EAP拡張(EAP−EXT)のためのEAPメソッド
【課題】EAP機能を拡張するために使用されるEAPメソッドを提供する。
【解決手段】クライアントとサーバ間に認証機構を持たない第1のEAPメソッドを採用し、第1のEAPメソッドは、クライアントを認証するために第1のEAPメソッドの内部で実行する内部認証メソッドに依存し、クライアントを認証するために使用される第2のEAPメソッドを第1のEAPメソッドの内部で実行する認証機構を有さず、第2のEAPメソッドにより生成されたEAPキーイングマテリアルに基づき第1のEAPメソッドに対してEAPキーイングマテリアルを得ることによって第1のEAPメソッドと第2のEAPメソッドとの間の暗号化結合を作る。
【解決手段】クライアントとサーバ間に認証機構を持たない第1のEAPメソッドを採用し、第1のEAPメソッドは、クライアントを認証するために第1のEAPメソッドの内部で実行する内部認証メソッドに依存し、クライアントを認証するために使用される第2のEAPメソッドを第1のEAPメソッドの内部で実行する認証機構を有さず、第2のEAPメソッドにより生成されたEAPキーイングマテリアルに基づき第1のEAPメソッドに対してEAPキーイングマテリアルを得ることによって第1のEAPメソッドと第2のEAPメソッドとの間の暗号化結合を作る。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、無線ネットワーク、幾つかの好適実施形態では、ピアとサーバとの間で一貫性維持のために照合されるパラメータをチャネル結合するシステム及び方法に関する。
【背景技術】
【0002】
ネットワーク及びインターネット(登録商標)プロトコル
多様なコンピュータネットワークがあり、インターネットは最も有名である。インターネットは、コンピュータネットワークの世界規模のネットワークである。今日、インターネットは、何百万人ものユーザが利用可能な、公衆の自律的ネットワークである。インターネットは、TCP/IP(すなわち、伝送制御プロトコル/インターネットプロトコル)と呼ばれる1組の通信プロトコルを使って各ホストを接続する。インターネットは、インターネットバックボーンとして呼ばれる通信インフラストラクチャを有する。インターネットバックボーンへのアクセスは大部分企業及び個人へのアクセスを再販するインターネットサービスプロバイダ(ISP)によって制御される。
【0003】
IP(インターネットプロトコル)に関して、これは、ネットワーク上である装置(電話機、PDA[携帯情報端末]、コンピュータなど)から別の装置にデータを送るためのプロトコルである。今日、IPv4、IPv6などを含めて、様々なIPのバージョンがある。ネットワーク上の各ホスト装置は、独自の一意の識別子である少なくとも1つのIPアドレスを有する。
【0004】
IPはコネクションレス型プロトコルである。通信時の端点間接続は連続的ではない。ユーザがデータ又はメッセージを送信し、又は受信するとき、データ又はメッセージは、パケットと呼ばれる構成要素に分割される。各パケットは、独立のデータ単位として扱われる。
【0005】
インターネットなどのネットワークを介した各点間の伝送を標準化するために、OSI(開放型システム間相互接続)モデルが確立された。OSIモデルは、ネットワーク中の2点間の通信プロセスを7つの階層に分け、各層(レイヤ)は独自の機能セットを付加する。各装置は、送信側端点では各層を通る下方への流れがあり、受信側端点では各層を通る上方への流れがあるようにメッセージを処理する。7つの機能層を提供するプログラミング及び/又はハードウェアは、通常、デバイスオペレーティングシステム、アプリケーションソフトウェア、TCP/IP及び/又は他のトランスポート及びネットワークプロトコル、並びに他のソフトウェア及びハードウェアの組み合わせである。
【0006】
通常、上位4層は、メッセージがユーザから、又はユーザへ渡されるときに使用され、下位3層は、メッセージが装置(IPホスト装置など)を通過するときに使用される。IPホストは、サーバ、ルータ、ワークステーションなど、IPパケットを送受信することのできるネットワーク上の任意の装置である。他の何らかのホストに向けられているメッセージは、各上位層には渡されず、この他のホストに転送される。OSIモデルの各層を以下に列記する。第7層(すなわち、アプリケーション層)は、例えば、通信相手が識別され、サービス品質が識別され、ユーザ認証及びプライバシが考慮され、データ構文に対する制約条件が識別される層である。第6層(すなわち、プレゼンテーション層)は、例えば、着信及び発信データをあるプレゼンテーション形式から別の形式に変換する層である。第5層(すなわち、セッション層)は、例えば、アプリケーション間の会話、交換及びダイアログをセットアップし、調整し、終了させる層である。第4層(すなわち、トランスポート層)は、例えば、エンドツーエンド制御及び誤りチェックなどを管理する層である。第3層(すなわち、ネットワーク層)は、例えば、経路指定や転送などを処理する層である。第2層(すなわち、データリンク層)は、例えば、物理レベルでの同期を提供し、ビットスタッフィングを行い、伝送プロトコルの知識及び管理などを提供する層である。米国電気電子技術者協会(IEEE)では、データリンク層を、物理層との間のデータ転送を制御するMAC(媒体アクセス制御)層と、ネットワーク層とのインターフェースを取り、コマンドを解釈し、誤り回復を行うLLC(論理リンク制御)層という、2つのさらなる副層(サブレイヤ)に細分する。第1層(すなわち、物理層)は、例えば、物理レベルにおいてネットワークを介してビットストリームを伝達する層である。IEEEでは、物理層を、PLCP(物理層収束手順)副層とPMD(物理媒体依存)副層とに細分する。
【0007】
無線ネットワーク:
無線ネットワークは、例えば、セルラ及び無線電話機、PC(パーソナルコンピュータ)、ラップトップコンピュータ、装着型コンピュータ、コードレス電話機、ポケットベル、ヘッドセット、プリンタ、PDAなど、多種多様なモバイル機器を組み込むことができる。例えば、モバイル機器は、音声及び/又はデータの高速無線伝送を確保するデジタルシステムを含むことができる。一般的なモバイル機器は、次の構成要素の一部又は全部、即ち送受信機(すなわち、例えば、送信機、受信機及び、必要に応じて、他の機能が統合されたシングルチップ送受信機などを含む、送信機及び受信機)、アンテナ、プロセッサ、1つ又は複数の音声変換器(例えば、音声通信用機器でのスピーカやマイクロホンなど)、電磁データ記憶(データ処理が提供される機器の場合などでの、ROM、RAM、デジタルデータ記憶など)、メモリ、フラッシュメモリ、フルチップセット又は集積回路、インターフェース(USB、CODEC、UART、PCMなど)及び/又は同種のものを含む。
【0008】
モバイルユーザが無線接続を介してローカルエリアネットワーク(LAN)に接続することのできる無線LAN(WLAN)が、無線通信に用いることができる。無線通信には、例えば、光、赤外線、電波、マイクロ波などの電磁波を介して伝搬する通信などが含めることができる。現在、ブルートゥース(登録商標)、IEEE802.11、HomeRFなど、様々なWLAN標準が存在する。
【0009】
一例として、ブルートゥース製品は、モバイルコンピュータ、モバイル電話機、携帯式ハンドヘルド機器、携帯情報端末(PDA)、及び他のモバイル機器の間のリンク、並びにインターネットへの接続を提供するのに使用できる。ブルートゥースは、モバイル機器が、短距離無線接続を使って、相互に、また非モバイル機器と、どのようにして容易に相互接続し合うことができるかを詳述するコンピュータ及び電気通信業界仕様である。ブルートゥースは、ある機器と別の機器との間でデータを同期させ、整合させ続けることを必要とする、様々なモバイル機器の普及から生じるエンドユーザ問題に対処して、異なるベンダからの装置を相互にシームレスに動作させるデジタル無線プロトコルを作成する。ブルートゥース機器は、共通の名称概念に従って名称付けできる。例えば、ブルートゥース機器は、ブルートゥース機器名(BDN)又は一意のブルートゥース機器アドレス(BDA)に関連付けられた名称を持ち得る。また、ブルートゥース機器は、インターネットプロトコル(IP)ネットワークに参加することもできる。ブルートゥース機器がIPネットワーク上で機能する場合、この機器は、IPアドレス及びIP(ネットワーク)名を備えることができる。よって、IPネットワークに参加するように構成されたブルートゥース機器は、BDN、BDA、IPアドレス及びIP名などを含むことができる。「IP名」という用語は、インターフェースのIPアドレスに対応する名称を指す。
【0010】
IEEE標準であるIEEE802.11は、無線LAN及び機器の技術の仕様を定める。802.11を使えば、各単一基地局がいくつかの機器をサポートする無線ネットワークが実現できる。いくつかの例では、機器に無線ハードウェアが事前装備されていることもあり、ユーザが、アンテナを含めることができ、カードなどの別個のハードウェアをインストールすることもできる。例えば、802.11で使用される機器は、通常、機器がアクセスポイント(AP)であるか、移動局(STA)であるか、ブリッジであるか、PCMCIAカードであるか、それとも別の機器であるか否かを問わず、無線送受信機、アンテナ、及びネットワークにおける各点間のパケットの流れを制御するMAC(媒体アクセス制御)層という3つの注目すべき要素を含む。
【0011】
更に、いくつかの無線ネットワークでは、複数インターフェース機器(MID)が利用できる。MIDは、ブルートゥースインターフェースと802.11インターフェースなど、2つの独立のネットワークインターフェースを含むことができ、よって、MIDが2つの別個のネットワーク上に参加すると同時に、ブルートゥース機器ともインターフェースすることが可能になる。MIDは、IPアドレス、及びIPアドレスに関連付けられた共通IP(ネットワーク)名を持つことができる。
【0012】
無線ネットワーク機器には、それだけに限らないが、ブルートゥース機器、複数インターフェース機器(MID)、802.11x機器(802.11a、802.11b、802.11g機器などを含む、IEEE802.11機器)、HomeRF(家庭内無線周波数)機器、Wi−Fi(Wireless Fidelity)機器、GPRS(汎用パケット無線システム)機器、3Gセルラ機器、2.5Gセルラ機器、GSM(登録商標)(移動通信用グローバルシステム)機器、EDGE(Enhanced Data for GSM Evolution)機器、TDMA型(時分割多重接続)機器、又はCDMA2000を含むCDMA型(符号分割多重接続)機器が含めることができる。各ネットワーク機器は、それだけに限らないが、IPアドレス、ブルートゥース機器アドレス、ブルートゥース共通名、ブルートゥースIPアドレス、ブルートゥースIP共通名、802.11IPアドレス、802.11IP共通名、IEEE MACアドレスを含む、様々な種類のアドレスを含むことができる。
【0013】
また、無線ネットワークは、例えば、モバイルIP(インターネットプロトコル)システム、PCSシステム、及び他のモバイルネットワークシステムにおいて見られるメソッド及びプロトコルも関与できる。モバイルIPでは、これに、インターネット技術標準化委員会(IETF)によって作成された標準通信プロトコルが関与する。モバイルIPでは、モバイル機器ユーザは、これらの一旦割り当てられたIPアドレスを維持しつつ、各ネットワークにまたがって移動することができる。コメントリクエスト(RFC)3344を参照されたい。(注:RFCはインターネット技術標準化委員会(IETF)の公式文書である。)モバイルIPは、インターネットプロトコル(IP)を拡張し、モバイル機器のホームネットワーク外部に接続するときに、モバイル機器にインターネットトラフィックを転送する手段を付加する。モバイルIPは、各モバイルノードに、これのホームネットワーク上のホームアドレスと、ネットワーク及びこれのサブネット内の機器の現在位置を識別する気付アドレス(CoA)を割り当てる。機器が異なるネットワークに移動すると、機器は、新しい気付アドレスを受け取る。ホームネットワーク上のモビリティエージェントは、各ホームアドレスを、これの気付アドレスと関連付けることができる。モバイルノードは、インターネット制御メッセージプロトコル(ICMP)などを使って、これの気付アドレスを変更する都度ホームエージェントにバインディング更新を送ることができる。
【0014】
(例えば、モバイルIP外部などの)基本的なIP経路指定において、経路指定機構は、各ネットワークノードが、常に、インターネットなどへの一定の接続点を有し、かつ各ノードのIPアドレスが、これが接続されているネットワークリンクを識別するという仮定を利用する。本明細書において、「ノード」という用語は、例えば、データ伝送のための再配信点や端点などを含むことができ、他のノードへの通信を認識し、処理し、及び/又は転送することのできる接続点を含む。例えば、インターネットルータは、機器のネットワークを識別するIPアドレスなどを調べることができる。次いで、ネットワークレベルにおいて、ルータは、特定のサブネットを識別するビットセットを調べることができる。次いで、サブネットレベルにおいて、ルータは、特定の機器を識別するビットセットを調べることができる。一般的なモバイルIP通信の場合、ユーザが、例えば、インターネットなどからモバイル機器を切断し、これを新しいサブネットで再接続しようとする場合、機器は、新しいIPアドレス、適正なネットマスク及びデフォルトのルータを用いて再構成する必要がある。そうでなければ、経路指定プロトコルは、パケットを適正に配信することができないはずである。
【0015】
メディア独立の事前認証:
メディア独立の事前認証(MPA)は、任意のリンク層を介して、任意のモビリティ管理プロトコルと共に動作する、モバイル支援型の、安全なハンドオーバ最適化方式である。MPAを用いれば、移動ノードは、候補ターゲットネットワーク(CTN)のIPアドレスと他の構成パラメータを安全に獲得することができるだけでなく、CTNに実際に接続する前に、獲得したIPアドレスを使ってIPパケットを送受信することもできる。これは、移動ノードが、リンク層におけるハンドオーバを実行する前に、任意のモビリティ管理プロトコルの対応付け更新を完了し、新しい気付アドレス(CoA)を使用することを可能にする。
【0016】
MPAは、任意のリンク層を介して、モバイルIPv4、モバイルIPv6、MOBIKE、HIP、SIPモビリティなどを含む任意のモビリティ管理プロトコルと共に動作する。MPAでは、IEEE802.11i事前認証の概念が、上位層で動作するように拡張され、移動端末がそこに移動できるネットワークからのIPアドレスの早期獲得と、移動端末がまだ現在のネットワークに接続されている間にネットワークへの事前対応型ハンドオーバとを実行する追加機構を組み込んでいる。
【0017】
MPAをサポートする移動ノード(MN)は、認証エージェント(AA)との事前認証プロセスを開始する。正常な認証により、PANA認証エージェント(PAA)が、AAとセキュリティアソシエーションを確立することが可能になる。これが、IPアドレスと他の構成パラメータを移動ノードに安全に配信するための構成プロトコルを安全に実行するのに使用される構成エージェント(CA)と、移動ノードへの事前対応型ハンドオーバトンネルを確立するためのトンネル管理プロトコルを安全に実行するアクセスルータ(AR)に加わる。この全プロセスが、MNが現在の接続点に接続されるときに実行される。これは、参照によりこれの開示が本明細書に組み込まれる、2006年3月の「draft-ohba-mobopts-mpa-framework-02.txt」と、2006年10月22日の「draft-ohba-mobopts-mpa-framework-03.txt」で詳細に説明されている。
【0018】
安全なネットワークアクセスサービスを提供することは、クライアントとアクセスネットワークの認証と許可に基づくアクセス制御を必要とする。クライアントからネットワークへの認証は、実行点を通るトラフィックフローを規制するのに必要とされるパラメータを提供する。クライアントとアクセスネットワークの間で認証メソッドを搬送するプロトコルが必要とされる。
【0019】
PANAは、ネットワークアクセス認証メソッドのためのリンク層不可知トランスポートを提供する。拡張可能認証プロトコル(EAP)[参照により全体が本明細書に組み込まれるRFC3748を参照]は、かかる認証メソッドを提供する。これに関して、PANAは、様々な認証メソッドを搬送することのできるEAPを搬送する。IPより上でのEAPのトランスポートを可能にすることによって、EAPメソッドとして伝えることができる任意の認証メソッドがPANAに利用でき、故に任意のリンク層技術に利用できる。
【0020】
PANAプロトコル[I-D.ietf-pana-pana]は、アクセスネットワーク内のPaC(PANAクライアント)とPAA(PANA認証エージェント)の間でEAPメッセージを伝送する。PaCがモバイル機器であり、これのアプリケーションを実行する間に、あるアクセスネットワークから別のアクセスネットワークに移動することができる場合、このPaCが、ハンドオーバ期間中にアプリケーションの性能を低下させずに、シームレスにハンドオーバを行うことは重要である。PaCが新しいアクセスネットワーク内のPAAとPANAセッションを確立することをハンドオーバが必要とするとき、PANAセッションを確立する信号は、できるだけ速く完了されるべきである。
【0021】
PANAプロトコルは、ネットワークアクセスサービスのための認証と許可を行うために、クライアント(PaC)とサーバ(PAA)の間で実行される。このプロトコルのメッセージングは、一連のリクエストとレスポンスを伴い、これらのうちのいくつかが、どちらかの側によって開始できる。各メッセージは、ペイロード内でゼロ以上のAVPを伝送することができる。PANAの主要ペイロードは、認証を実行するEAPである。PANAは、PaCとPAAが、EAPセッションを確立するのに役立つ。
【0022】
他の背景情報として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.を参照する。この文献の全開示はここに全て開示されているように参照により本明細書に援用される。
【0023】
EAP
(以下に引用する)Aboba, RFC 3748を参照すると、拡張認証プロトコル(EAP)の具体的態様が説明されている。EAPは複数の認証メソッドをサポートする認証フレームワークである。EAPは一般的にはIPを必要としない、ポイントツーポイントプロトコル(PPP)又はIEEE802のような複数のデータリンク層上で直接に実行する。EAPは二重削除及び再送信のため独自のサポートを備えているが、下位層順の保証に依存する。断片化はEAP自体内でサポートされないが、個々のEAPメソッドがこれをサポートできる。
【0024】
EAPは切換回路だけでなく、専用リンクに使用でき、無線リンクだけでなく有線であってもよい。今まで、EAPはPPP[RFC1661]を用いて切換回路又はダイアルアップネットワークを介して接続するホスト及びルータによって実現されていた。それはまたIEEE 802[IEEE−802]を用いてスイッチ及びアクセスポイントによっても実現されていた。IEEE 802有線媒体に関するEAPカプセル化が[IEEE-802.1X]に説明されており、IEEE無線LANsに関するカプセル化は[IEEE-802.11i]に開示されている。
【0025】
EAPアーチテクチャの利点の1つはその柔軟性にある。EAPは、特定の認証機構を選択するために用いられ、その際、Authenticatorが使用すべき特定の認証メソッドを決定するためにピアに対しより多くの情報を要求する。各新しい認証メソッドをサポートするために更新されることをAuthenticatorが必要とすることなく、EAPは幾つか又は全てのメソッドおよびピアに対するパススルーとして動作するAuthenticatorによって、幾つか又は全ての認証メソッドを実施できるバックエンド認証サーバの使用を可能にする。
【0026】
この後者の引用文献の中で、Authenticatorがパススルーとして動作するか否かに関係なくAuthenticatorの要求が適用される。要求がAuthenticator又はバックエンド認証サーバのいずれかに適用されることを意味している場合、EAP認証が終了される場所に依存して、用語「EAPサーバ」が使用されている。
【0027】
EAPはメッセージの再送信をサポートする一方で、それは下位層によって提供される順序付け保証を仮定し、故にメッセージの到達順序に異常のある受信はサポートされない。
【0028】
EAPはメッセージの断片化(フラグメンテーション)及び再構築(リアセンブリ)をサポートしないので、最小EAP MTUより大きなペイロードを生成するEAP認証メソッドは断片化サポートを提供する必要がある。
【0029】
EAP−TLSのような認証メソッドはメッセージの断片化及び再構築を提供するが、この後者の引用文献で定義されたEAPメソッドは行わない。その結果、EAPパケットサイズがリンクのEAP MTUを越えれば、これらのメソッドは困難に合うことになる。
【0030】
EAP認証はサーバ(Authenticator)によって初期化されるが、多くの認証プロトコルはクライアント(ピア)によって初期化される。その結果、EAPを通過するために1つ又は2つの追加メッセージ(多くとも1往復)を追加することが認証アルゴリズムに必要となるかもしれない。
【0031】
証明利用認証がサポートされる場合、追加往復の数は証明書連鎖(certificate chains)の断片化によりかなり多くなるかもしれない。一般的に、断片化EPAパケットは断片があるだけ多くの往復で送る必要がある。例えば、サイズが14960オクテットの証明連鎖は1496オクテットEAP MTUで10往復する必要がある。EAPが重大なパケットロスを起こす下位層上で動作する場合、又はAuthenticatorと認証サーバとの接続が重要なパケットロスを起こす場合、多くの往復を必要とするEAPメソッドは困難に直面することもある。これらの状況において、少ない往復を用いたEAPメソッドの使用が望まれる。
【0032】
EAP認証交換は次のように処理される。即ち、
[1]Authenticatorはピアを認証するためリクエスト(Request)を送る。リクエストは要求されているものを示すタイプフィールドを有する。リクエストタイプの例は識別、MD5−チャレンジなどを含む。MD5−チャレンジタイプはCHAP認証プロトコルに密接に対応する[RFC1994参照]。一般的には、Authenticatorは初期認証リクエストを送ることになるが、初期認証リクエストは必要とされなく、バイパスされないこともある。例えば、識別はピアが接続されているポート(専用回線、専用スイッチ又はダイアルアップポート)によって決定される場合、又は識別が(MD5−チャレンジレスポンスなどのネームフィールドにおいて、呼出局識別又はMACアドレスを介して)他のメソッドで得られる場合には要求されないこともある。
【0033】
[2]ピアは有効リクエストに答えてレスポンスパケット(Response packet)を送る。リクエストパケットと同様に、レスポンスパケットはリクエストのタイプフィールドに対応するタイプフィールドを含む。
【0034】
[3]Authenticatorは追加リクエストパケットを送り、ピアはレスポンスで答える。リクエスト及びレスポンスのシーケンスは必要なだけ継続する。EAPは‘横並び(lock step)’プロトコルであり、故に、初期リクエスト以外は、新たなリクエストは有効なレスポンスを受理する前に送ることができない。Authenticatorはリクエストを再送信する責任がある。適正数の再送信の後には、AuthenticatorはEAP対話を終了しなくてはならない。Authenticatorは再送信したとき、又はピアからのレスポンスが得られないときには成功又は失敗パケットを送る必要がない。
【0035】
[4]対話はAuthenticatorがピア(1以上のリクエストに対して受入れがたいレスポンス)を認証できなくなるまで続けられる。この場合、Authenticatorの実行にはEAP失敗(コード4)を送信する必要がある。あるいは、認証対話は認証が成功したことをAuthenticatorが決定するまで継続する。この場合、AuthenticatorはEAP成功(コード3)を送信する必要がある。
【0036】
他の利点では、EAPプロトコルは特定のものを事前取り決めする必要が無く多くの認証機構をサポートできる。更に、ネットワークアクセスサーバ(NAS)装置(例えば、スイッチ又はアクセスポイント)は各認証メソッドを理解する必要が無く、バックエンド認証サーバに対するパススルーエージェントとして動作できる。パススルーのためのサポートは随意的である。Authenticatorは局所ピアを認証でき、更に、同時に非局所ピア及び局所的には実行しない認証メソッドに対するパススルーとして作用する。更に、バックエンド認証サーバからAuthenticatorを分離することによって証明管理及びネットワークアクセスポリシー決定を簡単にする。
【0037】
概念的に、EAP実施は次の要素からなる。
【0038】
[a]下位層。下位層はピアとAuthenticatorとの間でEAPを送受信する義務がある。EAPはPPP,有線IEEE802ラン[IEEE-802.1X], IEEE 802.11 wireless LANs [IEEE-802.11], UDP (L2TP [RFC2661]及びIKEv2参照)及びTCPを含む各種下位層上で実行していた。
【0039】
[b]EAP層。EAP層は下位層を介してEAPパケットを送受信し、二重検出及び再送信を実行し、EAPメッセージをEAPピア及びAuthenticator層に搬送し及びAuthenticator層から受信する。
【0040】
[c]EAPピア及びAuthenticator層。コードフィールドに基づいて、EAP層は入力EAPパケットをEAPピア及びAuthenticator層に分離する。一般的には、所定ホストでのEAP実行はピア又はAuthenticator機能のいずれかをサポートすることになるが、ホストがEAPピア及びAuthenticatorの両方として作用することを可能にする。そのような実行においては、EAP及びAuthenticator層の両方が存在することになる。
【0041】
[d]EAPメソッド層。EAPメソッドはAuthenticatorアルゴリズムを実行し、EAPピア及びAuthenticator層を介してEAPメッセージを送受信する。断片化のサポートはEAP自体によっては得られないが、これはEAPメソッドの責任である。
【0042】
以後の参考文献はここに参照として引用される次の定義を説明している。
【0043】
Authenticator
EAP認証を初期化するリンクの終端。Authenticatorという用語は[IEEE-802.1X]に使用され、この明細書では同様の意味を有する。
【0044】
ピア
Authenticatorに応答するリンクの終端。[IEEE-802.1X]では、この終端はSupplicantとして知られている。
【0045】
バックエンド認証サーバ
バックエンド認証サーバは認証サービスをAuthenticatorに提供する個人である。使用時には、このサーバは一般的にはAuthenticatorのためにEAPメソッドを実行する。この専門用語は[IEEE-802.1X]に使用されている。
【0046】
AAA
EAPサポートを持つ認証、許可、及び課金(AAA)プロトコルはRADIUS及びダイアミタ(Diameter)を含む。この明細書では、用語“AAAサーバ”及び“バックエンド認証サーバ”は交換可能に使用される。
【0047】
EAPサーバ又はサーバ
ピアによってEAP認証メソッドを終了する個人バックエンド認証サーバが使用されない場合には、EAPサーバはAuthenticatorの一部である。Authenticatorがパススルーモードで行動する場合、EAPサーバはバックエンド認証サーバに設けられる。
【0048】
成功した認証
この明細書の内容では、「成功した認証」はEAPメッセージの交換であり、その結果Authenticatorはピアによってアクセスできることを決定し、ピアがこのアクセスを使用することを決定する。Authenticatorの決定は一般的には認証及び許可面の両方を含み、ピアはAuthenticatorに首尾良く証明できるが、アクセスは政策的理由によりAuthenticatorによって拒絶されるかもしれない。
【0049】
マスタセッションキー(MSK)
EAPピアとサーバ間で得られ、EAP法によって転送されるキーイングマテリアル。MSKは長さが少なくとも64オクテットである。既存の実施では、EAPサーバとして作用するAAAサーバはMSKをAuthenticatorに搬送する。
【0050】
拡張マスタセッションキー(EMSK):
EAPクライアントとサーバ間で得られ、EAP法によって転送される追加キーイングマテリアル。EMSKは長さが少なくとも64オクテットである。EMSKはAuthenticator又は任意の他の第三者によっては共有されない。EMSKはまだ定義されていない将来の使用のために予約される。
【0051】
EAP拡張
参考のため、出願人は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を参照する。この参考文献は次のようにEAP再認証プロトコルのためのEAP拡張を説明している。拡張可能認証プロトコルは2つのグループを認証するメソッドの搬送のための総括フレームワークであり、認証は一方向又は相互のいずれかである。第1目的はネットワークアクセス制御であり、キー生成メソッドはアクセス制御を実施するために推奨される。EAPキーイング階層は2つのキーを定義する。これらのキーはトップレベルで、即ちマスタキーセッション(MSK)及び拡張MSK(EMSK)で得られる。最も一般的な展開シナリオにおいては、ピア及びサーバはAuthenticatorとして知られている第三者を介して互いに認証する。Authenticator又はAuthenticatorによって管理される個人はアクセス制御を実施する。成功した認証後には、サーバはMSKをAuthenticatorに搬送し、Authenticator及びピアはMSKを認証キー又はキー導出キーとして用いて一時セッションキー(TSK)を取得し、単位パケットアクセス実施のためにTSKを使用する。ピアがあるAuthenticatorから他のAuthenticatorに移動するときは、完全EAP認証を避けることが望ましい。EAPメソッドの他の実施を伴う完全EAP交換は完了するためにいくつかの往復及びかなりの時間を取り、ハンドオフ時間に遅延が生じる。幾つかのEAP法は計算オーバヘッドを減じることによって再認証を最適化するために初期認証から状態の使用を特定し、メソッド特定再認証は殆どのケースでは少なくとも2往復する。多くのメソッドは再認証のためにサポートを提供しないことに注意することが重要でもある。故に、個々のメソッドにおけるよりもEAPにおいて効果的な再認証サポートを持つのが良い。
【0052】
Authenticator間で共有するキーは時々ハンドオフタイムを低減するため現実的な解決法として使用される。その場合、Authenticatorの譲歩は他のAuthenticatorを介して確立されるEAPセッションの譲歩となる。要するに、再びEAPメソッドを実行することを必要としないでピアとAuthenticator間にフレッシュキーを確立することを可能にする有効EAP再認証機構を設計する必要がある。この明細書はEAPを用いて有効再認証のためにEAP再認証拡張(ERX)を特定している。ERXに基づくEAP再認証プロトコル(ERP)はピアに対するEAPメソッド非依存再認証をサポートする。このピアは以前に実行されたEAP認証からの有効な残りキーマテリアルを有する。プロトコル及びEAP再認証に必要なキー階層がこの明細書に記載されている。
【0053】
次の背景参考文献は個々に参照としてここに援用される。
【先行技術文献】
【非特許文献】
【0054】
【非特許文献1】Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, March 1997 (ここでは[RFC2119]と称する).
【非特許文献2】Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, “Extensible Authentication Protocol (EAP),” RFC 3748, June 2004 (ここでは[RFC3748]と称する).
【非特許文献3】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.
【非特許文献4】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]と称する).
【非特許文献5】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]と称する).
【非特許文献6】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]と称する).
【非特許文献7】National Institute of Standards and Technology, “Secure Hash Standard”, August 2002 (ここでは[sha256]と称する).
【非特許文献8】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]と称する).
【非特許文献9】Kaufman, C., “Internet Key Exchange (IKEv2) Protocol”, RFC 4306, December 2005 (ここでは[RFC4306]と称する).
【非特許文献10】Narayanan, V. and L. Dondeti, “EAP Re-authentication Extensions”, draft-ietf-hokey-erx-02 (work in progress), July 2007 (ここでは[I-D.ietf-hokey-erx]と称する).
【非特許文献11】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]と称する). 各種方式及び方法は知られているが、改良された方式及び方法の必要性がある。
【発明の概要】
【発明が解決しようとする課題】
【0055】
本発明は背景技術における各種制限及び欠陥を解消する。本出願は以下に述べるように下記のような発明セットを含む、複数の発明を盛り込んでいる。
【課題を解決するための手段】
【0056】
発明セット♯1:
幾つかの実施形態によると、クライアントとサーバ間のメソッドの認証方法はa)クライアントとサーバ間に認証機構を有さないメソッドを採用すること、及びb)クライアントを認証するために前記メソッドに内部認証メソッドを当てにさせることを含む。好ましくは、メソッドは内部に第2EAPを持つ認証機構を有さない第1EAPメソッドであり、第2EAPはクライアントを認証するために使用される。
【0057】
発明セット♯2:
幾つかの他の実施形態によると、EAP拡張機能性に関する能力を交渉するためEAPピア及びEAPサーバのためのメソッドは、サーバと拡張機能性に関するクライアントとの能力交換を提供するEAP拡張メソッド(EAP−EXT)を採用することを含み、拡張機能性は認証機構を持たなく少なくとも1つのEAPメソッドはEAPピアを認証するためのEAP拡張メソッド以内で実行する。幾つかの実施形態では、本方法は内部EAPメソッドにキーイングマテリアルを生成させること、外部EAP拡張メソッドのメッセージをAUTH TLVでサポートすることを更に含む。幾つかの実施形態では、本方法は外部EAP拡張メッセージのAUTH TLVsは最近成功した内部メソッドのEAPキーイングマテリアルから生成されるEAP拡張キー(EAP−EXT−KEY)を用いて計算されることを更に含む。幾つかの実施形態では、本方法はEAP拡張キーがEAP−EXTメッセージをサポートする完全性のためのAUTH TLVsを計算するために使用されることを更に含む。幾つかの他の実施形態では、本方法はEAP拡張キーが使用特定ルートキー導出アルゴリズムを使用して内部EAPメソッドによって生成されるEMSKから得られることを更に含む。幾つかの実施形態では、本方法はEAP拡張メソッドが再認証機構に使用されたEAPメソッドによって要求される事前共有キーとして使用されるEAP再認証キーを定義することを更に含む。幾つかの実施形態では、本方法はEAP再認証キーが使用特定ルートキー導出アルゴリズムを用いるEAP拡張メソッドから排出されるEMSKから得られることを更に含む。幾つかの実施形態では、本方法は最終メッセージであることを示すために設定できるビット、エラーを示すために設定できる他のビット、複数のビットのバージョンフィールド、将来の拡張のための複数のビットの予約フィールド及び各々が特定の能力に対応する複数のビットの能力フィールドとともに共通EAPフィールドを含むメッセージフォーマットを用いることを更に含む。幾つかの実施形態では、本方法はサーバ及び拡張機能に関するクライアントとの能力交換は能力ビットの設定によって行われることを更に含む。幾つかの実施形態では、本方法は送信者がチャネル結合機構をサポートすることを能力ビットが示すことを更に含む。幾つかの実施形態では、本方法では能力ビットは送信者が再認証をサポートすることを示すことを更に含む。幾つかの実施形態では、本方法は送信者が再認証をサポートしていることを示す能力ビットが最終リクエスト/EXTメッセージに設定されるときを更に含み、メッセージがサーバID TLV及びピアID TLVを含む。幾つかの実施形態では、本方法は送信サポート再認証が最終リクエスト/EXTメッセージ及びレスポンス/EXTメッセージ交換に設定されることを能力ビットが示すとき、EAPピア及びEAPサーバがEAP再認証キーを発生することを更に含み、サーバID及びサーバIDに含まれるピアID並びにピアID TLVs及びEAP再認証キーは再認証EAPメソッドに使用される。幾つかの実施形態では、本方法はEAP拡張メソッド内で順次実行される複数の内部EAPメソッドを採用すること及びシーケンスの内部EAP法がキーイングマテリアルを生成する毎に新たなEAP拡張キーを生成することを更に含む。幾つかの実施形態では、本方法はa)EAPサーバが少なくとも1つの能力ビットセットでEAPリクエスト/EXTメッセージを送信し、b)EAPピアはEAPリクエスト/EXTメッセージを受信し、少なくとも1つの能力ビットセットでEAPレスポンス/EXTメッセージを送信することを更に含む。幾つかの実施形態では、本方法はc)EAP−レスポンス/Extメッセージを受信し、F−ビットセット、少なくとも1つの能力ビットセット、ピアID TLV,サーバID TLV及びAUTH TLVを持つEAPリクエスト/EXTメセージを送信すること、d)EAPピアが上記c)のEAPリクエスト/Extメッセージを受信し、F−ビットセット,少なくとも1つの能力ビットセット及びAUTH TLVを有するEAPレスポンス/EXTメッセージを送信すること、e)EAP−サーバがd)のEAPレスポンス/EXTメッセージ受信し、EAP−成功メッセージを送信することを更に含む。幾つかの実施形態では、本方法はピア又はサーバがエラーを検出する場合のエラーを示すビットセット及びAUTH TLVによってEAPピア又はEAPサーバのいずれかにEAP拡張メッセージを送信させることを更に含む。幾つかの実施形態において、本方法は能力情報が攻撃者によって攻撃されるのを避けるためにキーイングマテリアルの生成後にサポートメッセージ交換を行うことを更に含む。幾つかの実施形態では、本方法はEAP拡張メソッド以内に多くのEAPメソッドを順序付けることを更に含む。幾つかの実施形態では、本方法はシーケンスにおいて先に成功した内部メソッドによって生成されるキーを用いる外部EAP拡張メソッドと共に各内部EAPメソッドをサポートすることによって暗号結合を作成し、最後に成功した内部EAPメソッドによって生成されるEAPキーイングマテリアルを最後に搬送することを更に含む。
【0058】
発明セット#3:
幾つかの他の実施形態によると、プロセッサ、メモリ、デジタルデータ記憶装置、及びデータメッセージを無線で送受信するための少なくとも1つの無線インターフェースを含む無線移動局が設けられ、無線モバイル装置はEAPピアとして動作するようにプログラムされている。無線モバイル装置はi)EAPサーバから少なくとも1つの能力ビットセットによってEAPリクエスト/EXTメッセージを受信し、ii)少なくとも1つの能力ビットセットによってEAPレスポンス/EXTメッセージを送信するようにプログラムされる。
【0059】
発明セット#4:
幾つかの他の実施形態によると、無線ネットワーク用のEAPサーバがEAPピアによってEAP認証メソッドを終了する。EAPサーバはa)少なくとも1つの能力ビットセットによってEAPリクエスト/EXTメッセージをEAPピアに送信し、b)少なくとも1つの能力ビットセットによってEAPレスポンス/EXTメッセージをEAPピアから受信する。
【0060】
上記及び/又は他の発明、態様、特徴及び/又は種々実施形態の利点は添付図面と関連して以下の説明を鑑みて更に理解されるであろう。種々実施形態は異なる態様、特徴及び/又は適用できる場合の利点を含める及び/又は除外することができる。更に、種々の実施形態は適用できる場合に他の実施形態の1以上の態様又は特徴を組み合わすことができる。特定の実施形態の態様、特徴及び/又は利点の説明は他の実施形態又は請求項を限定するように解釈されるべきでない。
【図面の簡単な説明】
【0061】
【図1】幾つかの実施形態に従った単一内部メソッドによってEAPサーバとEAPピアとの間の具体的なEAP−EXTメッセージシーケンスを示す図である。
【図2】幾つかの実施形態に従った複数の内部メソッドによってEAPサーバとEAPピアとの間の具体的なEAP−EXTメッセージシーケンスを示す図である。
【図3A】幾つかの模範的実施形態に従った具体的メッセージフォーマットを示す図である。
【図3B】幾つかの模範的実施形態に従った具体的能力フィールドを示す図である。
【図3C】幾つかの模範的実施形態に従った具体的TLVフォーマットを示す図である。
【図4】幾つかの追加の実施形態に従った単一内部メソッドによってEAPサーバとEAPピアとの間の具体的なEAP−EXTメッセージシーケンスを示す図である。
【図5】幾つかの追加の実施形態に従った複数の内部メソッドによってEAPサーバとEAPピアとの間の具体的なEAP−EXTメッセージシーケンスを示す図である。
【図6A】幾つかの追加の模範的実施形態に従った具体的メッセージフォーマットを示す図である。
【図6B】幾つかの追加の模範的実施形態に従った具体的能力フィールドを示す図である。
【図6C】幾つかの追加の模範的実施形態に従った具体的TLVフォーマットを示す図である。
【図7A】暗号アルゴリズムTLVを示す図である。
【図7B】完全性アルゴリズムTLVを示す図である。
【発明を実施するための形態】
【0062】
本発明の好適な実施形態は添付図面に一例として示され、限定されない。
【0063】
本発明は多くの異なる形態で実施できるが、多数の具体的実施形態は本開示がここに記載された種々の発明の原理の例を提供するよう考えられるべきであり、そのような例は個々に記載され及び/又はここに説明されていると言う了解の下で説明されている。
【0064】
1.序論
EAP(拡張可能認証プロトコル)は“EAPメソッド”[RFC3748]として知られている多くの認証アルゴリズムをサポートする認証プロトコルである。EAPでは、EAPピア及びEAPサーバはEAPキーイングマテリアル、即ち、MSK(マスタセッションキー)及びEMSK(拡張マスタセッションキー)を生成する。MSKの生成、搬送及び使用の詳しいフレームワークは[I-D.ietf-eap-keying]に記載されている。
【0065】
EMSK用法の1つが再認証である場合にEMSK(拡張マスタセッションキー)の幾つかの用法を定義することによってEAP[RFC3748]の拡張機能がある。EAPの他の拡張機能は[I-D.ohba-eap-channel-binding]に定義されているチャネル結合方式である。チャネル結合に関する追加の背景文献として、2006年4月20日にY. Ohbaによって出願された、CHANNEL BINDING MECHANISM BASED PARAMETER BINDING IN KEY DERIVATIONと名称付けられた同時継続の出願番号11/379,568の全開示が全体として参照することによって本明細書に援用される。EAPの拡張機能をサポートする実施は拡張機能をサポートしない実施と相互運用する必要があり、故に、前者の実施は後者の実施と通信するとき拡張機能を無効にするので、EAPピアに対する機構が必要となり、EAPの拡張機能に関して能力を取り決めるEAPサーバが必要となる。
【0066】
EAP機能を拡張するために2つの基本的な方法がある。1つの方法は既存の方法、即ち、リクエスト、レスポンス、成功及び失敗に加えて拡張EAP機能を実現するために新たなEAPコードを定義することである。しかしながら、この方法はRFC3748への変更を必要とし、下位層プロトコルへの変更も必要とするかもしれない。他の方法は拡張機能を実現するために新たなEAPメソッドを定義することである。この明細書は後者の方法が既存のEAP展開への攻撃を参照にするために後者の方法と取る。
【0067】
この明細書はEAP−EXT、EAP機能を拡張するEAPメソッドを説明している。幾つかの好適実施形態では、拡張EAP機能はチャネル結合及び再認証を含む。また、EAP−EXTメソッドはその内部の多くのEAPメソッドの順序づけを可能にする。
【0068】
2.EAP−EXT概要
好適実施形態では、EAP−EXTは能力交換を提供する。この点について、メッセージ内のビットは能力の表示に使用できる。幾つかの実施形態では、1ビット(R−ビット)は再認証能力に使用される。幾つかの実施形態では、1ビット(C−ビット)はチャネル結合能力を示すために使用される。
【0069】
EAP−EXTが使用されるとき、サーバが第1のEAPリクエストを送る前にサーバにピアの識別が知られれば先のEAP−識別交換が省略できる。この点について、ピアの識別をサーバに提供する、例えば、Authenticatorとサーバとの間でピアの識別を転送する幾つかのアウトバンド(outband)機構がある。
【0070】
EAP−EXTにおいて、チャネル結合及び再認証のような拡張EAP能力はピア及びサーバ間で交換される。同時に、少なくとも1つのEAPメソッド(例えば、EAP−TLS)はピアを認証するためのEAP−EXT内で実行される。内部メソッドがEAPキーイングマテリアルを生成するまで、AUTH TLVは含まれず、能力はサポートされない。故に、1つの内部EAPメソッドだけがあれば、AUTH TLVを有するがメソッドTLVを有さない追加のEAP−EXTがEAP成功又はEAP失敗メッセージを送る前に実行される。
【0071】
内部EAPメソッドはEAPキーイングマテリアルを生成した後、EAP−EXTメッセージはAUTH TLVによってサポートする必要がある。EAP−EXTメッセージの中のAUTH TLVsは最後に成功した内部メソッドのEAPキーイングマテリアルから生成されるEAP−EXT−KEYを用いて計算する必要がある。これはEAP−EXT内部で順次実行される複数の内部EAPメソッドがあれば、新たなEAP−EXT−KEYがシーケンスの内部EAPメソッドがEAPキーイングマテリアルを生成する毎に生成されることを意味する。任意の内部EAPメソッドはEAPキーイングマテリアルを生成できる用になる必要がある。
【0072】
成功したEAP−EXT実行の最後に、最後に成功した内部EAPメソッドによって生成されるEAPキーイングマテリアルはEAP層に転送される。F−ビットはEXP−EXT交換の終了を示すために使用される。
【0073】
図1は単一の内部EAPメソッドを持つEAP−EXTメッセージシーケンスの例を示す。図2は複数の内部EAPメソッドを有するEAP−EXTメッセージシーケンスの例を示す。
【0074】
3.エラー処理
エラーは複数の理由、例えば、内部EAPメソッド認証の失敗又は異常、未知、紛失EAP−EXT TLVにより生じるかもしれない。エラーはピア又はサーバのいずれかによって検出できる。エラーを起こしたEAP−EXTメッセージは誤りメッセージと見なされる。E−ビットセットを持つEAP−EXTメッセージはエラー表示のために使用される。これらのメッセージはエラー表示と見なされる。エラー表示はAUTH TLVを含める必要があり、他のTLVsを含めるべきでない。
【0075】
有効AUTH TLVを持たない(間違ったエラー表示を含む)どんな間違いメッセージも静かに破棄さする必要がある。
【0076】
有効AUTH TLVを持つ間違いリクエストに対して、ピアはエラー表示レスポンスを送る。有効AUTH TLVを伴わない間違いレスポンスに対して、サーバはエラー表示リクエストを送り、このリクエストはエラー表示レスポンスでピアによって応答される。サーバは有効AUTH TLV.を伴うエラー表示レスポンスに応答してEAP失敗メッセージを送り返す。
【0077】
4.完全性サポートキー
EAP−EXTは2種類のキー、即ち、1)EAP−EXT−KEY及び2)EAP−REAUTH−KEYを定義する。
【0078】
4.1. EAP−EXT−KEYは完全性サポートEAP−EXTメッセージのためにAUTH TLVsの計算に使用される。HMAC−SHA−256(上記文献に含まれる参考[sha256]を参照)は完全性アルゴリズムに使用されると、EAP−EXT−KEYの長さは32オクテットである。EAP−EXT−KEYは次のように定義されるUSRK(Usage Specific Root Key)導出アルゴリズムを用いて内部EAPメソッドによって生成されるEMSKから得られる(例えば、上記に参照することによって援用される文献[I-D.salowey-eap-emsk-deriv]を参照)。
【0079】
EAP−EXT−KEY = KDF (EMSK, “EAP-EXT-Integrity-Key”, length).
KDFでは、EAP−EXT−KEYは上記に参照することによって援用される文献[I-D.salowey-eap-emsk-deriv]に特定されているデフォルトPRFを用いる。
【0080】
4.2. EAP−REAUTH−KEY
EAP−REAUTH−KEYは再認証機構に使用されるEAPメソッドによって要求される事前共有キーとして使用される。EAP−REAUTH−KEYの長さは再認証機構に依存する。EAP−REAUTH−KEYは上記で援用される文献[I-D.salowey-eap-emsk-deriv]に次のように定義されるUSRK導出アルゴリズムを用いてEAP−EXTから転送されるEMSKから得られる。
【0081】
EAP−REAUTH−KEY = KDF(EMSK, “EAP-EXT-Reauthentication-Key”, length)
5. メッセージフォーマット
EAP−EXTは(IANAによって割り当てられるべき)EAP Type Xを用いる。[RFC3748]に定義された共通EAPフィールド(例えば、コード、識別子、長さ及び種類)を含むメッセージフォーマットは図3(A)に示される。
【0082】
F:
このビットはこれが送信者からの最後のEAP−EXTメッセージであることを示すように設定する必要がある。そうでなければ、このビットは設定する必要がない。
【0083】
このビットはメッセージがエラー表示であるときに設定される。このビットが設定されると、Fビットも設定する必要がある。エラー表に関する詳細な説明のセクション3を参照。
【0084】
バージョン:
この8ビットフィールドはEAP−EXTメソッドのバージョンを示す。この明細書はバージョン1を定義している。
【0085】
予約(Reserved):
6ビットフィールドは将来の拡張のために予約される。このフィールドは送信者によってゼロに設定する必要があり、受信者はこのフィールドを無視する必要がある。
【0086】
能力(Capabilities)
能力フィールドが処理するこのフィールドは拡張EAP能力を含む。能力は図3(B)に示されるフォーマットを処理する。
【0087】
各ビットは特定能力に対応する。各ビットの意味は次の通りである。
【0088】
C:
このビットは送信者がMSKのための[I-D.ohba-eap-channel-binding]に定義されるチャネル結合機構をサポートすることを示すために設定される。このビットはリクエスト及びレスポンスの両方に対して設定され、EAP−EXTメソッドが首尾よく完了すると、ピア及びサーバはチャネル結合機構を可能にする必要がある。prf+用デフォルトハッシュアルゴリズム(default hash algorithm)はAUTH_HMAC_SHA1_160である。
【0089】
R:
このビットは送信者が再認証EAPメソッドをサポートすることを示すために設定される。このビットは最後のリクエスト/EXTメッセージに設定されると(即ち、Fビットを有するリクエスト/EXTが設定されると)、メッセージはサーバID TLV及びピアID TLVを含める必要があり、Reauth−Key−Lifetime AVPを含めることができる。このビットが最後のリクエスト/EXT及びレスポンス/EXTメッセージ交換に設定されると、ピア及びサーバはEAP−REAUTH−KEYを発生する必要がある。サーバID及びピアIDはサーバID及びピアID TLVsに含められ、EAP−REAUTH−KEYは再認証EAPメソッドに使用される。デフォルト再認証機構はこの明細書に基づく従来技術のそれらによって選択できる。
【0090】
他のビットは将来の使用のために予約され、送信者によってゼロに設定する必要があり、受信者によって無視される必要がある。
【0091】
TLV:
ゼロ、1以上のTLVs(Type-Length-Value’s)。そのTLVフォーマットは図3(C)に示される。
【0092】
タイプ:
このフィールドはこのTLVのタイプを示す。
【0093】
長さ:
このフィールドは種類及びTLVの長さフィールドを含めて、オクテットでこのTLVの長さを示す。
【0094】
値
このフィールドはTLVタイプに特定されるデータを含む。
【0095】
6. EAP−EXT TLVs
後続TLVsが定義される。
【0096】
6.1.メソッドTLV
メソッドTLV(タイプ1)はタイプフィールドから開始するEAPメソッドペイロードを含む。
【0097】
6.2. AUTH TLV
AUTH TLV(タイプ2)はEAP−EXTメッセージをサポートするために使用される完全性データを含む。EAP−EXT−KEYはAUTH TLVsを計算するために使用される。
【0098】
TLV値フィールドはこのフィールドを含む全体のEAPメッセージわたって計算される。完全性データを計算する前に、このフィールドは全てゼロに初期化する必要がある。このフィールドの長さは使用時に完全性アルゴリズムに依存する。完全性チェックが失敗すると、メッセージは静かに破棄する必要がある。デフォルト完全性アルゴリズムはHMAC−SHA−256である(例えば、上記で援用されている文献[sha256]を参照)。
【0099】
6.3. ピアID TLV
ピアID TLV(タイプ3)は再認証に使用されるピアの識別を含む。
【0100】
6.4. サーバID TLV
サーバID TLV(タイプ4)は再認証に使用されるサーバの識別を含む。
【0101】
6.5. Reauth−Key−Lifetime TLV
Reauth−Key−Lifetime TLV(タイプ5)はEAP−REAUTH−KEYの寿命を秒単位で含む。
【0102】
7. 安全性考慮
内部EAPメソッドがEAPキーイングマテリアルを送る前に能力交換はサポートされない。故に、EAPキーイングマテリアルの作成後の追加サポートメッセージ交換は能力情報がピア及びサーバによって検出されないで攻撃者によって変更されるのを避けるために義務付けられる。
【0103】
EAP−EXTはその中の多くのEAPメソッドの順序付けを可能にする。複数の入れ子又は順序認証メソッドを暗号的に結合しないでそれらで構成される複合認証メソッドが介入者攻撃に対して無防備さを有する。EAP−EXTはシーケンスにおいて前に成功した内部メソッドによって生成されるキーを用いて外部EAPメソッド(即ち、EAP−EXT)と共に各内部EAPメソッドをサポートし、最後に成功した内部EAPメソッドによって生成されるEAPキーイングマテリアルを最終的に転送することによって必要暗号化的結合を作ることができる。暗号化結合を達成するために、EAP−EXTはEAPキーイングマテリアルを生成できる内部EAPメソッドを必要とする。
【0104】
追加EAP−EXT実施形態
詳細説明の残りは幾つかの内容において上記オリジナル実施形態を越える幾つかの変形例を有する追加のEAP−EXT実施形態について述べる。上記から分かるように、これらの追加実施形態は上述した先の実施形態に多くの点で類似している。これらの実施形態では、拡張機能、例えば、HOKEY再認証(例えば[I-D.ietf-hokey-erx]参照)及びMSKチャネル結合[I-D.ietf-eap-keying]がEAP機能を拡張することによってサポートできる。上記で説明したように、EAP機能を拡張するために2つの方法がある。1つの方法は既存のもの、即ち、リクエスト、レスポンス、成功及び失敗に加えて拡張EAP機能を実現するため新EAPコードを定義することである。しかしながら、この方法は[RFC3748]に変更を要求し、Authenticator及び下位層プロトコルに変更を要求することもできる。他の方法は拡張機能を実現するための新たなEAPメソッドを定義することである。両方法について、これら延長機能は下位互換性であることが望まれるかもしれない。そのような場合、EAPピアとEAPサーバとの間で拡張機能に関する能力を取り決める機構が必要となるかもしれない。
【0105】
これらの追加実施形態では、EAP機能を拡張するために使用されるEAPメソッドが説明される。拡張機能は、例えば、HOKEY再認証及びMSKチャネル結合を含む。これらの実施形態での提案EAPメソッド(EAP−EXT)は再度それ自体内で多くのEAPメソッドの順序付けをも可能にする。更に、これらの実施形態の中で、EAP−EXTは内部メソッド実施がMSKを生成するがEMSK を生成しない場合にMSK及びEMSKを発生できる。
【0106】
EAP−EXT概要
EAP−EXTは能力交換を提供する。1ビット(Rビット)はHOKEY再認証能力を示すために使用される。1ビット(Cビット)はチャネル結合能力を示すために使用される。
【0107】
EAP−EXTが使用されるとき、先のEAP識別交換はサーバがEAPリクエストを送る前にピアの識別がサーバに知られていれば省略できる。ピアの識別を提供する、例えば、Authenticatorとサーバとの間でピアの識別を転送するための帯域外機構が使用できる。
【0108】
EAP−EXTにおいて、HOKEY再認証及びMSKチャネル結合のような拡張EAP能力がピアとサーバ間で交換される。同時に、少なくとも1つのEAPメソッド(例えば、EAP−TLS)がピアを認証するためにEAP−EXT内で実行される。1つ以上の内部メソッドはメソッドTLVs(Type-Length-Values)で行われる。内部メソッドがEAPキーイングマテリアルを生成するまで、AUTH TLVは含まれなく、能力はサポートされない。故に、内部EAPメソッドだけ存在すれば、AUTH TLVを持つ追加EAP−EXT交換は内部メソッドの完了後及びEAP成功又はEAP失敗メッセージを送る前に行う必要がある。
【0109】
内部EAPメソッドがEAPキーイングマテリアルを発生した後、EAP−EXTメッセージはAUTH TLVによってサポートする必要がある。EAP−EXTメッセージのAUTH TLVsは最後に成功した内部メソッドのEAPキーイングマテリアルから生成されるEAP−EXT−AUTH−KEYを用いて計算する必要がある。これはEAP−EXT内で順次実行される多くの内部EAPメソッドがあれば、新たなEAP−EXT−AUTH−KEYはシーケンスのうちの内部EAPがEAPキーイングマテリアルを発生する毎に生成されることを意味する。任意の内部EAPメソッドはEAPキーイングマテリアルを生成可能にする必要がある。
【0110】
成功したEAP−EXTの実行の終わりに、EAPキーイングマテリアルが最後に成功した内部EAPメソッドによって生成されるMSKから得られ、EAP層に転送される。EAPキーイングマテリアル及びUSRKs(Usage Specific Root Keys)[I-D.ietf-hokey-emsk-hierarchy]を得るために使用される仮想ランダム関数がPRF TLVsを用いてEAP−EXT内で交渉できる。FビットはEXP−EXT交換の終了を示すために使用される。
【0111】
図4は単一内部EAPメソッド及びPRF取り決めを持つEAP−EXTメッセージシーケンスの例を示す。図5は複数の内部EAPメソッドを持つがPRF交渉を持たないEAP−EXTメッセージシーケンスの例を示す。
【0112】
エラー取り扱い
上述したオリジナル実施形態でエラー取り扱いに関する検討がここに援用される。
【0113】
キー
幾つかの実施形態では、EAP−EXTは次のタイプのキーを定義する。
【0114】
a.EAP−EXT から転送されるMSK及びEMSK
EAP−EXT から転送される64オクテットMSK及び64オクテットEMSKのセットはMSK_iから得られ、MSKは次の方法で[I-D.ietf-hokey-emsk-hierarchy]に定義されたKDFを用いて、最後に成功した内部EAPメソッドによって生成される。
【0115】
(MSK, EMSK) = KDF(MSK_i, “EAP-EXT-EAP-Keying-Material”, 128)
b. EAP−EXT−AUTH−KEY:
EAP−EXT−AUTH−KEYはEAP−EXTメッセージを安全にサポートするためにAUTH TLVsを算出するために用いられる。EAP−EXT−AUTH−KEYはEAP−EXT内だけで使用され、決して転送されない。EAP−EXT−AUTH−KEYは次のように[RFC4306]で定義されたprf+を用いて、最後に成功した内部EAPメソッド(MSK_i)によって生成されるMSKから求められる。
【0116】
EAP-EXT-AUTH-KEY = prf+(MSK_i, “EAP-EXT-認証キー”,長さ)
prf+用デフォルトハッシュアルゴリズムはPRF_HMAC_SHA2_256である。
【0117】
フィールド長はEAP−EXT交換中にEAPサーバによって選択される完全性アルゴリズムに依存することになる。HMAC−SHA−256[sha256]が完全性アルゴリズムに使用されると、長さ=32である。
【0118】
c. EAP−EXT−ENC−KEY:
EAP−EXT−ENC−KEYは暗号化TLVsの内容を暗号化するために使用される。それはMSK_iから得られ、MSKは次のように[I-D.ietf-hokey-emsk-hierarchy]で定義されるKDFを用いて、最後に成功した内部EAPメソッドによって生成される。
【0119】
EAP-EXT-ENC-KEY = prf+(MSK_i, “EAP-EXT-Encryption-Key”,長さ);
EAP−EXT−ENC−KEYを生成するために使用されるPRFはEAP−EXT交換中にEAPサーバによって選択される完全性アルゴリズムによって決定される。prf+用デフォルトハッシュアルゴリズムはPRF_HMAC_SHA2_256である。
【0120】
フィールド長はEAP−EXT交換中に取り決められる取り決め暗号化アルゴリズムに依存する。例えば、AES−CBC−128が使用されるときは、長さ=16である。
【0121】
d. HOKEY−REAUTH−KEY:
HOKEY−REAUTH−KEYはHOKEY再認証機構[I-D.ietf-hokey-erx]に必要な事前共通キーとして使用される。HOKEY−REAUTH−KEYの長さはHOKEY再認証機構に依存する。HOKEY−REAUTH−KEYは次のように[I-D.ietf-hokey-emsk-hierarchy]で定義されるUSRK導出アルゴリズムを用いてEAP−EXTから転送されるEMSKから求められる。
【0122】
HOKEY−REAUTH−KEY = KDF(EMSK, “EAP-EXT-再認証キー”,長さ)
メッセージフォーマット
EAP−EXTは(IANAによって割り当てられる)EAP Type XXを使用する。[RFC3748]で定義される共通EAPフィールド(即ち、コード、識別子、長さ及びタイプ)を含むメッセージフォーマットは図6(A)に示される。
【0123】
F:
このビットはこれが送信者からの最後のEAP−EXTメッセージであることを示すように設定する必要がある。
【0124】
E:
このビットはメッセージがエラー表示であるときに設定される。このビットが設定されるとき、Fビットも設定する必要がある。エラー表示の詳細な説明を以下に示す。
【0125】
バージョン
8ビットフィールドはEAP−EXTメソッドのバージョンを示す。この明細書はバージョン1を定義する。
【0126】
予約
この6ビットフィールドは将来の拡張のために予約される。このフィールドは送信者によってゼロに設定する必要があり、受信者はこのフィールドを無視する必要がある。
【0127】
能力
能力フィールドは拡張EAP能力を含む。能力フィールドは(図3(B)と同様であり)幾つかの実施形態において図6(B)に示されるようなフォーマットを持っている。ここでは、各ビットは特定の能力に対応する。各ビットの意味は次の通りである。
【0128】
R:
このビットは送信者がHOKEY再認証[I-D.ietf-hokey-erx]をサポートすることを示すように設定される。このビットは最後のリクエスト/EXTメッセージに設定される(即ち、Fビットを有するリクエスト/EXTが設定される)と、メッセージはサーバID TLV及びピアID TLVを含める必要があり、Reauth-Key-Lifetime AVPを含めることができる。このビットは最後のリクエスト/EXT及びレスポンス/EXT交換に設定されると、ピア及びサーバはHOKEY−REAUTH−KEYを生成する必要がある。サーバID及びピアIDはサーバID及びピアID TLVsに含まれ、HOKEY−REAUTH−KEYはHOKEY再認証に使用される。
【0129】
C:
このビットは送信者がMSK用チャネル結合機構をサポートしていることを示すように設定される。このビットはリクエスト/EXTメッセージに設定されると、1つのチャネル結合機構(Channel-Binding-Mechanism)TLVもサーバによってサポートされる1つ以上のチャネル結合機構を示すように含める必要がある。ピアがサーバによってサポートされる1つ以上のチャネル結合機構の1つをサポートし、可能にしたければ、それはこのビットセットを持つレスポンス/EXTメッセージ及び選択チャネル結合機構を含む1つのチャネル結合機構TLVを送信する。このビットが1つのチャネル結合機構の成功した交渉によって最後のリクエスト/EXT及びレスポンス/EXT交換に設定され、EAP−EXTメソッドが首尾よく完了すれば、ピア及びサーバは取り決めチャネル結合機構を可能にする必要がある。
【0130】
他のビットは将来の使用のために予約され、送信者によってゼロに設定する必要があり、受信者によって無視される必要がある。
【0131】
TLV:
ゼロ、1以上のTLVs(Type-Length-Value’s)。そのTLVフォーマットは図3(C)に示される実施形態と同様である図6(C)に示されるようである。
【0132】
タイプ:
このフィールドはこのTLVのタイプを示す。
【0133】
長さ:
このフィールドはTLVのタイプ及び長さフィールドを含めてこのTLVの長さをオクテットで示す。
【0134】
値:
このフィールドはTLVタイプに特定するデータを含む。
【0135】
EAP−EXT TLVs:
これらの実施形態では、次のTLVsが定義される。
【0136】
a. メソッドTLV
メソッドTLV(タイプ1)はタイプフィールドから開始するEAPメソッドペイロードを含む。
【0137】
b. AUTH TLV
AUTH TLV(タイプ2)はEAP−EXTメッセージをサポートするために使用される完全性データを含む。EAP−EXT−AUTH−KEYはAUTH TLVsを計算するために使用される。TLV値フィールドはこのフィールドを含む全体のEAPメッセージにわたり計算される。完全性データを計算する前に、このフィールドは全てゼロに初期化する必要がある。このフィールドの長さは使用時に完全性アルゴリズムに依存する。完全性チェックが失敗すると、メッセージは静かに破棄する必要がある。デフォルト完全性アルゴリズムはHMAC−SHA−256[sha256]である。
【0138】
c. ピアID TLV
ピアID TLV(タイプ3)はHOKEY再認証に使用されるピアの識別を含む。
【0139】
d. サーバID TLV
サーバID TLV(タイプ4)はHOKEY再認証に使用されるサーバの識別を含む。
【0140】
e. Reauth−Key−Lifetime TLV
Reauth−Key−Lifetime TLV(タイプ5)は秒単位でHOKEY−REAUTH−KEYの寿命を含む。
【0141】
f. PRF TLV
PRF TLV(タイプ6)は[I-D.ietf-hokey-emsk-hierarchy]で定義される1以上の1−オクテット数を含む。このTLVがリクエストに運び込まれると、それはサーバによってサポートされる1以上のPRF数を示す。
【0142】
このTLVがリクエスト/EXTメッセージに運び込まれると、対応するレスポンス/EXTメッセージがこのTLVを含むことができる。レスポンス/EXT内のPRF TLVはリクエスト/EXTメッセージのPRF数の中の、ピアによってサポート及び選択される1つのPRF数を正確に含める必要がある。PRF数が上述されたPRF TLV交換を用いて首尾よく取り決められれば、取り決められた数がEAP−EXT及びUSRKsによって転送されるEAPキーイングマテリアルを得るためにKDFに使用される。そうでなければ、[I-D.ietf-hokey-emsk-hierarchy]で特定されたデフォルトPRFがKDFに使用される。
【0143】
g. チャネル結合機構TLV
チャネル結合機構TLV(タイプ7)1以上の1−オクテットチャネル結合機構数を含む。このTLVがリクエスト/EXTメッセージに運び込まれると、それはサーバによってサポートされる1以上のチャネル結合機構数を示す。このTLVがリクエスト/EXTメッセージに運び込まれると、対応するレスポンス/EXTメッセージはこのTLVを含めることができる。レスポンス/EXTメッセージのチャネル結合機構TLVはリクエスト/EXTメッセージのチャネル結合機構数の内の、ピアによってサポートされ、選択される1つのチャネル結合機構数を正確に含める必要がある。チャネル結合機構は上述したチャネル結合機構TLV交換を用いて首尾よく取り決められれば、取り決めチャネル結合機構が可能となる。
【0144】
以下のチャネル結合機構数はこの明細書において定義されている。即ち、機構1 - [I-D.ohba-eap-channel-binding]及び機構2 - [arkko-eap-service-identity-auth]。
【0145】
チャネル結合機構1について、prf+用デフォルトハッシュアルゴリズムはPRF_HMAC_SHA2_256である。
【0146】
チャネル結合機構2について、追加チャネル結合データTLVがリクエスト及びレスポンスに運び込まれる。
【0147】
h. チャネル結合データTLV
チャネル結合データTLV(タイプ8)は[arkko-eap-service-identity-auth]に使用されるオクテットストリングデータを含む。
【0148】
i. 暗号化アルゴリズムTLV
暗号化アルゴリズムTLVは暗号化TLVsを暗号化するために使用される暗号化アルゴリズムの取り決めを可能にする。このTLVはリクエスト/EXTに運び込まれると、それはEAPサーバによってサポートされる暗号化アルゴリズムを示す。このTLVがリクエスト/EXTメッセージに運び込まれると、対応するレスポンス/EXTメッセージはこのTLVを含むことができる。レスポンス/EXTメッセージの暗号化アルゴリズムTLVはリクエスト/EXTメッセージに含まれる暗号化アルゴリズムTLVのオプション内の、ピアによってサポートされ、選択された1つの暗号化アルゴリズム数を正確に含める必要がある。EAPサーバはデフォルト暗号化アルゴリズム(AES−CBC−128)を使用するためEAPピアを強制できることに留意する。そのような場合、EAPピアはリクエスト/EXTメッセージに暗号化アルゴリズムTLVを含めなく、同様に、EAPピアはレスポンス/EXTメッセージにもそれを含めない。参考のため、図7(A)は暗号化アルゴリズムTLVを示している。
【0149】
それは次のように定義された1以上の1−オクテット数を含む。
【0150】
0 予約
1 AES−CBC−128(デフォルト)
2 AES−CBC−256
3 3DES
4 IDEA
アルゴリズムは暗号化アルゴリズムTLVを用いて首尾よく交渉できなければ、デフォルト暗号化アルゴリズムが代わりに使用される。
【0151】
j. 完全性アルゴリズムTLV
EAP−EXTメソッドは簡単にするために及び競り下げ攻撃(bidding-down attacks)を避けるために完全性アルゴリズム取り決めを可能にしない。しかしながら、EAPサーバは異なる完全性アルゴリズムから選択でき、完全性アルゴリズムTLVを介してこの選択についてEAPピアに知らせる。EAPサーバがこのTLVを含んでいなければ、デフォルト値がHMAC−SHA−256となる。参考のため、図7(B)は完全性アルゴリズムTLVを示している。
【0152】
それは次のリストに定義された1以上の1−オクテット数を含む。
【0153】
0 予約
1 HMAC−SHA−1
2 HMAC−SHA−224
3 HMAC−SHA−256(デフォルト)
4 HMAC−SHA−384
5 HMAC−SHA−512
k. 暗号化TLV
暗号化TLV(タイプ10)はEAP−EXT−ENC−KEYによって暗号化された1以上の標準文字を含む。このフィールドの長さは使用時に暗号化アルゴリズムに依存する。図7(C)を参照する。
【0154】
それは次のように定義された1以上の1−オクテット数を含む。
【0155】
タイプ:
(10) 暗号化TLV
長さ:
4+IV長+暗号化データ長.
IV:
IVは最初が最上位ビットであるランダムビットのオクテットストリングである。IVの長さは使用時の暗号化アルゴリズムに依存する。例えば、AES−CBC−128について、IVは16バイト(128ビット)である。
【0156】
暗号化データ
可変長の暗号化TLV。暗号化データはEAP−EXT−ENC−KEによって暗号化された1以上の標準文字TLVsから成る。暗号化アルゴリズム及び標準文字データの長さに依存して、暫定データが暗号化動作の以前に標準文字データに加算できる。
【0157】
セキュリティ上の配慮
内部EAPメソッドがEAPキーイングマテリアルを転送する前の能力交換はサポートされない。故に、EAPキーイングマテリアルの生成後の追加サポートメッセージ交換はピア及びサーバによって検出されないで能力情報が攻撃者によって変更されることを回避するために義務付けられる。
【0158】
EAP−EXTはその内部の複数のEAPメソッドの順序付けを可能にする。複数の入れ子又は順序付けられた認証メソッドを暗号的に結合しないでそれらにより構成される組合せ認証メソッドはman-in-the-middle攻撃に対しては脆弱である。EAP−EXTはシーケンス内での先に成功した内部メソッドによって生成されるキーによって外部EAPメソッド(即ち、EAP−EXT)と共に各内部EAPメソッドをサポートし、最後に成功した内部EAPメソッドによって生成されるキーから得られるEAPキーイングマテリアルを転送することによって必要暗号化結合を作ることができる。暗号化結合を達成するために、EAP−EXTはEAPキーイングマテリアル生成できる内部EAPメソッドを必要とする。
【0159】
このメソッドは内部メソッドのMSKから算出されるMSK及びEMSKを転送する。故に、転送されたMSK及びEMSKの全体の長さは内部メソッドのMSKの長さと同じである。
【0160】
本発明の広い範囲
本明細書では、本発明の例示的実施形態を説明しているが、本発明は、本明細書で説明した様々な好ましい実施形態だけに限定されず、本開示に基づけば当分野の技術者によって理解されるはずの、等価の要素、改変、省略、(様々な実施形態にまたがる態様などの)組合せ、適合及び/又は変更を有するありとあらゆる実施形態を含むものである。特許請求の範囲における限定は、特許請求の範囲で用いられる言葉に基づいて幅広く解釈されるべきであり、本明細書において、又は本出願の出願中において記述される例だけに限定されず、これらの例は、非排他的であると解釈されるべきである。例えば、本開示において、「好ましくは」という用語は、非排他的であり、「それだけに限らないが、好ましくは」を意味する。本開示において、かつ本出願の出願中において、手段プラス機能又はステッププラス機能限定は、特定のクレーム限定について、この限定において、a)「〜の手段」又は「〜のステップ」が明記されている、b)対応する機能が明記されている、及びc)構造、材料又はこの構造をサポートする動作が記載されていないという条件すべてが存在する場合に限り用いられる。本開示において、かつ本出願の出願中において、「本発明」又は「発明」という用語は、本開示内の1つ又は複数の態様を指すものとして使用され得る。本発明又は発明という言葉は、誤って重要度の識別と解釈されるべきではなく、誤ってすべての態様又は実施形態にわたって適用されるものと解釈されるべきではなく(すなわち、本発明はいくつかの態様及び実施形態を有すると理解されるべきであり)、また、誤って本出願又は特許請求の範囲を限定するものと解釈されるべきではない。本開示において、かつ本出願の出願中において、「実施形態」という用語は、任意の態様、特徴、プロセス又はステップ、これらの任意の組合せ、及び/又はこれらの任意の部分などを記述するのに使用され得る。いくつかの例では、様々な実施形態が重なり合う特徴を含み得る。本開示では、「例えば」を意味する「e.g.」という省略用語が用いられ得る。
【技術分野】
【0001】
本発明は、無線ネットワーク、幾つかの好適実施形態では、ピアとサーバとの間で一貫性維持のために照合されるパラメータをチャネル結合するシステム及び方法に関する。
【背景技術】
【0002】
ネットワーク及びインターネット(登録商標)プロトコル
多様なコンピュータネットワークがあり、インターネットは最も有名である。インターネットは、コンピュータネットワークの世界規模のネットワークである。今日、インターネットは、何百万人ものユーザが利用可能な、公衆の自律的ネットワークである。インターネットは、TCP/IP(すなわち、伝送制御プロトコル/インターネットプロトコル)と呼ばれる1組の通信プロトコルを使って各ホストを接続する。インターネットは、インターネットバックボーンとして呼ばれる通信インフラストラクチャを有する。インターネットバックボーンへのアクセスは大部分企業及び個人へのアクセスを再販するインターネットサービスプロバイダ(ISP)によって制御される。
【0003】
IP(インターネットプロトコル)に関して、これは、ネットワーク上である装置(電話機、PDA[携帯情報端末]、コンピュータなど)から別の装置にデータを送るためのプロトコルである。今日、IPv4、IPv6などを含めて、様々なIPのバージョンがある。ネットワーク上の各ホスト装置は、独自の一意の識別子である少なくとも1つのIPアドレスを有する。
【0004】
IPはコネクションレス型プロトコルである。通信時の端点間接続は連続的ではない。ユーザがデータ又はメッセージを送信し、又は受信するとき、データ又はメッセージは、パケットと呼ばれる構成要素に分割される。各パケットは、独立のデータ単位として扱われる。
【0005】
インターネットなどのネットワークを介した各点間の伝送を標準化するために、OSI(開放型システム間相互接続)モデルが確立された。OSIモデルは、ネットワーク中の2点間の通信プロセスを7つの階層に分け、各層(レイヤ)は独自の機能セットを付加する。各装置は、送信側端点では各層を通る下方への流れがあり、受信側端点では各層を通る上方への流れがあるようにメッセージを処理する。7つの機能層を提供するプログラミング及び/又はハードウェアは、通常、デバイスオペレーティングシステム、アプリケーションソフトウェア、TCP/IP及び/又は他のトランスポート及びネットワークプロトコル、並びに他のソフトウェア及びハードウェアの組み合わせである。
【0006】
通常、上位4層は、メッセージがユーザから、又はユーザへ渡されるときに使用され、下位3層は、メッセージが装置(IPホスト装置など)を通過するときに使用される。IPホストは、サーバ、ルータ、ワークステーションなど、IPパケットを送受信することのできるネットワーク上の任意の装置である。他の何らかのホストに向けられているメッセージは、各上位層には渡されず、この他のホストに転送される。OSIモデルの各層を以下に列記する。第7層(すなわち、アプリケーション層)は、例えば、通信相手が識別され、サービス品質が識別され、ユーザ認証及びプライバシが考慮され、データ構文に対する制約条件が識別される層である。第6層(すなわち、プレゼンテーション層)は、例えば、着信及び発信データをあるプレゼンテーション形式から別の形式に変換する層である。第5層(すなわち、セッション層)は、例えば、アプリケーション間の会話、交換及びダイアログをセットアップし、調整し、終了させる層である。第4層(すなわち、トランスポート層)は、例えば、エンドツーエンド制御及び誤りチェックなどを管理する層である。第3層(すなわち、ネットワーク層)は、例えば、経路指定や転送などを処理する層である。第2層(すなわち、データリンク層)は、例えば、物理レベルでの同期を提供し、ビットスタッフィングを行い、伝送プロトコルの知識及び管理などを提供する層である。米国電気電子技術者協会(IEEE)では、データリンク層を、物理層との間のデータ転送を制御するMAC(媒体アクセス制御)層と、ネットワーク層とのインターフェースを取り、コマンドを解釈し、誤り回復を行うLLC(論理リンク制御)層という、2つのさらなる副層(サブレイヤ)に細分する。第1層(すなわち、物理層)は、例えば、物理レベルにおいてネットワークを介してビットストリームを伝達する層である。IEEEでは、物理層を、PLCP(物理層収束手順)副層とPMD(物理媒体依存)副層とに細分する。
【0007】
無線ネットワーク:
無線ネットワークは、例えば、セルラ及び無線電話機、PC(パーソナルコンピュータ)、ラップトップコンピュータ、装着型コンピュータ、コードレス電話機、ポケットベル、ヘッドセット、プリンタ、PDAなど、多種多様なモバイル機器を組み込むことができる。例えば、モバイル機器は、音声及び/又はデータの高速無線伝送を確保するデジタルシステムを含むことができる。一般的なモバイル機器は、次の構成要素の一部又は全部、即ち送受信機(すなわち、例えば、送信機、受信機及び、必要に応じて、他の機能が統合されたシングルチップ送受信機などを含む、送信機及び受信機)、アンテナ、プロセッサ、1つ又は複数の音声変換器(例えば、音声通信用機器でのスピーカやマイクロホンなど)、電磁データ記憶(データ処理が提供される機器の場合などでの、ROM、RAM、デジタルデータ記憶など)、メモリ、フラッシュメモリ、フルチップセット又は集積回路、インターフェース(USB、CODEC、UART、PCMなど)及び/又は同種のものを含む。
【0008】
モバイルユーザが無線接続を介してローカルエリアネットワーク(LAN)に接続することのできる無線LAN(WLAN)が、無線通信に用いることができる。無線通信には、例えば、光、赤外線、電波、マイクロ波などの電磁波を介して伝搬する通信などが含めることができる。現在、ブルートゥース(登録商標)、IEEE802.11、HomeRFなど、様々なWLAN標準が存在する。
【0009】
一例として、ブルートゥース製品は、モバイルコンピュータ、モバイル電話機、携帯式ハンドヘルド機器、携帯情報端末(PDA)、及び他のモバイル機器の間のリンク、並びにインターネットへの接続を提供するのに使用できる。ブルートゥースは、モバイル機器が、短距離無線接続を使って、相互に、また非モバイル機器と、どのようにして容易に相互接続し合うことができるかを詳述するコンピュータ及び電気通信業界仕様である。ブルートゥースは、ある機器と別の機器との間でデータを同期させ、整合させ続けることを必要とする、様々なモバイル機器の普及から生じるエンドユーザ問題に対処して、異なるベンダからの装置を相互にシームレスに動作させるデジタル無線プロトコルを作成する。ブルートゥース機器は、共通の名称概念に従って名称付けできる。例えば、ブルートゥース機器は、ブルートゥース機器名(BDN)又は一意のブルートゥース機器アドレス(BDA)に関連付けられた名称を持ち得る。また、ブルートゥース機器は、インターネットプロトコル(IP)ネットワークに参加することもできる。ブルートゥース機器がIPネットワーク上で機能する場合、この機器は、IPアドレス及びIP(ネットワーク)名を備えることができる。よって、IPネットワークに参加するように構成されたブルートゥース機器は、BDN、BDA、IPアドレス及びIP名などを含むことができる。「IP名」という用語は、インターフェースのIPアドレスに対応する名称を指す。
【0010】
IEEE標準であるIEEE802.11は、無線LAN及び機器の技術の仕様を定める。802.11を使えば、各単一基地局がいくつかの機器をサポートする無線ネットワークが実現できる。いくつかの例では、機器に無線ハードウェアが事前装備されていることもあり、ユーザが、アンテナを含めることができ、カードなどの別個のハードウェアをインストールすることもできる。例えば、802.11で使用される機器は、通常、機器がアクセスポイント(AP)であるか、移動局(STA)であるか、ブリッジであるか、PCMCIAカードであるか、それとも別の機器であるか否かを問わず、無線送受信機、アンテナ、及びネットワークにおける各点間のパケットの流れを制御するMAC(媒体アクセス制御)層という3つの注目すべき要素を含む。
【0011】
更に、いくつかの無線ネットワークでは、複数インターフェース機器(MID)が利用できる。MIDは、ブルートゥースインターフェースと802.11インターフェースなど、2つの独立のネットワークインターフェースを含むことができ、よって、MIDが2つの別個のネットワーク上に参加すると同時に、ブルートゥース機器ともインターフェースすることが可能になる。MIDは、IPアドレス、及びIPアドレスに関連付けられた共通IP(ネットワーク)名を持つことができる。
【0012】
無線ネットワーク機器には、それだけに限らないが、ブルートゥース機器、複数インターフェース機器(MID)、802.11x機器(802.11a、802.11b、802.11g機器などを含む、IEEE802.11機器)、HomeRF(家庭内無線周波数)機器、Wi−Fi(Wireless Fidelity)機器、GPRS(汎用パケット無線システム)機器、3Gセルラ機器、2.5Gセルラ機器、GSM(登録商標)(移動通信用グローバルシステム)機器、EDGE(Enhanced Data for GSM Evolution)機器、TDMA型(時分割多重接続)機器、又はCDMA2000を含むCDMA型(符号分割多重接続)機器が含めることができる。各ネットワーク機器は、それだけに限らないが、IPアドレス、ブルートゥース機器アドレス、ブルートゥース共通名、ブルートゥースIPアドレス、ブルートゥースIP共通名、802.11IPアドレス、802.11IP共通名、IEEE MACアドレスを含む、様々な種類のアドレスを含むことができる。
【0013】
また、無線ネットワークは、例えば、モバイルIP(インターネットプロトコル)システム、PCSシステム、及び他のモバイルネットワークシステムにおいて見られるメソッド及びプロトコルも関与できる。モバイルIPでは、これに、インターネット技術標準化委員会(IETF)によって作成された標準通信プロトコルが関与する。モバイルIPでは、モバイル機器ユーザは、これらの一旦割り当てられたIPアドレスを維持しつつ、各ネットワークにまたがって移動することができる。コメントリクエスト(RFC)3344を参照されたい。(注:RFCはインターネット技術標準化委員会(IETF)の公式文書である。)モバイルIPは、インターネットプロトコル(IP)を拡張し、モバイル機器のホームネットワーク外部に接続するときに、モバイル機器にインターネットトラフィックを転送する手段を付加する。モバイルIPは、各モバイルノードに、これのホームネットワーク上のホームアドレスと、ネットワーク及びこれのサブネット内の機器の現在位置を識別する気付アドレス(CoA)を割り当てる。機器が異なるネットワークに移動すると、機器は、新しい気付アドレスを受け取る。ホームネットワーク上のモビリティエージェントは、各ホームアドレスを、これの気付アドレスと関連付けることができる。モバイルノードは、インターネット制御メッセージプロトコル(ICMP)などを使って、これの気付アドレスを変更する都度ホームエージェントにバインディング更新を送ることができる。
【0014】
(例えば、モバイルIP外部などの)基本的なIP経路指定において、経路指定機構は、各ネットワークノードが、常に、インターネットなどへの一定の接続点を有し、かつ各ノードのIPアドレスが、これが接続されているネットワークリンクを識別するという仮定を利用する。本明細書において、「ノード」という用語は、例えば、データ伝送のための再配信点や端点などを含むことができ、他のノードへの通信を認識し、処理し、及び/又は転送することのできる接続点を含む。例えば、インターネットルータは、機器のネットワークを識別するIPアドレスなどを調べることができる。次いで、ネットワークレベルにおいて、ルータは、特定のサブネットを識別するビットセットを調べることができる。次いで、サブネットレベルにおいて、ルータは、特定の機器を識別するビットセットを調べることができる。一般的なモバイルIP通信の場合、ユーザが、例えば、インターネットなどからモバイル機器を切断し、これを新しいサブネットで再接続しようとする場合、機器は、新しいIPアドレス、適正なネットマスク及びデフォルトのルータを用いて再構成する必要がある。そうでなければ、経路指定プロトコルは、パケットを適正に配信することができないはずである。
【0015】
メディア独立の事前認証:
メディア独立の事前認証(MPA)は、任意のリンク層を介して、任意のモビリティ管理プロトコルと共に動作する、モバイル支援型の、安全なハンドオーバ最適化方式である。MPAを用いれば、移動ノードは、候補ターゲットネットワーク(CTN)のIPアドレスと他の構成パラメータを安全に獲得することができるだけでなく、CTNに実際に接続する前に、獲得したIPアドレスを使ってIPパケットを送受信することもできる。これは、移動ノードが、リンク層におけるハンドオーバを実行する前に、任意のモビリティ管理プロトコルの対応付け更新を完了し、新しい気付アドレス(CoA)を使用することを可能にする。
【0016】
MPAは、任意のリンク層を介して、モバイルIPv4、モバイルIPv6、MOBIKE、HIP、SIPモビリティなどを含む任意のモビリティ管理プロトコルと共に動作する。MPAでは、IEEE802.11i事前認証の概念が、上位層で動作するように拡張され、移動端末がそこに移動できるネットワークからのIPアドレスの早期獲得と、移動端末がまだ現在のネットワークに接続されている間にネットワークへの事前対応型ハンドオーバとを実行する追加機構を組み込んでいる。
【0017】
MPAをサポートする移動ノード(MN)は、認証エージェント(AA)との事前認証プロセスを開始する。正常な認証により、PANA認証エージェント(PAA)が、AAとセキュリティアソシエーションを確立することが可能になる。これが、IPアドレスと他の構成パラメータを移動ノードに安全に配信するための構成プロトコルを安全に実行するのに使用される構成エージェント(CA)と、移動ノードへの事前対応型ハンドオーバトンネルを確立するためのトンネル管理プロトコルを安全に実行するアクセスルータ(AR)に加わる。この全プロセスが、MNが現在の接続点に接続されるときに実行される。これは、参照によりこれの開示が本明細書に組み込まれる、2006年3月の「draft-ohba-mobopts-mpa-framework-02.txt」と、2006年10月22日の「draft-ohba-mobopts-mpa-framework-03.txt」で詳細に説明されている。
【0018】
安全なネットワークアクセスサービスを提供することは、クライアントとアクセスネットワークの認証と許可に基づくアクセス制御を必要とする。クライアントからネットワークへの認証は、実行点を通るトラフィックフローを規制するのに必要とされるパラメータを提供する。クライアントとアクセスネットワークの間で認証メソッドを搬送するプロトコルが必要とされる。
【0019】
PANAは、ネットワークアクセス認証メソッドのためのリンク層不可知トランスポートを提供する。拡張可能認証プロトコル(EAP)[参照により全体が本明細書に組み込まれるRFC3748を参照]は、かかる認証メソッドを提供する。これに関して、PANAは、様々な認証メソッドを搬送することのできるEAPを搬送する。IPより上でのEAPのトランスポートを可能にすることによって、EAPメソッドとして伝えることができる任意の認証メソッドがPANAに利用でき、故に任意のリンク層技術に利用できる。
【0020】
PANAプロトコル[I-D.ietf-pana-pana]は、アクセスネットワーク内のPaC(PANAクライアント)とPAA(PANA認証エージェント)の間でEAPメッセージを伝送する。PaCがモバイル機器であり、これのアプリケーションを実行する間に、あるアクセスネットワークから別のアクセスネットワークに移動することができる場合、このPaCが、ハンドオーバ期間中にアプリケーションの性能を低下させずに、シームレスにハンドオーバを行うことは重要である。PaCが新しいアクセスネットワーク内のPAAとPANAセッションを確立することをハンドオーバが必要とするとき、PANAセッションを確立する信号は、できるだけ速く完了されるべきである。
【0021】
PANAプロトコルは、ネットワークアクセスサービスのための認証と許可を行うために、クライアント(PaC)とサーバ(PAA)の間で実行される。このプロトコルのメッセージングは、一連のリクエストとレスポンスを伴い、これらのうちのいくつかが、どちらかの側によって開始できる。各メッセージは、ペイロード内でゼロ以上のAVPを伝送することができる。PANAの主要ペイロードは、認証を実行するEAPである。PANAは、PaCとPAAが、EAPセッションを確立するのに役立つ。
【0022】
他の背景情報として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.を参照する。この文献の全開示はここに全て開示されているように参照により本明細書に援用される。
【0023】
EAP
(以下に引用する)Aboba, RFC 3748を参照すると、拡張認証プロトコル(EAP)の具体的態様が説明されている。EAPは複数の認証メソッドをサポートする認証フレームワークである。EAPは一般的にはIPを必要としない、ポイントツーポイントプロトコル(PPP)又はIEEE802のような複数のデータリンク層上で直接に実行する。EAPは二重削除及び再送信のため独自のサポートを備えているが、下位層順の保証に依存する。断片化はEAP自体内でサポートされないが、個々のEAPメソッドがこれをサポートできる。
【0024】
EAPは切換回路だけでなく、専用リンクに使用でき、無線リンクだけでなく有線であってもよい。今まで、EAPはPPP[RFC1661]を用いて切換回路又はダイアルアップネットワークを介して接続するホスト及びルータによって実現されていた。それはまたIEEE 802[IEEE−802]を用いてスイッチ及びアクセスポイントによっても実現されていた。IEEE 802有線媒体に関するEAPカプセル化が[IEEE-802.1X]に説明されており、IEEE無線LANsに関するカプセル化は[IEEE-802.11i]に開示されている。
【0025】
EAPアーチテクチャの利点の1つはその柔軟性にある。EAPは、特定の認証機構を選択するために用いられ、その際、Authenticatorが使用すべき特定の認証メソッドを決定するためにピアに対しより多くの情報を要求する。各新しい認証メソッドをサポートするために更新されることをAuthenticatorが必要とすることなく、EAPは幾つか又は全てのメソッドおよびピアに対するパススルーとして動作するAuthenticatorによって、幾つか又は全ての認証メソッドを実施できるバックエンド認証サーバの使用を可能にする。
【0026】
この後者の引用文献の中で、Authenticatorがパススルーとして動作するか否かに関係なくAuthenticatorの要求が適用される。要求がAuthenticator又はバックエンド認証サーバのいずれかに適用されることを意味している場合、EAP認証が終了される場所に依存して、用語「EAPサーバ」が使用されている。
【0027】
EAPはメッセージの再送信をサポートする一方で、それは下位層によって提供される順序付け保証を仮定し、故にメッセージの到達順序に異常のある受信はサポートされない。
【0028】
EAPはメッセージの断片化(フラグメンテーション)及び再構築(リアセンブリ)をサポートしないので、最小EAP MTUより大きなペイロードを生成するEAP認証メソッドは断片化サポートを提供する必要がある。
【0029】
EAP−TLSのような認証メソッドはメッセージの断片化及び再構築を提供するが、この後者の引用文献で定義されたEAPメソッドは行わない。その結果、EAPパケットサイズがリンクのEAP MTUを越えれば、これらのメソッドは困難に合うことになる。
【0030】
EAP認証はサーバ(Authenticator)によって初期化されるが、多くの認証プロトコルはクライアント(ピア)によって初期化される。その結果、EAPを通過するために1つ又は2つの追加メッセージ(多くとも1往復)を追加することが認証アルゴリズムに必要となるかもしれない。
【0031】
証明利用認証がサポートされる場合、追加往復の数は証明書連鎖(certificate chains)の断片化によりかなり多くなるかもしれない。一般的に、断片化EPAパケットは断片があるだけ多くの往復で送る必要がある。例えば、サイズが14960オクテットの証明連鎖は1496オクテットEAP MTUで10往復する必要がある。EAPが重大なパケットロスを起こす下位層上で動作する場合、又はAuthenticatorと認証サーバとの接続が重要なパケットロスを起こす場合、多くの往復を必要とするEAPメソッドは困難に直面することもある。これらの状況において、少ない往復を用いたEAPメソッドの使用が望まれる。
【0032】
EAP認証交換は次のように処理される。即ち、
[1]Authenticatorはピアを認証するためリクエスト(Request)を送る。リクエストは要求されているものを示すタイプフィールドを有する。リクエストタイプの例は識別、MD5−チャレンジなどを含む。MD5−チャレンジタイプはCHAP認証プロトコルに密接に対応する[RFC1994参照]。一般的には、Authenticatorは初期認証リクエストを送ることになるが、初期認証リクエストは必要とされなく、バイパスされないこともある。例えば、識別はピアが接続されているポート(専用回線、専用スイッチ又はダイアルアップポート)によって決定される場合、又は識別が(MD5−チャレンジレスポンスなどのネームフィールドにおいて、呼出局識別又はMACアドレスを介して)他のメソッドで得られる場合には要求されないこともある。
【0033】
[2]ピアは有効リクエストに答えてレスポンスパケット(Response packet)を送る。リクエストパケットと同様に、レスポンスパケットはリクエストのタイプフィールドに対応するタイプフィールドを含む。
【0034】
[3]Authenticatorは追加リクエストパケットを送り、ピアはレスポンスで答える。リクエスト及びレスポンスのシーケンスは必要なだけ継続する。EAPは‘横並び(lock step)’プロトコルであり、故に、初期リクエスト以外は、新たなリクエストは有効なレスポンスを受理する前に送ることができない。Authenticatorはリクエストを再送信する責任がある。適正数の再送信の後には、AuthenticatorはEAP対話を終了しなくてはならない。Authenticatorは再送信したとき、又はピアからのレスポンスが得られないときには成功又は失敗パケットを送る必要がない。
【0035】
[4]対話はAuthenticatorがピア(1以上のリクエストに対して受入れがたいレスポンス)を認証できなくなるまで続けられる。この場合、Authenticatorの実行にはEAP失敗(コード4)を送信する必要がある。あるいは、認証対話は認証が成功したことをAuthenticatorが決定するまで継続する。この場合、AuthenticatorはEAP成功(コード3)を送信する必要がある。
【0036】
他の利点では、EAPプロトコルは特定のものを事前取り決めする必要が無く多くの認証機構をサポートできる。更に、ネットワークアクセスサーバ(NAS)装置(例えば、スイッチ又はアクセスポイント)は各認証メソッドを理解する必要が無く、バックエンド認証サーバに対するパススルーエージェントとして動作できる。パススルーのためのサポートは随意的である。Authenticatorは局所ピアを認証でき、更に、同時に非局所ピア及び局所的には実行しない認証メソッドに対するパススルーとして作用する。更に、バックエンド認証サーバからAuthenticatorを分離することによって証明管理及びネットワークアクセスポリシー決定を簡単にする。
【0037】
概念的に、EAP実施は次の要素からなる。
【0038】
[a]下位層。下位層はピアとAuthenticatorとの間でEAPを送受信する義務がある。EAPはPPP,有線IEEE802ラン[IEEE-802.1X], IEEE 802.11 wireless LANs [IEEE-802.11], UDP (L2TP [RFC2661]及びIKEv2参照)及びTCPを含む各種下位層上で実行していた。
【0039】
[b]EAP層。EAP層は下位層を介してEAPパケットを送受信し、二重検出及び再送信を実行し、EAPメッセージをEAPピア及びAuthenticator層に搬送し及びAuthenticator層から受信する。
【0040】
[c]EAPピア及びAuthenticator層。コードフィールドに基づいて、EAP層は入力EAPパケットをEAPピア及びAuthenticator層に分離する。一般的には、所定ホストでのEAP実行はピア又はAuthenticator機能のいずれかをサポートすることになるが、ホストがEAPピア及びAuthenticatorの両方として作用することを可能にする。そのような実行においては、EAP及びAuthenticator層の両方が存在することになる。
【0041】
[d]EAPメソッド層。EAPメソッドはAuthenticatorアルゴリズムを実行し、EAPピア及びAuthenticator層を介してEAPメッセージを送受信する。断片化のサポートはEAP自体によっては得られないが、これはEAPメソッドの責任である。
【0042】
以後の参考文献はここに参照として引用される次の定義を説明している。
【0043】
Authenticator
EAP認証を初期化するリンクの終端。Authenticatorという用語は[IEEE-802.1X]に使用され、この明細書では同様の意味を有する。
【0044】
ピア
Authenticatorに応答するリンクの終端。[IEEE-802.1X]では、この終端はSupplicantとして知られている。
【0045】
バックエンド認証サーバ
バックエンド認証サーバは認証サービスをAuthenticatorに提供する個人である。使用時には、このサーバは一般的にはAuthenticatorのためにEAPメソッドを実行する。この専門用語は[IEEE-802.1X]に使用されている。
【0046】
AAA
EAPサポートを持つ認証、許可、及び課金(AAA)プロトコルはRADIUS及びダイアミタ(Diameter)を含む。この明細書では、用語“AAAサーバ”及び“バックエンド認証サーバ”は交換可能に使用される。
【0047】
EAPサーバ又はサーバ
ピアによってEAP認証メソッドを終了する個人バックエンド認証サーバが使用されない場合には、EAPサーバはAuthenticatorの一部である。Authenticatorがパススルーモードで行動する場合、EAPサーバはバックエンド認証サーバに設けられる。
【0048】
成功した認証
この明細書の内容では、「成功した認証」はEAPメッセージの交換であり、その結果Authenticatorはピアによってアクセスできることを決定し、ピアがこのアクセスを使用することを決定する。Authenticatorの決定は一般的には認証及び許可面の両方を含み、ピアはAuthenticatorに首尾良く証明できるが、アクセスは政策的理由によりAuthenticatorによって拒絶されるかもしれない。
【0049】
マスタセッションキー(MSK)
EAPピアとサーバ間で得られ、EAP法によって転送されるキーイングマテリアル。MSKは長さが少なくとも64オクテットである。既存の実施では、EAPサーバとして作用するAAAサーバはMSKをAuthenticatorに搬送する。
【0050】
拡張マスタセッションキー(EMSK):
EAPクライアントとサーバ間で得られ、EAP法によって転送される追加キーイングマテリアル。EMSKは長さが少なくとも64オクテットである。EMSKはAuthenticator又は任意の他の第三者によっては共有されない。EMSKはまだ定義されていない将来の使用のために予約される。
【0051】
EAP拡張
参考のため、出願人は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を参照する。この参考文献は次のようにEAP再認証プロトコルのためのEAP拡張を説明している。拡張可能認証プロトコルは2つのグループを認証するメソッドの搬送のための総括フレームワークであり、認証は一方向又は相互のいずれかである。第1目的はネットワークアクセス制御であり、キー生成メソッドはアクセス制御を実施するために推奨される。EAPキーイング階層は2つのキーを定義する。これらのキーはトップレベルで、即ちマスタキーセッション(MSK)及び拡張MSK(EMSK)で得られる。最も一般的な展開シナリオにおいては、ピア及びサーバはAuthenticatorとして知られている第三者を介して互いに認証する。Authenticator又はAuthenticatorによって管理される個人はアクセス制御を実施する。成功した認証後には、サーバはMSKをAuthenticatorに搬送し、Authenticator及びピアはMSKを認証キー又はキー導出キーとして用いて一時セッションキー(TSK)を取得し、単位パケットアクセス実施のためにTSKを使用する。ピアがあるAuthenticatorから他のAuthenticatorに移動するときは、完全EAP認証を避けることが望ましい。EAPメソッドの他の実施を伴う完全EAP交換は完了するためにいくつかの往復及びかなりの時間を取り、ハンドオフ時間に遅延が生じる。幾つかのEAP法は計算オーバヘッドを減じることによって再認証を最適化するために初期認証から状態の使用を特定し、メソッド特定再認証は殆どのケースでは少なくとも2往復する。多くのメソッドは再認証のためにサポートを提供しないことに注意することが重要でもある。故に、個々のメソッドにおけるよりもEAPにおいて効果的な再認証サポートを持つのが良い。
【0052】
Authenticator間で共有するキーは時々ハンドオフタイムを低減するため現実的な解決法として使用される。その場合、Authenticatorの譲歩は他のAuthenticatorを介して確立されるEAPセッションの譲歩となる。要するに、再びEAPメソッドを実行することを必要としないでピアとAuthenticator間にフレッシュキーを確立することを可能にする有効EAP再認証機構を設計する必要がある。この明細書はEAPを用いて有効再認証のためにEAP再認証拡張(ERX)を特定している。ERXに基づくEAP再認証プロトコル(ERP)はピアに対するEAPメソッド非依存再認証をサポートする。このピアは以前に実行されたEAP認証からの有効な残りキーマテリアルを有する。プロトコル及びEAP再認証に必要なキー階層がこの明細書に記載されている。
【0053】
次の背景参考文献は個々に参照としてここに援用される。
【先行技術文献】
【非特許文献】
【0054】
【非特許文献1】Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, March 1997 (ここでは[RFC2119]と称する).
【非特許文献2】Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, “Extensible Authentication Protocol (EAP),” RFC 3748, June 2004 (ここでは[RFC3748]と称する).
【非特許文献3】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.
【非特許文献4】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]と称する).
【非特許文献5】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]と称する).
【非特許文献6】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]と称する).
【非特許文献7】National Institute of Standards and Technology, “Secure Hash Standard”, August 2002 (ここでは[sha256]と称する).
【非特許文献8】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]と称する).
【非特許文献9】Kaufman, C., “Internet Key Exchange (IKEv2) Protocol”, RFC 4306, December 2005 (ここでは[RFC4306]と称する).
【非特許文献10】Narayanan, V. and L. Dondeti, “EAP Re-authentication Extensions”, draft-ietf-hokey-erx-02 (work in progress), July 2007 (ここでは[I-D.ietf-hokey-erx]と称する).
【非特許文献11】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]と称する). 各種方式及び方法は知られているが、改良された方式及び方法の必要性がある。
【発明の概要】
【発明が解決しようとする課題】
【0055】
本発明は背景技術における各種制限及び欠陥を解消する。本出願は以下に述べるように下記のような発明セットを含む、複数の発明を盛り込んでいる。
【課題を解決するための手段】
【0056】
発明セット♯1:
幾つかの実施形態によると、クライアントとサーバ間のメソッドの認証方法はa)クライアントとサーバ間に認証機構を有さないメソッドを採用すること、及びb)クライアントを認証するために前記メソッドに内部認証メソッドを当てにさせることを含む。好ましくは、メソッドは内部に第2EAPを持つ認証機構を有さない第1EAPメソッドであり、第2EAPはクライアントを認証するために使用される。
【0057】
発明セット♯2:
幾つかの他の実施形態によると、EAP拡張機能性に関する能力を交渉するためEAPピア及びEAPサーバのためのメソッドは、サーバと拡張機能性に関するクライアントとの能力交換を提供するEAP拡張メソッド(EAP−EXT)を採用することを含み、拡張機能性は認証機構を持たなく少なくとも1つのEAPメソッドはEAPピアを認証するためのEAP拡張メソッド以内で実行する。幾つかの実施形態では、本方法は内部EAPメソッドにキーイングマテリアルを生成させること、外部EAP拡張メソッドのメッセージをAUTH TLVでサポートすることを更に含む。幾つかの実施形態では、本方法は外部EAP拡張メッセージのAUTH TLVsは最近成功した内部メソッドのEAPキーイングマテリアルから生成されるEAP拡張キー(EAP−EXT−KEY)を用いて計算されることを更に含む。幾つかの実施形態では、本方法はEAP拡張キーがEAP−EXTメッセージをサポートする完全性のためのAUTH TLVsを計算するために使用されることを更に含む。幾つかの他の実施形態では、本方法はEAP拡張キーが使用特定ルートキー導出アルゴリズムを使用して内部EAPメソッドによって生成されるEMSKから得られることを更に含む。幾つかの実施形態では、本方法はEAP拡張メソッドが再認証機構に使用されたEAPメソッドによって要求される事前共有キーとして使用されるEAP再認証キーを定義することを更に含む。幾つかの実施形態では、本方法はEAP再認証キーが使用特定ルートキー導出アルゴリズムを用いるEAP拡張メソッドから排出されるEMSKから得られることを更に含む。幾つかの実施形態では、本方法は最終メッセージであることを示すために設定できるビット、エラーを示すために設定できる他のビット、複数のビットのバージョンフィールド、将来の拡張のための複数のビットの予約フィールド及び各々が特定の能力に対応する複数のビットの能力フィールドとともに共通EAPフィールドを含むメッセージフォーマットを用いることを更に含む。幾つかの実施形態では、本方法はサーバ及び拡張機能に関するクライアントとの能力交換は能力ビットの設定によって行われることを更に含む。幾つかの実施形態では、本方法は送信者がチャネル結合機構をサポートすることを能力ビットが示すことを更に含む。幾つかの実施形態では、本方法では能力ビットは送信者が再認証をサポートすることを示すことを更に含む。幾つかの実施形態では、本方法は送信者が再認証をサポートしていることを示す能力ビットが最終リクエスト/EXTメッセージに設定されるときを更に含み、メッセージがサーバID TLV及びピアID TLVを含む。幾つかの実施形態では、本方法は送信サポート再認証が最終リクエスト/EXTメッセージ及びレスポンス/EXTメッセージ交換に設定されることを能力ビットが示すとき、EAPピア及びEAPサーバがEAP再認証キーを発生することを更に含み、サーバID及びサーバIDに含まれるピアID並びにピアID TLVs及びEAP再認証キーは再認証EAPメソッドに使用される。幾つかの実施形態では、本方法はEAP拡張メソッド内で順次実行される複数の内部EAPメソッドを採用すること及びシーケンスの内部EAP法がキーイングマテリアルを生成する毎に新たなEAP拡張キーを生成することを更に含む。幾つかの実施形態では、本方法はa)EAPサーバが少なくとも1つの能力ビットセットでEAPリクエスト/EXTメッセージを送信し、b)EAPピアはEAPリクエスト/EXTメッセージを受信し、少なくとも1つの能力ビットセットでEAPレスポンス/EXTメッセージを送信することを更に含む。幾つかの実施形態では、本方法はc)EAP−レスポンス/Extメッセージを受信し、F−ビットセット、少なくとも1つの能力ビットセット、ピアID TLV,サーバID TLV及びAUTH TLVを持つEAPリクエスト/EXTメセージを送信すること、d)EAPピアが上記c)のEAPリクエスト/Extメッセージを受信し、F−ビットセット,少なくとも1つの能力ビットセット及びAUTH TLVを有するEAPレスポンス/EXTメッセージを送信すること、e)EAP−サーバがd)のEAPレスポンス/EXTメッセージ受信し、EAP−成功メッセージを送信することを更に含む。幾つかの実施形態では、本方法はピア又はサーバがエラーを検出する場合のエラーを示すビットセット及びAUTH TLVによってEAPピア又はEAPサーバのいずれかにEAP拡張メッセージを送信させることを更に含む。幾つかの実施形態において、本方法は能力情報が攻撃者によって攻撃されるのを避けるためにキーイングマテリアルの生成後にサポートメッセージ交換を行うことを更に含む。幾つかの実施形態では、本方法はEAP拡張メソッド以内に多くのEAPメソッドを順序付けることを更に含む。幾つかの実施形態では、本方法はシーケンスにおいて先に成功した内部メソッドによって生成されるキーを用いる外部EAP拡張メソッドと共に各内部EAPメソッドをサポートすることによって暗号結合を作成し、最後に成功した内部EAPメソッドによって生成されるEAPキーイングマテリアルを最後に搬送することを更に含む。
【0058】
発明セット#3:
幾つかの他の実施形態によると、プロセッサ、メモリ、デジタルデータ記憶装置、及びデータメッセージを無線で送受信するための少なくとも1つの無線インターフェースを含む無線移動局が設けられ、無線モバイル装置はEAPピアとして動作するようにプログラムされている。無線モバイル装置はi)EAPサーバから少なくとも1つの能力ビットセットによってEAPリクエスト/EXTメッセージを受信し、ii)少なくとも1つの能力ビットセットによってEAPレスポンス/EXTメッセージを送信するようにプログラムされる。
【0059】
発明セット#4:
幾つかの他の実施形態によると、無線ネットワーク用のEAPサーバがEAPピアによってEAP認証メソッドを終了する。EAPサーバはa)少なくとも1つの能力ビットセットによってEAPリクエスト/EXTメッセージをEAPピアに送信し、b)少なくとも1つの能力ビットセットによってEAPレスポンス/EXTメッセージをEAPピアから受信する。
【0060】
上記及び/又は他の発明、態様、特徴及び/又は種々実施形態の利点は添付図面と関連して以下の説明を鑑みて更に理解されるであろう。種々実施形態は異なる態様、特徴及び/又は適用できる場合の利点を含める及び/又は除外することができる。更に、種々の実施形態は適用できる場合に他の実施形態の1以上の態様又は特徴を組み合わすことができる。特定の実施形態の態様、特徴及び/又は利点の説明は他の実施形態又は請求項を限定するように解釈されるべきでない。
【図面の簡単な説明】
【0061】
【図1】幾つかの実施形態に従った単一内部メソッドによってEAPサーバとEAPピアとの間の具体的なEAP−EXTメッセージシーケンスを示す図である。
【図2】幾つかの実施形態に従った複数の内部メソッドによってEAPサーバとEAPピアとの間の具体的なEAP−EXTメッセージシーケンスを示す図である。
【図3A】幾つかの模範的実施形態に従った具体的メッセージフォーマットを示す図である。
【図3B】幾つかの模範的実施形態に従った具体的能力フィールドを示す図である。
【図3C】幾つかの模範的実施形態に従った具体的TLVフォーマットを示す図である。
【図4】幾つかの追加の実施形態に従った単一内部メソッドによってEAPサーバとEAPピアとの間の具体的なEAP−EXTメッセージシーケンスを示す図である。
【図5】幾つかの追加の実施形態に従った複数の内部メソッドによってEAPサーバとEAPピアとの間の具体的なEAP−EXTメッセージシーケンスを示す図である。
【図6A】幾つかの追加の模範的実施形態に従った具体的メッセージフォーマットを示す図である。
【図6B】幾つかの追加の模範的実施形態に従った具体的能力フィールドを示す図である。
【図6C】幾つかの追加の模範的実施形態に従った具体的TLVフォーマットを示す図である。
【図7A】暗号アルゴリズムTLVを示す図である。
【図7B】完全性アルゴリズムTLVを示す図である。
【発明を実施するための形態】
【0062】
本発明の好適な実施形態は添付図面に一例として示され、限定されない。
【0063】
本発明は多くの異なる形態で実施できるが、多数の具体的実施形態は本開示がここに記載された種々の発明の原理の例を提供するよう考えられるべきであり、そのような例は個々に記載され及び/又はここに説明されていると言う了解の下で説明されている。
【0064】
1.序論
EAP(拡張可能認証プロトコル)は“EAPメソッド”[RFC3748]として知られている多くの認証アルゴリズムをサポートする認証プロトコルである。EAPでは、EAPピア及びEAPサーバはEAPキーイングマテリアル、即ち、MSK(マスタセッションキー)及びEMSK(拡張マスタセッションキー)を生成する。MSKの生成、搬送及び使用の詳しいフレームワークは[I-D.ietf-eap-keying]に記載されている。
【0065】
EMSK用法の1つが再認証である場合にEMSK(拡張マスタセッションキー)の幾つかの用法を定義することによってEAP[RFC3748]の拡張機能がある。EAPの他の拡張機能は[I-D.ohba-eap-channel-binding]に定義されているチャネル結合方式である。チャネル結合に関する追加の背景文献として、2006年4月20日にY. Ohbaによって出願された、CHANNEL BINDING MECHANISM BASED PARAMETER BINDING IN KEY DERIVATIONと名称付けられた同時継続の出願番号11/379,568の全開示が全体として参照することによって本明細書に援用される。EAPの拡張機能をサポートする実施は拡張機能をサポートしない実施と相互運用する必要があり、故に、前者の実施は後者の実施と通信するとき拡張機能を無効にするので、EAPピアに対する機構が必要となり、EAPの拡張機能に関して能力を取り決めるEAPサーバが必要となる。
【0066】
EAP機能を拡張するために2つの基本的な方法がある。1つの方法は既存の方法、即ち、リクエスト、レスポンス、成功及び失敗に加えて拡張EAP機能を実現するために新たなEAPコードを定義することである。しかしながら、この方法はRFC3748への変更を必要とし、下位層プロトコルへの変更も必要とするかもしれない。他の方法は拡張機能を実現するために新たなEAPメソッドを定義することである。この明細書は後者の方法が既存のEAP展開への攻撃を参照にするために後者の方法と取る。
【0067】
この明細書はEAP−EXT、EAP機能を拡張するEAPメソッドを説明している。幾つかの好適実施形態では、拡張EAP機能はチャネル結合及び再認証を含む。また、EAP−EXTメソッドはその内部の多くのEAPメソッドの順序づけを可能にする。
【0068】
2.EAP−EXT概要
好適実施形態では、EAP−EXTは能力交換を提供する。この点について、メッセージ内のビットは能力の表示に使用できる。幾つかの実施形態では、1ビット(R−ビット)は再認証能力に使用される。幾つかの実施形態では、1ビット(C−ビット)はチャネル結合能力を示すために使用される。
【0069】
EAP−EXTが使用されるとき、サーバが第1のEAPリクエストを送る前にサーバにピアの識別が知られれば先のEAP−識別交換が省略できる。この点について、ピアの識別をサーバに提供する、例えば、Authenticatorとサーバとの間でピアの識別を転送する幾つかのアウトバンド(outband)機構がある。
【0070】
EAP−EXTにおいて、チャネル結合及び再認証のような拡張EAP能力はピア及びサーバ間で交換される。同時に、少なくとも1つのEAPメソッド(例えば、EAP−TLS)はピアを認証するためのEAP−EXT内で実行される。内部メソッドがEAPキーイングマテリアルを生成するまで、AUTH TLVは含まれず、能力はサポートされない。故に、1つの内部EAPメソッドだけがあれば、AUTH TLVを有するがメソッドTLVを有さない追加のEAP−EXTがEAP成功又はEAP失敗メッセージを送る前に実行される。
【0071】
内部EAPメソッドはEAPキーイングマテリアルを生成した後、EAP−EXTメッセージはAUTH TLVによってサポートする必要がある。EAP−EXTメッセージの中のAUTH TLVsは最後に成功した内部メソッドのEAPキーイングマテリアルから生成されるEAP−EXT−KEYを用いて計算する必要がある。これはEAP−EXT内部で順次実行される複数の内部EAPメソッドがあれば、新たなEAP−EXT−KEYがシーケンスの内部EAPメソッドがEAPキーイングマテリアルを生成する毎に生成されることを意味する。任意の内部EAPメソッドはEAPキーイングマテリアルを生成できる用になる必要がある。
【0072】
成功したEAP−EXT実行の最後に、最後に成功した内部EAPメソッドによって生成されるEAPキーイングマテリアルはEAP層に転送される。F−ビットはEXP−EXT交換の終了を示すために使用される。
【0073】
図1は単一の内部EAPメソッドを持つEAP−EXTメッセージシーケンスの例を示す。図2は複数の内部EAPメソッドを有するEAP−EXTメッセージシーケンスの例を示す。
【0074】
3.エラー処理
エラーは複数の理由、例えば、内部EAPメソッド認証の失敗又は異常、未知、紛失EAP−EXT TLVにより生じるかもしれない。エラーはピア又はサーバのいずれかによって検出できる。エラーを起こしたEAP−EXTメッセージは誤りメッセージと見なされる。E−ビットセットを持つEAP−EXTメッセージはエラー表示のために使用される。これらのメッセージはエラー表示と見なされる。エラー表示はAUTH TLVを含める必要があり、他のTLVsを含めるべきでない。
【0075】
有効AUTH TLVを持たない(間違ったエラー表示を含む)どんな間違いメッセージも静かに破棄さする必要がある。
【0076】
有効AUTH TLVを持つ間違いリクエストに対して、ピアはエラー表示レスポンスを送る。有効AUTH TLVを伴わない間違いレスポンスに対して、サーバはエラー表示リクエストを送り、このリクエストはエラー表示レスポンスでピアによって応答される。サーバは有効AUTH TLV.を伴うエラー表示レスポンスに応答してEAP失敗メッセージを送り返す。
【0077】
4.完全性サポートキー
EAP−EXTは2種類のキー、即ち、1)EAP−EXT−KEY及び2)EAP−REAUTH−KEYを定義する。
【0078】
4.1. EAP−EXT−KEYは完全性サポートEAP−EXTメッセージのためにAUTH TLVsの計算に使用される。HMAC−SHA−256(上記文献に含まれる参考[sha256]を参照)は完全性アルゴリズムに使用されると、EAP−EXT−KEYの長さは32オクテットである。EAP−EXT−KEYは次のように定義されるUSRK(Usage Specific Root Key)導出アルゴリズムを用いて内部EAPメソッドによって生成されるEMSKから得られる(例えば、上記に参照することによって援用される文献[I-D.salowey-eap-emsk-deriv]を参照)。
【0079】
EAP−EXT−KEY = KDF (EMSK, “EAP-EXT-Integrity-Key”, length).
KDFでは、EAP−EXT−KEYは上記に参照することによって援用される文献[I-D.salowey-eap-emsk-deriv]に特定されているデフォルトPRFを用いる。
【0080】
4.2. EAP−REAUTH−KEY
EAP−REAUTH−KEYは再認証機構に使用されるEAPメソッドによって要求される事前共有キーとして使用される。EAP−REAUTH−KEYの長さは再認証機構に依存する。EAP−REAUTH−KEYは上記で援用される文献[I-D.salowey-eap-emsk-deriv]に次のように定義されるUSRK導出アルゴリズムを用いてEAP−EXTから転送されるEMSKから得られる。
【0081】
EAP−REAUTH−KEY = KDF(EMSK, “EAP-EXT-Reauthentication-Key”, length)
5. メッセージフォーマット
EAP−EXTは(IANAによって割り当てられるべき)EAP Type Xを用いる。[RFC3748]に定義された共通EAPフィールド(例えば、コード、識別子、長さ及び種類)を含むメッセージフォーマットは図3(A)に示される。
【0082】
F:
このビットはこれが送信者からの最後のEAP−EXTメッセージであることを示すように設定する必要がある。そうでなければ、このビットは設定する必要がない。
【0083】
このビットはメッセージがエラー表示であるときに設定される。このビットが設定されると、Fビットも設定する必要がある。エラー表に関する詳細な説明のセクション3を参照。
【0084】
バージョン:
この8ビットフィールドはEAP−EXTメソッドのバージョンを示す。この明細書はバージョン1を定義している。
【0085】
予約(Reserved):
6ビットフィールドは将来の拡張のために予約される。このフィールドは送信者によってゼロに設定する必要があり、受信者はこのフィールドを無視する必要がある。
【0086】
能力(Capabilities)
能力フィールドが処理するこのフィールドは拡張EAP能力を含む。能力は図3(B)に示されるフォーマットを処理する。
【0087】
各ビットは特定能力に対応する。各ビットの意味は次の通りである。
【0088】
C:
このビットは送信者がMSKのための[I-D.ohba-eap-channel-binding]に定義されるチャネル結合機構をサポートすることを示すために設定される。このビットはリクエスト及びレスポンスの両方に対して設定され、EAP−EXTメソッドが首尾よく完了すると、ピア及びサーバはチャネル結合機構を可能にする必要がある。prf+用デフォルトハッシュアルゴリズム(default hash algorithm)はAUTH_HMAC_SHA1_160である。
【0089】
R:
このビットは送信者が再認証EAPメソッドをサポートすることを示すために設定される。このビットは最後のリクエスト/EXTメッセージに設定されると(即ち、Fビットを有するリクエスト/EXTが設定されると)、メッセージはサーバID TLV及びピアID TLVを含める必要があり、Reauth−Key−Lifetime AVPを含めることができる。このビットが最後のリクエスト/EXT及びレスポンス/EXTメッセージ交換に設定されると、ピア及びサーバはEAP−REAUTH−KEYを発生する必要がある。サーバID及びピアIDはサーバID及びピアID TLVsに含められ、EAP−REAUTH−KEYは再認証EAPメソッドに使用される。デフォルト再認証機構はこの明細書に基づく従来技術のそれらによって選択できる。
【0090】
他のビットは将来の使用のために予約され、送信者によってゼロに設定する必要があり、受信者によって無視される必要がある。
【0091】
TLV:
ゼロ、1以上のTLVs(Type-Length-Value’s)。そのTLVフォーマットは図3(C)に示される。
【0092】
タイプ:
このフィールドはこのTLVのタイプを示す。
【0093】
長さ:
このフィールドは種類及びTLVの長さフィールドを含めて、オクテットでこのTLVの長さを示す。
【0094】
値
このフィールドはTLVタイプに特定されるデータを含む。
【0095】
6. EAP−EXT TLVs
後続TLVsが定義される。
【0096】
6.1.メソッドTLV
メソッドTLV(タイプ1)はタイプフィールドから開始するEAPメソッドペイロードを含む。
【0097】
6.2. AUTH TLV
AUTH TLV(タイプ2)はEAP−EXTメッセージをサポートするために使用される完全性データを含む。EAP−EXT−KEYはAUTH TLVsを計算するために使用される。
【0098】
TLV値フィールドはこのフィールドを含む全体のEAPメッセージわたって計算される。完全性データを計算する前に、このフィールドは全てゼロに初期化する必要がある。このフィールドの長さは使用時に完全性アルゴリズムに依存する。完全性チェックが失敗すると、メッセージは静かに破棄する必要がある。デフォルト完全性アルゴリズムはHMAC−SHA−256である(例えば、上記で援用されている文献[sha256]を参照)。
【0099】
6.3. ピアID TLV
ピアID TLV(タイプ3)は再認証に使用されるピアの識別を含む。
【0100】
6.4. サーバID TLV
サーバID TLV(タイプ4)は再認証に使用されるサーバの識別を含む。
【0101】
6.5. Reauth−Key−Lifetime TLV
Reauth−Key−Lifetime TLV(タイプ5)はEAP−REAUTH−KEYの寿命を秒単位で含む。
【0102】
7. 安全性考慮
内部EAPメソッドがEAPキーイングマテリアルを送る前に能力交換はサポートされない。故に、EAPキーイングマテリアルの作成後の追加サポートメッセージ交換は能力情報がピア及びサーバによって検出されないで攻撃者によって変更されるのを避けるために義務付けられる。
【0103】
EAP−EXTはその中の多くのEAPメソッドの順序付けを可能にする。複数の入れ子又は順序認証メソッドを暗号的に結合しないでそれらで構成される複合認証メソッドが介入者攻撃に対して無防備さを有する。EAP−EXTはシーケンスにおいて前に成功した内部メソッドによって生成されるキーを用いて外部EAPメソッド(即ち、EAP−EXT)と共に各内部EAPメソッドをサポートし、最後に成功した内部EAPメソッドによって生成されるEAPキーイングマテリアルを最終的に転送することによって必要暗号化的結合を作ることができる。暗号化結合を達成するために、EAP−EXTはEAPキーイングマテリアルを生成できる内部EAPメソッドを必要とする。
【0104】
追加EAP−EXT実施形態
詳細説明の残りは幾つかの内容において上記オリジナル実施形態を越える幾つかの変形例を有する追加のEAP−EXT実施形態について述べる。上記から分かるように、これらの追加実施形態は上述した先の実施形態に多くの点で類似している。これらの実施形態では、拡張機能、例えば、HOKEY再認証(例えば[I-D.ietf-hokey-erx]参照)及びMSKチャネル結合[I-D.ietf-eap-keying]がEAP機能を拡張することによってサポートできる。上記で説明したように、EAP機能を拡張するために2つの方法がある。1つの方法は既存のもの、即ち、リクエスト、レスポンス、成功及び失敗に加えて拡張EAP機能を実現するため新EAPコードを定義することである。しかしながら、この方法は[RFC3748]に変更を要求し、Authenticator及び下位層プロトコルに変更を要求することもできる。他の方法は拡張機能を実現するための新たなEAPメソッドを定義することである。両方法について、これら延長機能は下位互換性であることが望まれるかもしれない。そのような場合、EAPピアとEAPサーバとの間で拡張機能に関する能力を取り決める機構が必要となるかもしれない。
【0105】
これらの追加実施形態では、EAP機能を拡張するために使用されるEAPメソッドが説明される。拡張機能は、例えば、HOKEY再認証及びMSKチャネル結合を含む。これらの実施形態での提案EAPメソッド(EAP−EXT)は再度それ自体内で多くのEAPメソッドの順序付けをも可能にする。更に、これらの実施形態の中で、EAP−EXTは内部メソッド実施がMSKを生成するがEMSK を生成しない場合にMSK及びEMSKを発生できる。
【0106】
EAP−EXT概要
EAP−EXTは能力交換を提供する。1ビット(Rビット)はHOKEY再認証能力を示すために使用される。1ビット(Cビット)はチャネル結合能力を示すために使用される。
【0107】
EAP−EXTが使用されるとき、先のEAP識別交換はサーバがEAPリクエストを送る前にピアの識別がサーバに知られていれば省略できる。ピアの識別を提供する、例えば、Authenticatorとサーバとの間でピアの識別を転送するための帯域外機構が使用できる。
【0108】
EAP−EXTにおいて、HOKEY再認証及びMSKチャネル結合のような拡張EAP能力がピアとサーバ間で交換される。同時に、少なくとも1つのEAPメソッド(例えば、EAP−TLS)がピアを認証するためにEAP−EXT内で実行される。1つ以上の内部メソッドはメソッドTLVs(Type-Length-Values)で行われる。内部メソッドがEAPキーイングマテリアルを生成するまで、AUTH TLVは含まれなく、能力はサポートされない。故に、内部EAPメソッドだけ存在すれば、AUTH TLVを持つ追加EAP−EXT交換は内部メソッドの完了後及びEAP成功又はEAP失敗メッセージを送る前に行う必要がある。
【0109】
内部EAPメソッドがEAPキーイングマテリアルを発生した後、EAP−EXTメッセージはAUTH TLVによってサポートする必要がある。EAP−EXTメッセージのAUTH TLVsは最後に成功した内部メソッドのEAPキーイングマテリアルから生成されるEAP−EXT−AUTH−KEYを用いて計算する必要がある。これはEAP−EXT内で順次実行される多くの内部EAPメソッドがあれば、新たなEAP−EXT−AUTH−KEYはシーケンスのうちの内部EAPがEAPキーイングマテリアルを発生する毎に生成されることを意味する。任意の内部EAPメソッドはEAPキーイングマテリアルを生成可能にする必要がある。
【0110】
成功したEAP−EXTの実行の終わりに、EAPキーイングマテリアルが最後に成功した内部EAPメソッドによって生成されるMSKから得られ、EAP層に転送される。EAPキーイングマテリアル及びUSRKs(Usage Specific Root Keys)[I-D.ietf-hokey-emsk-hierarchy]を得るために使用される仮想ランダム関数がPRF TLVsを用いてEAP−EXT内で交渉できる。FビットはEXP−EXT交換の終了を示すために使用される。
【0111】
図4は単一内部EAPメソッド及びPRF取り決めを持つEAP−EXTメッセージシーケンスの例を示す。図5は複数の内部EAPメソッドを持つがPRF交渉を持たないEAP−EXTメッセージシーケンスの例を示す。
【0112】
エラー取り扱い
上述したオリジナル実施形態でエラー取り扱いに関する検討がここに援用される。
【0113】
キー
幾つかの実施形態では、EAP−EXTは次のタイプのキーを定義する。
【0114】
a.EAP−EXT から転送されるMSK及びEMSK
EAP−EXT から転送される64オクテットMSK及び64オクテットEMSKのセットはMSK_iから得られ、MSKは次の方法で[I-D.ietf-hokey-emsk-hierarchy]に定義されたKDFを用いて、最後に成功した内部EAPメソッドによって生成される。
【0115】
(MSK, EMSK) = KDF(MSK_i, “EAP-EXT-EAP-Keying-Material”, 128)
b. EAP−EXT−AUTH−KEY:
EAP−EXT−AUTH−KEYはEAP−EXTメッセージを安全にサポートするためにAUTH TLVsを算出するために用いられる。EAP−EXT−AUTH−KEYはEAP−EXT内だけで使用され、決して転送されない。EAP−EXT−AUTH−KEYは次のように[RFC4306]で定義されたprf+を用いて、最後に成功した内部EAPメソッド(MSK_i)によって生成されるMSKから求められる。
【0116】
EAP-EXT-AUTH-KEY = prf+(MSK_i, “EAP-EXT-認証キー”,長さ)
prf+用デフォルトハッシュアルゴリズムはPRF_HMAC_SHA2_256である。
【0117】
フィールド長はEAP−EXT交換中にEAPサーバによって選択される完全性アルゴリズムに依存することになる。HMAC−SHA−256[sha256]が完全性アルゴリズムに使用されると、長さ=32である。
【0118】
c. EAP−EXT−ENC−KEY:
EAP−EXT−ENC−KEYは暗号化TLVsの内容を暗号化するために使用される。それはMSK_iから得られ、MSKは次のように[I-D.ietf-hokey-emsk-hierarchy]で定義されるKDFを用いて、最後に成功した内部EAPメソッドによって生成される。
【0119】
EAP-EXT-ENC-KEY = prf+(MSK_i, “EAP-EXT-Encryption-Key”,長さ);
EAP−EXT−ENC−KEYを生成するために使用されるPRFはEAP−EXT交換中にEAPサーバによって選択される完全性アルゴリズムによって決定される。prf+用デフォルトハッシュアルゴリズムはPRF_HMAC_SHA2_256である。
【0120】
フィールド長はEAP−EXT交換中に取り決められる取り決め暗号化アルゴリズムに依存する。例えば、AES−CBC−128が使用されるときは、長さ=16である。
【0121】
d. HOKEY−REAUTH−KEY:
HOKEY−REAUTH−KEYはHOKEY再認証機構[I-D.ietf-hokey-erx]に必要な事前共通キーとして使用される。HOKEY−REAUTH−KEYの長さはHOKEY再認証機構に依存する。HOKEY−REAUTH−KEYは次のように[I-D.ietf-hokey-emsk-hierarchy]で定義されるUSRK導出アルゴリズムを用いてEAP−EXTから転送されるEMSKから求められる。
【0122】
HOKEY−REAUTH−KEY = KDF(EMSK, “EAP-EXT-再認証キー”,長さ)
メッセージフォーマット
EAP−EXTは(IANAによって割り当てられる)EAP Type XXを使用する。[RFC3748]で定義される共通EAPフィールド(即ち、コード、識別子、長さ及びタイプ)を含むメッセージフォーマットは図6(A)に示される。
【0123】
F:
このビットはこれが送信者からの最後のEAP−EXTメッセージであることを示すように設定する必要がある。
【0124】
E:
このビットはメッセージがエラー表示であるときに設定される。このビットが設定されるとき、Fビットも設定する必要がある。エラー表示の詳細な説明を以下に示す。
【0125】
バージョン
8ビットフィールドはEAP−EXTメソッドのバージョンを示す。この明細書はバージョン1を定義する。
【0126】
予約
この6ビットフィールドは将来の拡張のために予約される。このフィールドは送信者によってゼロに設定する必要があり、受信者はこのフィールドを無視する必要がある。
【0127】
能力
能力フィールドは拡張EAP能力を含む。能力フィールドは(図3(B)と同様であり)幾つかの実施形態において図6(B)に示されるようなフォーマットを持っている。ここでは、各ビットは特定の能力に対応する。各ビットの意味は次の通りである。
【0128】
R:
このビットは送信者がHOKEY再認証[I-D.ietf-hokey-erx]をサポートすることを示すように設定される。このビットは最後のリクエスト/EXTメッセージに設定される(即ち、Fビットを有するリクエスト/EXTが設定される)と、メッセージはサーバID TLV及びピアID TLVを含める必要があり、Reauth-Key-Lifetime AVPを含めることができる。このビットは最後のリクエスト/EXT及びレスポンス/EXT交換に設定されると、ピア及びサーバはHOKEY−REAUTH−KEYを生成する必要がある。サーバID及びピアIDはサーバID及びピアID TLVsに含まれ、HOKEY−REAUTH−KEYはHOKEY再認証に使用される。
【0129】
C:
このビットは送信者がMSK用チャネル結合機構をサポートしていることを示すように設定される。このビットはリクエスト/EXTメッセージに設定されると、1つのチャネル結合機構(Channel-Binding-Mechanism)TLVもサーバによってサポートされる1つ以上のチャネル結合機構を示すように含める必要がある。ピアがサーバによってサポートされる1つ以上のチャネル結合機構の1つをサポートし、可能にしたければ、それはこのビットセットを持つレスポンス/EXTメッセージ及び選択チャネル結合機構を含む1つのチャネル結合機構TLVを送信する。このビットが1つのチャネル結合機構の成功した交渉によって最後のリクエスト/EXT及びレスポンス/EXT交換に設定され、EAP−EXTメソッドが首尾よく完了すれば、ピア及びサーバは取り決めチャネル結合機構を可能にする必要がある。
【0130】
他のビットは将来の使用のために予約され、送信者によってゼロに設定する必要があり、受信者によって無視される必要がある。
【0131】
TLV:
ゼロ、1以上のTLVs(Type-Length-Value’s)。そのTLVフォーマットは図3(C)に示される実施形態と同様である図6(C)に示されるようである。
【0132】
タイプ:
このフィールドはこのTLVのタイプを示す。
【0133】
長さ:
このフィールドはTLVのタイプ及び長さフィールドを含めてこのTLVの長さをオクテットで示す。
【0134】
値:
このフィールドはTLVタイプに特定するデータを含む。
【0135】
EAP−EXT TLVs:
これらの実施形態では、次のTLVsが定義される。
【0136】
a. メソッドTLV
メソッドTLV(タイプ1)はタイプフィールドから開始するEAPメソッドペイロードを含む。
【0137】
b. AUTH TLV
AUTH TLV(タイプ2)はEAP−EXTメッセージをサポートするために使用される完全性データを含む。EAP−EXT−AUTH−KEYはAUTH TLVsを計算するために使用される。TLV値フィールドはこのフィールドを含む全体のEAPメッセージにわたり計算される。完全性データを計算する前に、このフィールドは全てゼロに初期化する必要がある。このフィールドの長さは使用時に完全性アルゴリズムに依存する。完全性チェックが失敗すると、メッセージは静かに破棄する必要がある。デフォルト完全性アルゴリズムはHMAC−SHA−256[sha256]である。
【0138】
c. ピアID TLV
ピアID TLV(タイプ3)はHOKEY再認証に使用されるピアの識別を含む。
【0139】
d. サーバID TLV
サーバID TLV(タイプ4)はHOKEY再認証に使用されるサーバの識別を含む。
【0140】
e. Reauth−Key−Lifetime TLV
Reauth−Key−Lifetime TLV(タイプ5)は秒単位でHOKEY−REAUTH−KEYの寿命を含む。
【0141】
f. PRF TLV
PRF TLV(タイプ6)は[I-D.ietf-hokey-emsk-hierarchy]で定義される1以上の1−オクテット数を含む。このTLVがリクエストに運び込まれると、それはサーバによってサポートされる1以上のPRF数を示す。
【0142】
このTLVがリクエスト/EXTメッセージに運び込まれると、対応するレスポンス/EXTメッセージがこのTLVを含むことができる。レスポンス/EXT内のPRF TLVはリクエスト/EXTメッセージのPRF数の中の、ピアによってサポート及び選択される1つのPRF数を正確に含める必要がある。PRF数が上述されたPRF TLV交換を用いて首尾よく取り決められれば、取り決められた数がEAP−EXT及びUSRKsによって転送されるEAPキーイングマテリアルを得るためにKDFに使用される。そうでなければ、[I-D.ietf-hokey-emsk-hierarchy]で特定されたデフォルトPRFがKDFに使用される。
【0143】
g. チャネル結合機構TLV
チャネル結合機構TLV(タイプ7)1以上の1−オクテットチャネル結合機構数を含む。このTLVがリクエスト/EXTメッセージに運び込まれると、それはサーバによってサポートされる1以上のチャネル結合機構数を示す。このTLVがリクエスト/EXTメッセージに運び込まれると、対応するレスポンス/EXTメッセージはこのTLVを含めることができる。レスポンス/EXTメッセージのチャネル結合機構TLVはリクエスト/EXTメッセージのチャネル結合機構数の内の、ピアによってサポートされ、選択される1つのチャネル結合機構数を正確に含める必要がある。チャネル結合機構は上述したチャネル結合機構TLV交換を用いて首尾よく取り決められれば、取り決めチャネル結合機構が可能となる。
【0144】
以下のチャネル結合機構数はこの明細書において定義されている。即ち、機構1 - [I-D.ohba-eap-channel-binding]及び機構2 - [arkko-eap-service-identity-auth]。
【0145】
チャネル結合機構1について、prf+用デフォルトハッシュアルゴリズムはPRF_HMAC_SHA2_256である。
【0146】
チャネル結合機構2について、追加チャネル結合データTLVがリクエスト及びレスポンスに運び込まれる。
【0147】
h. チャネル結合データTLV
チャネル結合データTLV(タイプ8)は[arkko-eap-service-identity-auth]に使用されるオクテットストリングデータを含む。
【0148】
i. 暗号化アルゴリズムTLV
暗号化アルゴリズムTLVは暗号化TLVsを暗号化するために使用される暗号化アルゴリズムの取り決めを可能にする。このTLVはリクエスト/EXTに運び込まれると、それはEAPサーバによってサポートされる暗号化アルゴリズムを示す。このTLVがリクエスト/EXTメッセージに運び込まれると、対応するレスポンス/EXTメッセージはこのTLVを含むことができる。レスポンス/EXTメッセージの暗号化アルゴリズムTLVはリクエスト/EXTメッセージに含まれる暗号化アルゴリズムTLVのオプション内の、ピアによってサポートされ、選択された1つの暗号化アルゴリズム数を正確に含める必要がある。EAPサーバはデフォルト暗号化アルゴリズム(AES−CBC−128)を使用するためEAPピアを強制できることに留意する。そのような場合、EAPピアはリクエスト/EXTメッセージに暗号化アルゴリズムTLVを含めなく、同様に、EAPピアはレスポンス/EXTメッセージにもそれを含めない。参考のため、図7(A)は暗号化アルゴリズムTLVを示している。
【0149】
それは次のように定義された1以上の1−オクテット数を含む。
【0150】
0 予約
1 AES−CBC−128(デフォルト)
2 AES−CBC−256
3 3DES
4 IDEA
アルゴリズムは暗号化アルゴリズムTLVを用いて首尾よく交渉できなければ、デフォルト暗号化アルゴリズムが代わりに使用される。
【0151】
j. 完全性アルゴリズムTLV
EAP−EXTメソッドは簡単にするために及び競り下げ攻撃(bidding-down attacks)を避けるために完全性アルゴリズム取り決めを可能にしない。しかしながら、EAPサーバは異なる完全性アルゴリズムから選択でき、完全性アルゴリズムTLVを介してこの選択についてEAPピアに知らせる。EAPサーバがこのTLVを含んでいなければ、デフォルト値がHMAC−SHA−256となる。参考のため、図7(B)は完全性アルゴリズムTLVを示している。
【0152】
それは次のリストに定義された1以上の1−オクテット数を含む。
【0153】
0 予約
1 HMAC−SHA−1
2 HMAC−SHA−224
3 HMAC−SHA−256(デフォルト)
4 HMAC−SHA−384
5 HMAC−SHA−512
k. 暗号化TLV
暗号化TLV(タイプ10)はEAP−EXT−ENC−KEYによって暗号化された1以上の標準文字を含む。このフィールドの長さは使用時に暗号化アルゴリズムに依存する。図7(C)を参照する。
【0154】
それは次のように定義された1以上の1−オクテット数を含む。
【0155】
タイプ:
(10) 暗号化TLV
長さ:
4+IV長+暗号化データ長.
IV:
IVは最初が最上位ビットであるランダムビットのオクテットストリングである。IVの長さは使用時の暗号化アルゴリズムに依存する。例えば、AES−CBC−128について、IVは16バイト(128ビット)である。
【0156】
暗号化データ
可変長の暗号化TLV。暗号化データはEAP−EXT−ENC−KEによって暗号化された1以上の標準文字TLVsから成る。暗号化アルゴリズム及び標準文字データの長さに依存して、暫定データが暗号化動作の以前に標準文字データに加算できる。
【0157】
セキュリティ上の配慮
内部EAPメソッドがEAPキーイングマテリアルを転送する前の能力交換はサポートされない。故に、EAPキーイングマテリアルの生成後の追加サポートメッセージ交換はピア及びサーバによって検出されないで能力情報が攻撃者によって変更されることを回避するために義務付けられる。
【0158】
EAP−EXTはその内部の複数のEAPメソッドの順序付けを可能にする。複数の入れ子又は順序付けられた認証メソッドを暗号的に結合しないでそれらにより構成される組合せ認証メソッドはman-in-the-middle攻撃に対しては脆弱である。EAP−EXTはシーケンス内での先に成功した内部メソッドによって生成されるキーによって外部EAPメソッド(即ち、EAP−EXT)と共に各内部EAPメソッドをサポートし、最後に成功した内部EAPメソッドによって生成されるキーから得られるEAPキーイングマテリアルを転送することによって必要暗号化結合を作ることができる。暗号化結合を達成するために、EAP−EXTはEAPキーイングマテリアル生成できる内部EAPメソッドを必要とする。
【0159】
このメソッドは内部メソッドのMSKから算出されるMSK及びEMSKを転送する。故に、転送されたMSK及びEMSKの全体の長さは内部メソッドのMSKの長さと同じである。
【0160】
本発明の広い範囲
本明細書では、本発明の例示的実施形態を説明しているが、本発明は、本明細書で説明した様々な好ましい実施形態だけに限定されず、本開示に基づけば当分野の技術者によって理解されるはずの、等価の要素、改変、省略、(様々な実施形態にまたがる態様などの)組合せ、適合及び/又は変更を有するありとあらゆる実施形態を含むものである。特許請求の範囲における限定は、特許請求の範囲で用いられる言葉に基づいて幅広く解釈されるべきであり、本明細書において、又は本出願の出願中において記述される例だけに限定されず、これらの例は、非排他的であると解釈されるべきである。例えば、本開示において、「好ましくは」という用語は、非排他的であり、「それだけに限らないが、好ましくは」を意味する。本開示において、かつ本出願の出願中において、手段プラス機能又はステッププラス機能限定は、特定のクレーム限定について、この限定において、a)「〜の手段」又は「〜のステップ」が明記されている、b)対応する機能が明記されている、及びc)構造、材料又はこの構造をサポートする動作が記載されていないという条件すべてが存在する場合に限り用いられる。本開示において、かつ本出願の出願中において、「本発明」又は「発明」という用語は、本開示内の1つ又は複数の態様を指すものとして使用され得る。本発明又は発明という言葉は、誤って重要度の識別と解釈されるべきではなく、誤ってすべての態様又は実施形態にわたって適用されるものと解釈されるべきではなく(すなわち、本発明はいくつかの態様及び実施形態を有すると理解されるべきであり)、また、誤って本出願又は特許請求の範囲を限定するものと解釈されるべきではない。本開示において、かつ本出願の出願中において、「実施形態」という用語は、任意の態様、特徴、プロセス又はステップ、これらの任意の組合せ、及び/又はこれらの任意の部分などを記述するのに使用され得る。いくつかの例では、様々な実施形態が重なり合う特徴を含み得る。本開示では、「例えば」を意味する「e.g.」という省略用語が用いられ得る。
【特許請求の範囲】
【請求項1】
クライアントとサーバ間のメソッドの認証のための方法であって、
a)クライアントとサーバ間に認証機構を持たない第1のEAPメソッドを採用し、
b)前記第1のEAPメソッドは、前記クライアントを認証するために前記第1のEAPメソッドの内部で実行する内部認証メソッドに依存し、
c)前記第1EAPメソッドは、前記クライアントを認証するために使用される第2のEAPメソッドを前記第1のEAPメソッドの内部で実行する認証機構を有さず、
d)前記第2のEAPメソッドにより生成されたEAPキーイングマテリアルに基づき前記第1のEAPメソッドに対してEAPキーイングマテリアルを得ることによって前記第1のEAPメソッドと前記第2のEAPメソッドとの間の暗号化結合を作ること、
を含む方法。
【請求項2】
更に、EAP拡張機能性を採用することに関して前記クライアントと前記サーバとの能力交換を実行することを含む、請求項1の方法。
【請求項3】
更に、前記EAP拡張メソッド内で順次実行される複数の内部EAPメソッドを採用すること及び順次の内部EAPメソッドがキーイングマテリアルを生成する毎に新EAP拡張キーを生成することを更に含む、請求項2の方法。
【請求項1】
クライアントとサーバ間のメソッドの認証のための方法であって、
a)クライアントとサーバ間に認証機構を持たない第1のEAPメソッドを採用し、
b)前記第1のEAPメソッドは、前記クライアントを認証するために前記第1のEAPメソッドの内部で実行する内部認証メソッドに依存し、
c)前記第1EAPメソッドは、前記クライアントを認証するために使用される第2のEAPメソッドを前記第1のEAPメソッドの内部で実行する認証機構を有さず、
d)前記第2のEAPメソッドにより生成されたEAPキーイングマテリアルに基づき前記第1のEAPメソッドに対してEAPキーイングマテリアルを得ることによって前記第1のEAPメソッドと前記第2のEAPメソッドとの間の暗号化結合を作ること、
を含む方法。
【請求項2】
更に、EAP拡張機能性を採用することに関して前記クライアントと前記サーバとの能力交換を実行することを含む、請求項1の方法。
【請求項3】
更に、前記EAP拡張メソッド内で順次実行される複数の内部EAPメソッドを採用すること及び順次の内部EAPメソッドがキーイングマテリアルを生成する毎に新EAP拡張キーを生成することを更に含む、請求項2の方法。
【図1】
【図2】
【図3A】
【図3B】
【図3C】
【図4】
【図5】
【図6A】
【図6B】
【図6C】
【図7A】
【図7B】
【図2】
【図3A】
【図3B】
【図3C】
【図4】
【図5】
【図6A】
【図6B】
【図6C】
【図7A】
【図7B】
【公開番号】特開2012−199929(P2012−199929A)
【公開日】平成24年10月18日(2012.10.18)
【国際特許分類】
【出願番号】特願2012−95152(P2012−95152)
【出願日】平成24年4月18日(2012.4.18)
【分割の表示】特願2009−509206(P2009−509206)の分割
【原出願日】平成19年12月5日(2007.12.5)
【出願人】(000003078)株式会社東芝 (54,554)
【出願人】(504473670)テルコーディア・テクノロジーズ・インコーポレーテッド (72)
【Fターム(参考)】
【公開日】平成24年10月18日(2012.10.18)
【国際特許分類】
【出願日】平成24年4月18日(2012.4.18)
【分割の表示】特願2009−509206(P2009−509206)の分割
【原出願日】平成19年12月5日(2007.12.5)
【出願人】(000003078)株式会社東芝 (54,554)
【出願人】(504473670)テルコーディア・テクノロジーズ・インコーポレーテッド (72)
【Fターム(参考)】
[ Back to top ]