JP5043114B2 - Ｅａｐからのケルベロス・ブートストラッピング（ｂｋｅ） - Google Patents

Description

本発明は、ＥＡＰからケルベロスをブートする（ＢＫＥ）に関する。

多様なコンピュータネットワークがあり、インターネットは最も有名である。インターネットは、コンピュータネットワークの世界規模のネットワークである。今日、インターネットは、何百万人ものユーザが利用可能な、公衆の自律的ネットワークである。インターネットは、ＴＣＰ／ＩＰ（すなわち、伝送制御プロトコル／インターネットプロトコル）と呼ばれる１組の通信プロトコルを使って各ホストを接続する。インターネットは、インターネットバックボーンとして呼ばれる通信インフラストラクチャを有する。インターネットバックボーンへのアクセスは大部分企業及び個人へのアクセスを再販するインターネットサービスプロバイダ（ＩＳＰ）によって制御される。

ＩＰ（インターネットプロトコル）に関して、これは、ネットワーク上である装置（電話機、ＰＤＡ［携帯情報端末］、コンピュータなど）から別の装置にデータを送るためのプロトコルである。今日、ＩＰｖ４、ＩＰｖ６などを含めて、様々なＩＰのバージョンがある。ネットワーク上の各ホスト装置は、独自の一意の識別子である少なくとも１つのＩＰアドレスを有する。

ＩＰはコネクションレス型プロトコルである。通信時の端点間接続は連続的ではない。ユーザがデータ又はメッセージを送信し、又は受信するとき、データ又はメッセージは、パケットと呼ばれる構成要素に分割される。各パケットは、独立のデータ単位として扱われる。

インターネットなどのネットワークを介した各点間の伝送を標準化するために、ＯＳＩ（開放型システム間相互接続）モデルが確立された。ＯＳＩモデルは、ネットワーク中の２点間の通信プロセスを７つの階層に分け、各層（レイヤ）は独自の機能セットを付加する。各装置は、送信側端点では各層を通る下方への流れがあり、受信側端点では各層を通る上方への流れがあるようにメッセージを処理する。７つの機能層を提供するプログラミング及び／又はハードウェアは、通常、デバイスオペレーティングシステム、アプリケーションソフトウェア、ＴＣＰ／ＩＰ及び／又は他のトランスポート及びネットワークプロトコル、ならびに他のソフトウェア及びハードウェアの組み合わせである。

通常、上位４層は、メッセージがユーザから、又はユーザへ渡されるときに使用され、下位３層は、メッセージが装置（ＩＰホスト装置など）を通過するときに使用される。ＩＰホストは、サーバ、ルータ、ワークステーションなど、ＩＰパケットを送受信することのできるネットワーク上の任意の装置である。他の何らかのホストに向けられているメッセージは、各上位層には渡されず、この他のホストに転送される。ＯＳＩモデル及び他の類似するモデルにおいて、ＩＰは第３層のネットワーク層にある。

無線ネットワーク
無線ネットワークは、例えば、セルラ及び無線電話機、ＰＣ（パーソナルコンピュータ）、ラップトップコンピュータ、装着型コンピュータ、コードレス電話機、ポケットベル、ヘッドセット、プリンタ、ＰＤＡなど、多種多様なモバイル機器を組み込むことができる。例えば、モバイル機器は、音声及び／又はデータの高速無線伝送を確保するデジタルシステムを含むことができる。典型的なモバイル機器は、次の構成要素の一部又は全部、即ち送受信機（すなわち、例えば、送信機、受信機及び、必要に応じて、他の機能が統合されたシングルチップ送受信機などを含む、送信機及び受信機）、アンテナ、プロセッサ、１つ又は複数の音声変換器（例えば、音声通信用機器でのスピーカやマイクロホンなど）、電磁データ記憶（データ処理が提供される機器の場合などでの、ＲＯＭ、ＲＡＭ、デジタルデータ記憶など）、メモリ、フラッシュメモリ、フルチップセット又は集積回路、インターフェース（ＵＳＢ、ＣＯＤＥＣ、ＵＡＲＴ、ＰＣＭなど）及び／又は同種のものを含む。

モバイルユーザが無線接続を介してローカルエリアネットワーク（ＬＡＮ）に接続することのできる無線ＬＡＮ（ＷＬＡＮ）が、無線通信に用いられ得る。無線通信には、例えば、光、赤外線、電波、マイクロ波などの電磁波を介して伝搬する通信などが含まれ得る。現在、ブルートゥース（登録商標）、ＩＥＥＥ８０２．１１、ＨｏｍｅＲＦなど、様々なＷＬＡＮ標準が存在する。

一例として、ブルートゥース製品は、モバイルコンピュータ、モバイル電話機、携帯式ハンドヘルド機器、携帯情報端末（ＰＤＡ）、及び他のモバイル機器の間のリンク、ならびにインターネットへの接続を提供するのに使用できる。ブルートゥースは、モバイル機器が、短距離無線接続を使って、相互に、また非モバイル機器と、どのようにして容易に相互接続し合うことができるかを詳述するコンピュータ及び電気通信業界仕様である。ブルートゥースは、ある機器と別の機器との間でデータを同期させ、整合させ続けることを必要とする、様々なモバイル機器の普及から生じるエンドユーザ問題に対処して、異なるベンダからの装置を相互にシームレスに動作させるデジタル無線プロトコルを作成する。ブルートゥース機器は、共通の命名概念に従って命名できる。例えば、ブルートゥース機器は、ブルートゥース機器名（ＢＤＮ）又は一意のブルートゥース機器アドレス（ＢＤＡ）に関連付けられた名前を持ち得る。また、ブルートゥース機器は、インターネットプロトコル（ＩＰ）ネットワークに参加することもできる。ブルートゥース機器がＩＰネットワーク上で機能する場合、この機器は、ＩＰアドレス及びＩＰ（ネットワーク）名を備え得る。よって、ＩＰネットワークに参加するように構成されたブルートゥース機器は、ＢＤＮ、ＢＤＡ、ＩＰアドレス及びＩＰ名などを含むことができる。「ＩＰ名」という用語は、インターフェースのＩＰアドレスに対応する名前を指す。

ＩＥＥＥ標準であるＩＥＥＥ８０２．１１は、無線ＬＡＮ及び機器の技術の仕様を定める。８０２．１１を使えば、各単一基地局がいくつかの機器をサポートする無線ネットワークが実現できる。いくつかの例では、機器に無線ハードウェアが事前装備されていることもあり、ユーザが、アンテナを含み得る、カードなどの別個のハードウェアをインストールすることもできる。例えば、８０２．１１で使用される機器は、通常、機器がアクセスポイント（ＡＰ）であるか、移動局（ＳＴＡ）であるか、ブリッジであるか、ＰＣＭＣＩＡカードであるか、それとも別の機器であるか否かを問わず、無線送受信機、アンテナ、及びネットワークにおける各点間のパケットの流れを制御するＭＡＣ（媒体アクセス制御）層という３つの注目すべき要素を含む。

更に、いくつかの無線ネットワークでは、複数インターフェース機器（ＭＩＤ）が利用できる。ＭＩＤは、ブルートゥースインターフェースと８０２．１１インターフェースなど、２つの独立のネットワークインターフェースを含むことができ、よって、ＭＩＤが２つの別個のネットワーク上に参加すると同時に、ブルートゥース機器ともインターフェースすることが可能になる。ＭＩＤは、ＩＰアドレス、及びＩＰアドレスに関連付けられた共通ＩＰ（ネットワーク）名を持つことができる。

無線ネットワーク機器には、それだけに限らないが、ブルートゥース機器、複数インターフェース機器（ＭＩＤ）、８０２．１１ｘ機器（８０２．１１ａ、８０２．１１ｂ、８０２．１１ｇ機器などを含む、ＩＥＥＥ８０２．１１機器）、ＨｏｍｅＲＦ（家庭内無線周波数）機器、Ｗｉ−Ｆｉ（Wireless Fidelity）機器、ＧＰＲＳ（汎用パケット無線システム）機器、３Ｇセルラ機器、２．５Ｇセルラ機器、ＧＳＭ（移動通信用グローバルシステム）機器、ＥＤＧＥ（Enhanced Data for GSM Evolution）機器、ＴＤＭＡ型（時分割多重接続）機器、又はＣＤＭＡ２０００を含むＣＤＭＡ型（符号分割多重接続）機器が含めることができる。各ネットワーク機器は、それだけに限らないが、ＩＰアドレス、ブルートゥース機器アドレス、ブルートゥース共通名、ブルートゥースＩＰアドレス、ブルートゥースＩＰ共通名、８０２．１１ＩＰアドレス、８０２．１１ＩＰ共通名、ＩＥＥＥ ＭＡＣアドレスを含む、様々な種類のアドレスを含むことができる。

また、無線ネットワークは、例えば、モバイルＩＰ（インターネットプロトコル）システム、ＰＣＳシステム、及び他のモバイルネットワークシステムにおいて見られる方法及びプロトコルも関与できる。モバイルＩＰでは、これに、インターネット技術標準化委員会（ＩＥＴＦ）によって作成された標準通信プロトコルが関与する。モバイルＩＰでは、モバイル機器ユーザは、これらの一旦割り当てられたＩＰアドレスを維持しつつ、各ネットワークにまたがって移動することができる。コメント要求（ＲＦＣ）３３４４を参照されたい。（注：ＲＦＣはインターネット技術標準化委員会（ＩＥＴＦ）の公式文書である。）モバイルＩＰは、インターネットプロトコル（ＩＰ）を拡張し、モバイル機器のホームネットワーク外部に接続するときに、モバイル機器にインターネットトラフィックを転送する手段を付加する。モバイルＩＰは、各モバイルノードに、これのホームネットワーク上のホームアドレスと、ネットワーク及びこれのサブネット内の機器の現在位置を識別する気付アドレス（ＣｏＡ）を割り当てる。機器が異なるネットワークに移動すると、機器は、新しい気付アドレスを受け取る。ホームネットワーク上のモビリティエージェントは、各ホームアドレスを、これの気付アドレスと関連付けることができる。モバイルノードは、インターネット制御メッセージプロトコル（ＩＣＭＰ）などを使って、これの気付アドレスを変更する都度ホームエージェントにバインディング更新を送ることができる。

（例えば、モバイルＩＰ外部などの）基本的なＩＰ経路指定において、経路指定機構は、各ネットワークノードが、常に、インターネットなどへの一定の接続点を有し、かつ各ノードのＩＰアドレスが、これが接続されているネットワークリンクを識別するという仮定を利用する。本明細書において、「ノード」という用語は、例えば、データ伝送のための再配信点や端点などを含むことができ、他のノードへの通信を認識し、処理し、及び／又は転送することのできる接続点を含む。例えば、インターネットルータは、機器のネットワークを識別するＩＰアドレスなどを調べることができる。次いで、ネットワークレベルにおいて、ルータは、特定のサブネットを識別するビットセットを調べることができる。次いで、サブネットレベルにおいて、ルータは、特定の機器を識別するビットセットを調べることができる。典型的なモバイルＩＰ通信の場合、ユーザが、例えば、インターネットなどからモバイル機器を切断し、これを新しいサブネットで再接続しようとする場合、機器は、新しいＩＰアドレス、適正なネットマスク及びデフォルトのルータを用いて再構成する必要がある。そうでなければ、経路指定プロトコルは、パケットを適正に配信することができないはずである。

ケルベロスに関する背景
ケルベロスは、ネットワーク認証プロトコルである。http://web.mit.edu/Kerberos/を参照すること。ケルベロスは、秘密鍵暗号を使用することによってクライアント／サーバアプリケーションに認証を与える。このプロトコルの無料インプリメンテーションは、マサチューセッツ工科大学（Massachusetts Institute of Technology）から利用できる。ケルベロスは、多くの商品でも利用できる。

ケルベロスは、コンピュータネットワークでサービスの要求を認証するための安全な方法である。ケルベロスは、サーバから特定のサービスを要求するために使用できる認証プロセスから暗号化チケットをユーザに要求させる。ユーザのパスワードは、ネットワークを通過する必要がない。

ケルベロス［ＲＦＣ１５１０］は、認証、許可及び鍵の配布を提供する周知のセキュリティプロトコルである。ケルベロスは多くのプロトコルを保証するために使用される。

ケルベロスは、ユーザがパスワードを再入力することを要求しないで、クライアントＡがチケット交付サービス（ＴＧＳ：Ticket Granting Service）にアクセスするための初回チケットを入手できるようにする。この初回チケットは、クライアントＡがサービスＢにアクセスするための別のチケットを取得するためにＴＧＳとのケルベロス交渉を開始できるようにする。この手法を使用することによって、また、ケルベロスは、Ａが（アクセスしたドメインの中の）ローカルＴＧＳにアクセスするために（Ａのホームドメインの中の）リモートＴＧＳからチケットを回収できる相互レルム動作を可能にする。しかしながら、ケルベロスは３者間で時間の同期を必要とする。

いくつかの例では、ＥＡＰフレームワークの柔軟性を、大学及び企業のネットワーク内に幅広く配備されたケルベロスと結合することによって、ケルベロスチケット交付チケットをブートすることが可能である。このケルベロスチケット交付チケットは、次に、種々のプロトコルとの使用のためにサービスチケットを回収するために使用できる。ＥＡＰプロトコルの相互作用の助けを借りてケルベロスチケットをブートするこの手法は、［I-D.tshofenig-pana-bootstrap-keruberos］に説明されており、その全体的な開示はここに参照により組み込まれている。

ＥＡＰとケルベロスとを組み合わせる別の手法は、ＥＡＰベースの事前認証機構をケルベロスに統合することである。しかしながら、信任状をブートするために一般的なプロトコルを使用することは、（ＭＩＰｖ６ブートスラッピンブ作業［I-D.ietf-mip6-bootstrap-ps］の一部として説明されるような）使用モバイルＩＰのための対称鍵をブートするために、あるいは公開鍵／秘密鍵をブートするためにも使用できる。したがって、短命の公開鍵と秘密権の対のエンドホストへの配信を秘密裏に保護することが必要であろう。この鍵の対は、おそらく取り消し（リボケーションrevocation）機構を必要とすることない短いライフタイムを有し、（ＩＫＥｖ２またはＴＬＳを含む）公開鍵ベースの機構を活用するすべてのセキュリティプロトコルで使用できるであろう。大きな優位点は、対称暗号に基づいた認証プロトコルがＥＡＰ内で依然として使用できるため、公開鍵のインフラストラクチャが回避されることである。以下の節で説明されるように、拡張認証プロトコル（ＥＡＰ）［ＲＦＣ３７４８参照。この全体が参照によりここに組み込まれている］が認証方法を提供する。いくつかの例では、ＰＡＮＡプロトコル［I-D.ietf-pana-pana］が、アクセスネットワーク内でＰａＣ（ＰＡＮＡクライアント）とＰＡＡ（ＰＡＮＡ認証エージェント）の間でＥＡＰメッセージを伝搬する。

ＥＡＰに関する背景
Ａｂｏｂａ、ＲＦＣ３７４８（以下に引用）を参照すると、拡張認証プロトコル（ＥＡＰ）の実例となる態様が説明されている。ＥＡＰは、複数の認証方法をサポートする認証フレームワークである。ＥＡＰは、通常、ＩＰを必要とせずに、例えばポイントツーポイントプロトコル（ＰＰＰ）またはＩＥＥＥ ８０２等のデータリンク層で直接的に実行する。ＥＡＰは、複製排除と再送に独自のサポートを提供するが、下位層の順序付け保証に頼っている。フラグメンテーションは、ＥＡＰ自体の中ではサポートされていないが、個々のＥＡＰ方法はこれをサポートしている。

ＥＡＰは、交換回線網だけではなく専用リンク、無線リンクだけではなく有線リンクでも使用されてよい。今日まで、ＥＡＰは、交換回線網またはＰＰＰ［ＲＦＣ１６６１］を使用するダイアルアップ回線を介して接続するホスト及びルータで実現されてきた。ＥＡＰはまた、ＩＥＥＥ ８０２[ＩＥＥＥ−８０２]を使用するスイッチおよびアクセスポイントで実現されてきた。ＩＥＥＥ ８０２有線媒体上でのＥＡＰカプセル化は、［ＩＥＥＥ−８０２．１Ｘ］に、ＩＥＥＥ無線ＬＡＮでのカプセル化は［ＩＥＥＥ−８０２．１１ｉ］の中に説明されている。

ＥＡＰアーキテクチャの優位点の１つはこの柔軟性である。ＥＡＰは、通常は認証が使用される特定の認証方法を決定するためにさらに多くの情報を要求した後に、特定の認証機構を選択するために使用される。オーセンティケータがそれぞれの新しい認証方法をサポートするために更新されることを必要とするよりむしろ、ＥＡＰは、いくつかまたはすべての認証方法を実現してよく、オーセンティケータがいくつかのまたはすべての方法のための通過地点及びピアの役目を務めるバックエンド認証サーバの使用を許可する。

この後者の引用文書の中で、オーセンティケータ要件は、このオーセンティケータが通過地点の役目を務めているかどうかに関係なく当てはまる。要件が、オーセンティケータまたはバックエンド認証サーバのどちらかに当てはまることが意図される場合、ＥＡＰ認証がどこで終了されるのかに応じて、用語「ＥＡＰサーバ」が使用されてきた。

ＥＡＰは、ＩＰ層の接続性が使用できない可能性のあるネットワークアクセス認証で使用するために設計された。ＥＡＰは、飛行中の単一のパケットしかサポートしないロックステッププトロコルである。その結果として、例えばＴＣＰまたはＳＣＴＰ等のトランスポートプロトコルとは異なり、ＥＡＰはバルクデータを効率的に運ぶことはできない。

ＥＡＰは再送をサポートするが、ＥＡＰは下位層によって提供される順序付け保証を想定するため、順序がバラバラの受信はサポートされない。

ＥＡＰはフラグメンテーションとリアセンブリをサポートしないので、最小ＥＡＰ ＭＴＵより多くのペイロードを生成するＥＡＰ認証方法はフラグメンテーションサポートを提供する必要がある。

例えばＥＡＰ−ＴＬＳ等の認証方法はフラグメンテーション及びリアセンブリに対するサポートを提供するが、この後者の引用文書で規定されるＥＡＰはサポートを提供しない。結果として、ＥＡＰパケットサイズがリンクのＥＡＰ ＭＴＵを超えると、これらの方法は問題に遭遇する。

多くの認証プロトコルはクライアント（ピア）によって起動されるが、ＥＡＰ認証はサーバ（オーセンティケータ）によって起動される。結果として、認証アルゴリズムがＥＡＰ上で実行するために１つまたは２つの追加メッセージを（多くても１回の往復で）追加することが必要となる可能性がある。

証明書ベースの認証がサポートされる場合、追加の往復数が、証明書チェーンのフラグメンテーションのためにはるかに多くなる可能性がある。一般的には、分解されたＥＡＰパケットは、フラグメントと同数の往復を送ることを必要とする。例えば、サイズが１４９６０オクテットの証明書チェーンは、１０回の往復が１４９６オクテットのＥＡＰ ＭＴＵで送信することを必要とするであろう。ＥＡＰが、かなりのパケット損失が経験される下位層で実行する場合、あるいはオーセンティケータと認証サーバの間の接続がかなりのパケット損失を経験する場合、多くの往復を要するＥＡＰメソッドは問題を経験する場合がある。これらの状況では、往復がさらに少ないＥＡＰメソッドの使用が賢明である。

ＥＡＰ認証交換は、以下のように進行する。

［１］オーセンティケータは、ピアを認証するためのリクエスト（Request）を送信する。このリクエストは、何が要求されているか示すためのタイプ（Type）フィールドを有する。リクエストタイプの例は、アイデンティティ、ＭＤ５−チャレンジ（MD5-Challenge）等を含む。ＭＤ５−チャレンジＴｙｐｅは、ＣＨＡＰ認証プロトコルに厳密に対応する［ＲＦＣ１９９４参照］。通常は、オーセンティケータは初期アイデンティティ要求（Identity Request）を送信するが、初期アイデンティティ要求が必要とされない場合には、迂回できる。例えば、アイデンティティが、ピアが接続している（専用回線、専用スイッチまたはダイアルアップポート）ポートによって決定される場合、あるいはアイデンティティが別の様式（発呼局アイデンティティまたはＭＡＣアドレスを介して、ＭＤ５−チャレンジ応答（MD5-Challenge Response）のＮａｍｅ（名前）フィールドの中で等）で取得される場合には、アイデンティティは必要とされない場合がある。

［２］ピアは有効なリクエストに応えてレスポンスパケットを送信する。リクエストパケットと同様に、レスポンスパケットには、リクエストのタイプフィールドに相当するタイプフィールドが含まれる。

［３］オーセンティケータは追加のリクエストパケットを送信し、ピアはレスポンスで応答する。リクエストとレスポンスのシーケンスは必要なだけ続行する。ＥＡＰは「ロックステップ」プロトコルであり、その結果初回のリクエスト以外、有効なレスポンスを受信する前に新しいリクエストを送信することはできない。オーセンティケータは、要求の再送に関与する。適切な回数再送した後に、オーセンティケータはＥＡＰ会話を終了する必要がある。オーセンティケータは、再送時、あるいはピアから応答を取得できないときには成功（Success）または失敗（Failure）パケットを送信する必要はない。

［４］オーセンティケータがピアを認証できなくなるまで（１つまたは複数のリクエストに対する受け入れられないレスポンス）、会話は続行し、この場合オーセンティケータインプリメンテーションはＥＡＰ失敗（EAP Failure）（コード４）を送信する必要がある。あるいは、認証会話は、オーセンティケータが、認証成功が発生したことを確認するまで続行でき、この場合、オーセンティケータはＥＡＰ成功（EAP Success）（コード３）を送信する必要がある。同文献。

他の優位点の内、ＥＡＰプロトコルは特定のものを事前協議する必要なく複数の認証機構をサポートできる。加えて、（例えば、スイッチまたはアクセスポイント（ＡＰ）等の）ネットワークアクセスサーバ（ＮＡＳ）装置は、各認証方法を理解する必要はなく、バックエンド認証サーバにとっての通過地点エージェントの役割を務めてよい。通過地点のサポートはオプションである。オーセンティケータは、同時に非ローカルピア及びオーセンティケータが局所的に実現しない認証方法に対する通過地点の役割を務めつつ、ローカルピアを認証してよい。加えて、オーセンティケータをバックエンド認証サーバから分離することにより、信任状管理及びポリシー決定が簡略化される。

概念上、ＥＡＰインプリメンテーションは、以下の構成要素からなる。

［ａ］下位層。下位層はピアとオーセンティケータの間でのＥＡＰフレームの送信と受信に関与する。ＥＡＰは、ＰＰＰ、有線ＩＥＥＥ ８０２ ＬＡＮ［ＩＥＥＥ−８０２．１Ｘ参照］、ＩＥＥＥ ８０２．１１無線ＬＡＮ［ＩＥＥＥ−８０２．１１］、ＵＤＰ（Ｌ２ＴＰ［ＲＦＣ２６６１］とＩＫＥｖ２）及びＴＣＰを含む種々の下位層で実行されてきた。

［ｂ］ＥＡＰ層。ＥＡＰ層は下位層を介してＥＡＰパケットを送受し、複製検出と再送を実現し、ＥＡＰメッセージをＥＡＰピアとオーセンティケータの層に配信し、ＥＡＰピアとオーセンティケータの層から受信する。

［ｃ］ＥＡＰピアとオーセンティケータの層。Ｃｏｄｅ（コード）フィールドに基づき、ＥＡＰ層は入力ＥＡＰパケットをＥＡＰピア層とオーセンティケータ層に分離する。通常は、任意のホスト上でのＥＡＰインプリメンテーションは、ピアの機能性またはオーセンティケータの機能性のどちらかをサポートするが、ホストがＥＡＰピアとオーセンティケータの両方の役割を務めることが可能である。このようなインプリメンテーションでは、ピア層とオーセンティケータ層の両方とも存在する。

［ｄ］ＥＡＰメソッド層。ＥＡＰメソッドは、認証アルゴリズムを実現し、ＥＡＰピア層とオーセンティケータ層を介してＥＡＰメッセージを送受する。フラグメンテーションサポートはＥＡＰ自体によっては提供されないので、これはＥＡＰメソッドの責任である。同文献。

後に引用される文献は、本願で参照のために引用される以下の定義を説明する。

オーセンティケータ（Authenticator）：
ＥＡＰ認証を起動するリンクの端部。オーセンティケータという用語は、［ＩＥＥＥ−８０２．１Ｘ］で使用され、本願において類似した意味を有する。

ピア(Peer)：
オーセンティケータに応答するリンクの端部。［ＩＥＥＥ−８０２．１Ｘ］では、この端部は嘆願者(Supplicant)として知られている。

バックエンド認証サーバ：
バックエンド認証サーバは、オーセンティケータに認証サービスを提供するエンティティである。使用されるとき、このサーバは、通常、オーセンティケータのためにＥＡＰメソッドを実行する。この専門用語も［ＩＥＥＥ−８０２．１Ｘ］で使用される。

ＡＡＡ：
ＥＡＰサポートのある認証(Authentication）、許可（Authorization）、及びアカウンティング（Accounting）プロトコルは、ＲＡＤＩＵＳ（半径）及びＤｉａｍｅｔｅｒ（直径）を含む。本願では、用語「ＡＡＡサーバ」と「バックエンド認証サーバ」は交互に用いられる。

ＥＡＰサーバまたはサーバ
ピアとのＥＡＰ認証メソッドを終了するエンティティ。バックエンド認証サーバが使用されないケースでは、ＥＡＰサーバがオーセンティケータの一部である。オーセンティケータが通過地点モードで動作するケースでは、ＥＡＰサーバはバックエンド認証サーバに位置する。

認証成功
本願の関連では、「認証成功」とは、オーセンティケータがピアによるアクセスを許可することを決定し、ピアがこのアクセスを使用することを決定した結果としてのＥＡＰメッセージの交換である。オーセンティケータの決定は、通常は、認証と許可の両方の態様を必要とする。つまり、ピアが無事にオーセンティケータに対して認証し得るが、アクセスがポリシーの理由からオーセンティケータによって拒絶される可能性がある。

マスタセッション鍵（ＭＳＫ）
ＥＡＰピアとサーバの間で導出され、ＥＡＰメソッドによってエクスポートされるキーイング資料。ＭＳＫは少なくとも長さ６４オクテットである。既存のインプリメンテーションでは、ＥＡＰサーバとしてふるまうＡＡＡサーバがオーセンティケータにＭＳＫを運ぶ。

拡張マスタセッション鍵（ＥＭＳＫ）
ＥＡＰクライアントとサーバの間で導出され、ＥＡＰメソッドによってエクスポートされる追加のキーイング資料。ＥＭＳＫは少なくとも長さ６４オクテットである。ＥＭＳＫはオーセンティケータや他のサードパーティと共有されない。ＥＭＳＫは、まだ定められていない将来の使用のために確保される。

ＥＡＰ拡張：
参考のため、http://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.を引用する。この文献は、ＥＡＰ再認証プロトコル用ＥＡＰ拡張を以下のように説明する。「拡張認証プロトコル（ＥＡＰ）は、２つのパーティ（party）を認証するメソッドのトランスポートのための一般的なフレームワークである。認証は、一方的または相互のどちらかである。おもな目的はネットワークアクセス制御であり、アクセス制御を施行するために鍵生成方法が推奨される。ＥＡＰキーイング階層は、最上位で導出される２つの鍵―マスタセッション鍵（ＭＳＫ）と拡張ＭＳＫ（ＥＭＳＫ）を定義する。大部分の共通した配備シナリオでは、ピアとサーバはオーセンティケータとして知られているサードパーティを通して互いを認証する。オーセンティケータまたはオーセンティケータによって管理されているエンティティがアクセス制御を施行する。認証成功後、サーバはオーセンティケータにＭＳＫを運び、オーセンティケータとピアはＭＳＫを認証鍵または鍵導出鍵として短期セッション鍵（ＴＳＫ）を導出し、パケット単位のアクセス施行のためにこのＴＳＫを使用する。」同文献。「ピアがあるオーセンティケータから別のオーセンティケータに移動するとき、完全なＥＡＰ認証を回避することが望ましい。ＥＡＰメソッドの別のランとの完全なＥＡＰ交換は、完了するために数往復及びかなりの時間を要し、ハンドオフ時間の遅延を引き起こす。いくつかのＥＡＰメソッドは、計算上のオーバヘッドを削減することによって再認証（Re-authentication）を最適化するために初回認証からの状態の使用を指定するが、メソッド特有の再認証は少なくとも２往復を要する。多くの方法が再認証のサポートを提供しないことに留意することも重要である。したがって、個々のメソッドにおいてよりもＥＡＰにおいて効率的な再認証を有することが有益である。」同文献。

「オーセンティケータ全体での鍵の共有は、ハンドオフ時間を減らすための実用的な解決策として使用されることもある。その場合、オーセンティケータが妥協すると、他のオーセンティケータを介して確立されたＥＡＰセッションが危うくなる。」同文献。「要するに、ＥＡＰメソッドを再度実行する必要なく、ピアとオーセンティケータの間に新しい鍵を確立できるようにする効率的なＥＡＰ再認証機構を設計することが必要である。」同文献。「この文献は、ＥＡＰを使用する効率的な再認証のためにＥＡＰ再認証拡張（EAP Reauthentication Extensions）を規定する。ＥＲＸに基づいたＥＡＰ再認証プロトコル（ＥＲＰ）は、ＥＡＰメソッドに関係のない、以前に実行されたＥＡＰ認証から有効な期限切れになっていない鍵資料を有するピアに対する再認証をサポートする。ＥＡＰ再認証に必要とされるプロトコル及び鍵階層は、この文献に説明されている。」同文献。

ＥＡＰの拡張（ＥＡＰ−ＥＸＴ）：
本願は、ともにＥＡＰ拡張（ＥＡＰ−ＥＸ）用ＥＡＰメソッド（AN EAP METHOD FOR EAP EXTENSION（ＥＡＰ−ＥＸＴ））と題され、ここに全体的に開示がなされているように、参照によりここに組み込まれている、本譲受人の以前の発明U.S. non-provisional application Serial No.11/867,659, filed on October 4, 2007, to Y. Oba, et al., 及び U.S. provisional application Serial No.60/869,113, filed on December 8, 2006, to Y. Oba, et al.にさらなる改良を示す。背景技術を説明する文献として、本譲受人の上記背景技術に関連する情報が、以下のパラグラフに組み込まれている。

１．ＥＡＰ−ＥＸＴの概論
上記説明に加えて、ＥＡＰ（拡張認証プログラム）は、「ＥＡＰメソッド」［ＲＦＣ３７４８］として知られている複数の認証アルゴリズムをサポートする認証プロトコルである。ＥＡＰでは、ＥＡＰピアとＥＡＰサーバが、ＥＡＰキーイング資料、つまりＭＳＫ（Master Session Keyマスタセッション鍵）とＥＭＳＫ（Extended Master Session Key拡張マスタセッション鍵）を生成する。ＭＳＫの生成、トランスポート、及び使用のための詳細なフレームワークは［I-D.ietf-eap-keying］に説明されている。

ＥＭＳＫ使用法の１つが再認証である、ＥＭＳＫ（拡張マスタセッション鍵）のいくつかの使用法を定めることによるＥＡＰ［ＲＦＣ３７４８］の拡張機能性がある。ＥＡＰの別の拡張機能性は、［I-D.ohba-eap-channel-binding］に規定されている。チャネルバインディングに関するさらなる背景技術文献として、Y.Ohbaと同時継続出願の出願番号第１１／３７９，５６８号（CHANNEL BINDING MECHANISM BASED PARAMETER BINDING IN KEY DERIVATION, filed on April 20, 2006）が、参照として、その全体がここに組み込まれている。ＥＡＰの拡張機能性をサポートするインプリメンテーションは、前者のインプリメンテーションが、後者のインプリメンテーションと通信するときに拡張機能性を無効にできるように拡張機能性をサポートしないインプリメンテーションと相関する必要があるので、ＥＡＰピアとＥＡＰサーバが、必要とされるＥＡＰの拡張機能性に関するケイパビリティ(capability)について交渉する仕組みが必要とされる。

ＥＡＰ機能性を拡張するには２つの基本的な手法がある。１つの手法は、既存のコード、つまりリクエスト、レスポンス、成功（Success）及び失敗（Failure）に加えて、拡張ＥＡＰ機能性を実現するために新しいＥＡＰコードを定義することである。しかしながら、この手法は、ＲＦＣ３７４８に対する変更を必要とし、下位層プロトコルに対する変更も必要とする可能性がある。他の手法は、拡張機能性を実現するために新しいメソッドを定めることである。本願は、既存のＥＡＰ配置に対する影響を最小限に抑えるために後者の手法を採る。

ＥＡＰ−ＥＸＴは、ＥＡＰ機能性を拡張するためのＥＡＰメソッドである。いくつかの好ましい実施形態では、拡張ＥＡＰ機能性は、チャネルバインディングと再認証を含む。ＥＡＰ−ＥＸＴメソッドは、ＥＡＰ−ＥＸＴメソッドの内部での複数のＥＡＰメソッドの連鎖も可能にする。

２．ＥＡＰ−ＥＸＴ概要
好ましい実施形態では、ＥＡＰ−ＥＸＴはケイパビリティ交換を提供する。この点で、メッセージの中のビットは、ケイパビリティの表示のために使用できる。いくつかの実施形態では、１個のビット（Ｒ−ビット）が再認証（Re-authentication）ケイパビリティを示すために使用される。いくつかの実施形態では、１個のビット（Ｃ−ビット）が、チャネルバインディングケイパビリティを示すために使用される。

ＥＡＰ−ＥＸＴが使用されるとき、サーバが最初のＥＡＰ−リクエストを送信する前にピアのアイデンティティがサーバに既知である場合には、上記のＥＡＰ-アイデンティティ交換は省略できる。この点で、例えば、オーセンティケータとサーバの間でピアのアイデンティティを転送する等の、ピアのアイデンティティをサーバに提供するためのいくつかのアウトバンド（outband）機構がある。

ＥＡＰ−ＥＸＴでは、例えば、チャネルバインディングと再認証等の拡張されたＥＡＰケイパビリティがピアとサーバの間で交換される。同時に、少なくとも１つのＥＡＰメソッド（例えばＥＡＰ−ＴＬＳ）がピアを認証するためにＥＡＰ−ＥＸＴの内部で実行される。内部メソッドがＥＡＰキーイング資料を生成するまで、ＡＵＴＨ ＴＬＶ（Type-Length-Value（タイプ−長さ−値））は含まれず、ケイパビリティは保護されていない。したがって、ただ１つのＥＡＰメソッドしかない場合、メソッドＴＬＶはないが、ＡＵＴＨ ＴＬＶとの追加のＥＡＰ ＥＸＴ交換（複数の場合がある）が、ＥＡＰ−成功またはＥＡＰ−失敗メッセージを送信する前に実行される。ＴＬＶ（Type-Length-Value）に関する背景技術として、データ通信では、プロトコル情報がプロトコルの内部でタイプ−長さ−値またはＴＬＶ要素として符号化されてよいことが留意される。一例として、タイプフィールドと長さフィールドは、通常、サイズが固定され（例えば、数バイト）、値フィールドは、通常、可変サイズである。これらのフィールドは通常、以下のように使用される。タイプ−メッセージのこの部分が表すフィールドの種類を示す数値コード。長さ−値フィールドのサイズ（通常はバイト単位）。及び値−メッセージのこの部分のためのデータを含む可変サイズのバイトのセット。ＴＬＶ表現を使用する優位点のいくつかは、以下を含む。つまり、ＴＬＶシーケンスは汎用化された構文解析関数を使用して容易に検索される。さらに旧いノードで受け取られる新しいメッセージ要素は、安全に省略することができ、メッセージの残りを構文解析できる。そして、ＴＬＶ要素は、通常は、構文解析をさらに高速にし、データをさらに小さくするバイナリフォーマットで使用される。

内部ＥＡＰメソッドがＥＡＰキーイング資料を生成した後、ＥＡＰ−ＥＸＴメッセージは、ＡＵＴＨ ＴＬＶで保護される必要がある。ＥＡＰ−ＥＸＴメッセージ中のＡＵＴＨ ＴＬＶは、最新の成功した内部メソッドのＥＡＰキーイング資料から生成されるＥＡＰ−ＥＸＴ−ＫＥＹを使用して計算される必要がある。つまり、ＥＡＰ−ＥＸＴの内部で連続して実行される複数の内部ＥＡＰメソッドがある場合、シーケンスの中の内部ＥＡＰメソッドがＥＡＰキーイング資料を生成するたびに、新しいＥＡＰ−ＥＸＴ−ＫＥＹが生成される。任意のＥＡＰメソッドは、ＥＡＰキーイング資料を生成できる必要がある。

成功したＥＡＰ−ＥＸＴランの最後に、前回成功した内部ＥＡＰメソッドによって生成されるＥＡＰキーイング資料がＥＡＰ層にエクスポートされる。Ｆ−ビットは、ＥＸＰ−ＥＸＴ交換の最後を示すために使用される。

図１は、単一内部ＥＡＰメソッドのあるＥＡＰ−ＥＸＴメッセージシーケンスの例を示す。図２は、複数の内部ＥＡＰメソッドのあるＥＡＰ−ＥＸＴメッセージシーケンスの例を示す。

３．エラー処理
エラーは、例えば内部ＥＡＰメソッド認証の失敗、あるいは不正な形式の、未知の、または紛失したＥＡＰ−ＥＸＴ ＴＬＶに起因するいくつかの理由で起こることがある。エラーは、ピアまたはサーバのどちらかによって検出されてよい。エラーを引き起こしたＥＡＰ−ＥＸＴメッセージは、誤りメッセージと呼ばれている。Ｅ−ビットが設定されたＥＡＰ−ＥＸＴメッセージは、エラーの表示に使用される。これらのメッセージはエラー表示と呼ばれている。エラー表示は、ＡＵＴＨ ＴＬＶを含む必要があり、他のＴＬＶを含んではならない。

有効なＡＵＴＨ ＴＬＶのない（誤ったエラー表示を含む）誤りメッセージは、静かに破棄される必要がある。

有効なＡＵＴＨ ＴＬＶをもつ誤ったリクエストの場合、ピアはエラー表示レスポンスを送信する。有効なＡＵＴＨ ＴＬＶをもつ誤ったレスポンスの場合、サーバは、エラー表示レスポンスでピアによって応答されたエラー表示リクエストを送信する。サーバは、有効なＡＵＴＨ ＴＬＶをもつエラー表示レスポンスに応えてＥＡＰ−失敗メッセージを返す。

４．インテグリティ保護鍵
ＥＡＰ−ＥＸＴは、次の２つのタイプの鍵、１）ＥＡＰ−ＥＸＴ−ＫＥＹと２）ＥＡＰ−ＲＥＡＵＴＨ−ＫＥＹを定義する。

４．１ ＥＡＰ−ＥＸＴ−ＫＥＹ
ＥＡＰ−ＥＸＴ−ＫＥＹは、ＥＡＰ−ＥＸＴメッセージを保護するインテグリティのＡＵＴＨ ＴＬＶを計算するために使用される。ＨＭＡＣ−ＳＣＡ−２５６（例えば、以下に参照により組み込まれている参照文献［ｓｈａ２５６］参照）がインテグリティアルゴリズムのために使用されるとき、ＥＡＰ−ＥＸＴ−ＫＥＹの長さは３２オクテットである。ＥＡＰ−ＥＸＴ−ＫＥＹは、以下のように（例えば、以下に参照により組み込まれている参照文献［I-D.salowey-eap-emsk-deriv]参照)に定義されるＵＳＲＫ(Usage Specific Root Key）誘導アルゴリズムを使用して内部ＥＡＰメソッドによって生成されるＥＭＳＫから導出される。

ＥＡＰ−ＥＸＴ−ＫＥＹ＝ＫＤＦ（ＥＭＳＫ，“ＥＡＰ−ＥＸＴ−インテグリティ−鍵”，長さ）
ＫＤＦでは、ＥＡＰ−ＥＸＴ−ＫＥＹは、以下に参照により組み込まれている参照文献［I-D.salaowey-eap-emsk-deriv］に指定されるデフォルトのＰＲＦを使用する。

背景技術として、ＵＳＲＫ鍵導出関数（ＫＤＦ：key derivation function）は、拡張マスタセッション鍵（ＥＭＳＫ:Extended Master Session Key）、鍵ラベル、オプションデータ、及び出力長からＵＳＲＫを導出する。ＫＤＦは、同じ入力には同じ出力を与えることが期待される。基本的な鍵導出関数は、ＵＳＲＫ＝ＫＤＦ（ＥＭＳＫ、鍵ラベル、オプションデータ、長さ）である。同文献を参照。通常は、鍵ラベルは、使用定義ごとに一意の印刷可能ＡＳＣＩＩ文字列であり、最大２５５バイトである。同文献を参照。一般的には、鍵ラベルは、ドメインが、ＵＳＲＫの使用定義の詳細を制御する組織であるｌａｂｅｌ−ｓｔｒｉｎｇ＠ｄｏｍａｉｎの形となる。鍵ラベルはグローバルな一意性を提供する。これらのラベルのための割り当ての規則は、［I-D.salowey-eap-emsk-deriv］の第７項に示されている。

上記文献に説明されているように、ＥＭＳＫ鍵導出関数は、以下の関数プロトタイプを有する擬似ランダム関数（ＰＲＦ:pseudo random function）に基づいている。

ＫＤＦ＝ＰＲＦ（鍵、データ）。同文献参照。ＥＭＳＫからＵＳＲＫを導出するために使用されるデフォルトのＰＲＦは、ＨＭＡＣ−ＳＨＡ−２５６に基づく［ＲＦＣ４３０６］のＰＲＦ＋鍵拡張ＰＲＦから取り出される。ｐｒｆ＋構造は、［ＲＦＣ２２４６］の中で使用されるもののような他のＰＲＦに優るｐｒｆ＋構造の（ｉｔｓ）簡略さと効率のために選ばれた。［ＲＦＣ４３０６］からのＰＲＦ＋の定義が以下に示される。

ｐｒｆ＋（Ｋ，Ｓ）＝Ｔ１｜Ｔ２｜Ｔ３｜Ｔ４｜…
ここで、
Ｔ１＝ｐｒｆ（Ｋ，Ｓ｜０ｘ０１）
Ｔ２＝ｐｒｆ（Ｋ，Ｔ１｜Ｘ｜０ｘ０２）
Ｔ３＝ｐｒｆ（Ｋ，Ｔ２｜Ｘ｜０ｘ０３）
Ｔ４＝ｐｒｆ（Ｋ，Ｔ３｜Ｘ｜０ｘ０４）
鍵資料に必要とされる長さを計算するために必要に応じて続行する。

鍵Ｋは、ＥＭＳＫであり、Ｓは、［I-D.salowey-eap-emsk-deriv］のセクション３．１に定義されるデータである。同文献参照。上記のように、ＰＲＦはＨＭＡＣ−ＳＨＡ−２５６として受け取られる。同文献参照。

４．２ ＥＡＰ−ＲＥＡＡＵＴＨ−ＫＥＹ
ＥＡＰ−ＲＥＡＵＴＨ−ＫＥＹは、再認証メカニズムに使用されるＥＡＰメソッドによって必要とされる事前共有鍵として使用されている。ＥＡＰ−ＲＥＡＵＴＨ−ＫＥＹの長さは、再認証メカニズムに依存する。ＥＡＰ−ＲＥＡＵＴＨ−ＫＥＹは、以下に組み込まれている参照文献［I-D.salowey-eap-emsk-deriv］の中に定義されているＵＳＲＫ誘導アルゴリズムを使用してＥＡＰ−ＥＸＴからエクスポートされるＥＭＳＫから導出される。

ＥＡＰ−ＲＥＡＵＴＨ−ＫＥＹ＝ＫＤＦ（ＥＭＳＫ，“ＥＡＰ−ＥＸＴ−再認証−鍵”，長さ）
５．メッセージフォーマット
ＥＡＰ−ＥＸＴは、ＥＡＰタイプＸを使用する（ＩＡＮＡによって割り当てられる）。［ＲＦＣ３７４８］に定義される共通ＥＡＰフィールド（例えば、コード（Code）、識別子（Identifier）、長さ（Length）及びタイプ（Type）を含むメッセージフォーマットが、図３（Ａ）に示されている。

Ｆ：
このビットは、これが送信者からの最後のＥＡＰ−ＥＸＴメッセージであることを示すために設定される必要がある。それ以外の場合、このビットを設定する必要はない。

このビットは、メッセージがエラー表示であるときに設定される。このビットが設定されると、Ｆ−ビットも設定される必要がある。エラー表示の詳細な説明については第３節を参照すること。

バージョン（Version）：
この８ビットのフィールドは、ＥＡＰ−ＥＸＴメソッドのバージョンを示す。本願はバージョン１を定義する。

予約（Reserved）：
この６ビットのフィールドは将来の拡張のために予約されている。このフィールドは、送信者によってゼロに設定される必要があり、受信者はこのフィールドを無視する必要がある。

ケイパビリティ（Capabilities）
このフィールド、ケイパビリティフィールドは、拡張されたＥＡＰケイパビリティを含む。ケイパビリティフィールド、フォーマットが図３（Ｂ）に示されている。

各ビットはある特定のケイパビリティに対応する。各ビットのセマンティクスは以下の通りである。

Ｃ：
このビットは、送信者が、ＭＳＫのために［I-D.ohba-eap-channel-binding］に定義されるチャネルバインディング機構をサポートしていることを示すために設定される。このビットがリクエストとレスポンスの両方のために設定され、ＥＡＰ−ＥＸＴメソッドが無事に完了すると、ピアとサーバはチャネルバインディング機構を有効にする必要がある。ｐｒｆ＋のためのデフォルトハッシュアルゴリズムは、ＡＵＴＨ＿ＨＭＡＣ−ＳＨＡ１＿１６０である。

Ｒ：
このビットは、送信者が再認証（re-authentication）ＥＡＰメソッドをサポートすることを示すために設定される。このビットが最後のリクエスト／ＥＸＴメッセージで設定される（つまり、Ｆ−ビットが付いたリクエスト／ＥＸＴが設定される）とき、メッセージは、サーバ−ＩＤ ＴＬＶとピア−ＩＤ ＴＬＶ（ピア−ＩＤ ＴＬＶ）とを含む必要があり、Ｒｅａｕｔｈ−Ｋｅｙ−ライフタイムＡＶＰを含むことができる。このビットが最後のリクエスト／ＥＸＴとレスポンス／ＥＸＴ交換で設定されると、ピアとサーバはＥＡＰ−ＲＥＡＵＴＨ−ＫＥＹを生成する必要がある。サーバ−ＩＤ ＴＬＶとピア−ＩＤ ＴＬＶに含まれるサーバ−ＩＤとピア−ＩＤおよびＥＡＰ−ＲＥＡＵＴＨ−ＫＥＹは、再認証ＥＡＰメソッドに使用される。デフォルトの再認証機構は、本開示に基づいて当業者によって選択できる。

他のビットは将来の使用のために予約され、送信者によってゼロに設定される必要があり、受信者によって無視される必要がある。

ＴＬＶ（タイプ（Type）−長さ（Length）−値（Value‘s））：
ゼロ個、１個、または複数のＴＬＶ。ＴＬＶのフォーマットは図３（Ｃ）に示されている。

タイプ：
このフィールドは、このＴＬＶのタイプを示す。

長さ：
このフィールドは、このＴＬＶの長さをオクテット単位で示し、ＴＬＶのＴｙｐｅフィールドとＬｅｎｇｔｈフィールドを含む、
値：
このフィールドは、ＴＶＬ Ｔｙｐｅに特有なデータを含む。

６．ＥＡＰ−ＥＸＴ ＴＬＶ
以下のＴＬＶが定義される。

６．１ メソッドＴＬＶ（Ｍｅｔｈｏｄ ＴＬＶ）
メソッドＴＬＶ（タイプ１）は、タイプフィールドから開始するＥＡＰメソッドペイロードを含む。

６．２ ＡＵＴＨ ＴＬＶ
ＡＵＴＨ ＴＬＶ（タイプ２）は、ＥＡＰ−ＥＸＴメッセージを保護するために使用されるインテグリティデータを含む。ＥＡＰ−ＥＸＴ−ＫＥＹは、ＡＵＴＨ ＴＬＶを計算するために使用される。

ＴＬＶ−値（Value）フィールドは、このフィールドを含むＥＡＰメッセージ全体で計算される。インテグリティデータを計算する前に、このフィールドは全てゼロに初期化される必要がある。このフィールドの長さは、使用中のインテグリティアルゴリズムに依存する。インテグリティチェックが失敗すると、メッセージは静かに破棄される必要がある。デフォルトのインテグリティアルゴリズムはＨＭＡＣ−ＳＨＡ−２５６である（例えば、以下に組み込まれる参考資料［ｓｈａ２５６］を参照）。

６．３ ピア−ＩＤ ＴＬＶ
ピア−ＩＤ ＴＬＶ（タイプ３）は、再認証に使用されるピアのアイデンティティを含む。

６．４ サーバ−ＩＤ ＴＬＶ
サーバ−ＩＤ ＴＬＶ（タイプ４）は、再認証に使用されるサーバのアイデンティティを含む。

６．５ Ｒｅａｕｔｈ−Ｋｅｙ−ライフタイム ＴＬＶ
Ｒｅａｕｔｈ−Ｋｅｙ−ライフタイム ＴＬＶ（タイプ５）は、ＥＡＰ−ＲＥＡＵＴＨ−ＫＥＹの秒単位のライフタイム（有効期間）を含む。

７．セキュリティの考慮すべき事項
内部ＥＡＰメソッドがＥＡＰキーイング資料をエクスポートする前のケイパビリティ交換は、保護されていない。したがって、ＥＡＰキーイング資料の作成後の追加の保護メッセージの交換は、ピアとサーバによって検出されることなく攻撃者によってケイパビリティ情報が改変されるのを回避するように指示されている。

ＥＡＰ−ＥＸＴは、ＥＡＰ−ＥＸＴの内部の複数のＥＡＰメソッドの連鎖を可能にする。暗号でメソッドを拘束することなく、複数の入れ子または順次認証メソッドからなる複合認証方法が、介入者攻撃に脆弱性を有することは公知である。ＥＡＰ−ＥＸＴは、外部ＥＡＰメソッド（ＥＡＰ−ＥＸＴ）とともにそれぞれの内部ＥＡＰメソッドを、シーケンスの中のそれに先行する成功した内部メソッドによって生成された鍵で保護し、最後に成功した内部ＥＡＰメソッドによって生成されたＥＡＰキーイング資料を最終的にエクスポートすることによって、必要とされるバインディングを暗号で作成できる。暗号バインディングを達成するために、ＥＡＰ−ＥＸＴは、内部ＥＡＰメソッドがＥＡＰキーイング資料を生成できることを必要とする。

以下に示す先行技術文献は、参照によりその全体がここに組み込まれる。

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]と呼ぶ) Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos Network Authentication Service (V5)", RFC 4120, July 2005 (ここでは[RFC4120]と呼ぶ). Zhu, L. and B. Tung, "Public Key Cryptography for Initial Authentication in Kerberos (PKINIT)", RFC 4556, June 2006 (ここでは[RFC4556]と呼ぶ)

本発明は、前述されたシステム及び方法を含む既存のシステム及び方法を改良する。

いくつかの好ましい実施形態によれば、ＥＡＰからケルベロスをブートするためのシステム及び方法が提供される（ここでＢＫＥと呼ばれている）。とりわけ、複数のネットワークアプリケーションをサポートするために、好ましい実施形態は、有利にケルベロスをＥＡＰから利用できるようにする。とりわけ、好ましい実施形態は、例えば、―ケルベロスのための新しいケイパビリティビットを含む−ＥＡＰ−ＥＸＴメソッド（ＥＡＰ−ＥＸＴに関連する背景技術の説明参照）の中の新しいケイパビリティを定義する。

いくつかの実施形態によれば、モバイル機器がＥＡＰからケルベロスをブートするための方法は、ＥＡＰがモバイル機器の初回ネットワークアクセス認証のために使用され、ケルベロスが複数のネットワークアプリケーションをサポートするために複数の異なるプロトコルにセッション鍵をセットアップために使用される。該方法は、ケルベロスに関連するＥＡＰ拡張機能に関するケイパビリティについてＥＡＰサーバと交渉するＥＡＰピアをもつモバイルノードを構成し、ケルベロス機能に関して、該ＥＡＰサーバと該ＥＡＰピアとの間のケイパビリティ交換を提供するＥＡＰ拡張メソッド（ＥＡＰ−ＥＸＴ）を適用することを含む。該方法は、ＥＡＰピアが、ケルベロス機能に関連するケイパビリティフィールドに新しいケイパビリティビット（Ｋ）を有する、ＥＡＰサーバから送信されるリクエストメッセージを受信することと、ＥＡＰピアに、ケルベロス機能に関連するケイパビリティフィールドに新しいケイパビリティビット（Ｋ）を有するレスポンスメッセージを送信させることとを含む。いくつかの例では、該方法はさらに、ＥＡＰピアがＥＡＰサーバからリクエストメッセージを受信するときと、ＥＡＰピアがＡＵＴＨ ＴＬＶが設定されたＫ−ビットをもつレスポンスメッセージを送信するときとの両方で、ＥＡＰピアにＥＡＰサーバから送信されるケルベロスブートストラッピングパラメータを受信させることとを含む。いくつかの例では、該方法は、ＥＡＰピアに、新しいケルベロスブートＴＬＶ（ＫＲＢ−ＢＯＯＴ）を適用するＥＡＰサーバから送信されるケルベロスブートストラッピングパラメータを受信させることを含む。いくつかの例では、該方法は、ＥＡＰピアに、次に、ケルベロスＡＳ−ＲＥＱメッセージをＥＡＰサーバに送信させることを含み、ＡＳ−ＲＥＱメッセージはケルベロスメッセージＴＬＶ（ＫＲＢ−ＭＳＧ）に含まれている。いくつかの例では、該方法は、ＥＡＰサーバに、次に、ケルベロス鍵配布センタにＡＳ−ＲＥＱメッセージを転送させることと、鍵配布センタに、ＡＳ−ＲＥＰをＥＡＰサーバへ返させることと、ＥＡＰサーバに、ＥＡＰピアへＡＳ−ＲＥＰを転送させることとを含み、ＡＳ−ＲＥＰはＫＲＢ−ＭＳＧ ＴＬＶに含まれている。いくつかの例では、該方法は、ＥＡＰ拡張メソッド（ＥＡＰ−ＥＸＴ）からエクスポートされるＥＭＳＫから導出される、ケルベロスによって必要とされる事前共有鍵（ＥＡＰ−ＫＲＢ−ＫＥＹ）を生成することを含む。いくつかの例では、該方法は、ＥＡＰ−ＫＲＢ−ＫＥＹ＝ＫＤＦ（ＥＭＳＫ，“ＥＡＰ−ＥＸＴ−ケルベロス−ブートストラッピング−鍵”，長さ）であるＵＳＲＫ導出アルゴリズムを使用してＥＡＰ−ＥＸＴからエクスポートされるＥＭＳＫから導出される、ケルベロスによって要求される事前共有鍵（ＥＡＰ−ＫＲＢ−ＫＥＹ）を生成することを含む。

いくつかの実施形態によれば、アクセスしたドメインまたはホームドメインでのネットワークアクセスのための初回認証が、ドメインの中で使用される複数の異なるプロトコルにセッション鍵をセットアップために使用される単一サインオンを実行するモバイルノードのための方法が提供される。該方法は、ＥＡＰが初回ネットワークアクセス認証のために使用され、ケルベロスが複数の異なるプロトコルにセッション鍵をセットアップために使用されるＥＡＰからケルベロスをブートするようにモバイル機器を構成することと、ドメイン内でハンドオーバのためのＥＡＰシグナリングをなくすことによって、リンク層ハンドオーバパフォーマンスを最適化するためにリンク層プロトコルにセッション鍵をセットアップこととを含む。いくつかの例では、該方法は、ケルベロス機能に関して、ＥＡＰサーバとＥＡＰピアとの間のケイパビリティ交換を提供するＥＡＰ拡張メソッド（ＥＡＰ−ＥＸＴ）を適用することを含み、ＥＡＰピアに、ケルベロス機能に関連するケイパビリティフィールドに新しいケイパビリティビット（Ｋ）を有する、ＥＡＰサーバから送信されるリクエストメッセージを受信させることと、ＥＡＰピアに、ケルベロス機能性に関連するケイパビリティフィールドに新しいケイパビリティビット（Ｋ）を有するレスポンスメッセージを送信させることとを含む。

いくつかの実施形態によれば、ドメイン内でのネットワークアクセスのための初回認証が、当該ドメイン内で使用される複数の異なるプロトコルにセッション鍵をセットアップために使用される単一サインオンをモバイル機器が実行するためのシステムを提供する。該システムは、ａ）ＥＡＰがモバイル機器の初回ネットワークアクセス認証のために使用され、ケルベロスが複数のネットワークアプリケーションをサポートするために複数の異なるプロトコルにセッション鍵をセットアップために使用される、どちらもＥＡＰからケルベロスをブートするように構成されたモバイル機器及びサーバを含み、ｂ）該モバイル機器及び該サーバは、ケルベロス機能に関してＥＡＰサーバとＥＡＰピアの間でケイパビリティ交換を提供するＥＡＰ拡張メソッド（ＥＡＰ−ＥＸＴ）を適用することを含み、ケルベロスに関連するＥＡＰ拡張機能に関するケイパビリティについて交渉するように構成されている。ｉ）前記サーバは、前記ケルベロス機能に関連するケイパビリティフィールドに新しいケイパビリティビット（Ｋ）を有するリクエストメッセージをＥＡＰピアに送信するように構成されたＥＡＰサーバを有し、ｉｉ）前記モバイル機器は、前記ケルベロス機能に関連するケイパビリティフィールドに新しいケイパビリティビット（Ｋ）を有するレスポンスメッセージを送信するように構成されたＥＡＰピアを有する。

上記及び／または他の発明、態様、種々の実施形態の特徴及び／または利点は、添付の図を参照した以下の説明に鑑みてさらに理解されるであろう。種々の実施形態は、適用できる異なる複数の態様、特徴、及び／または利点を含み及び／または除外することがある。加えて、種々の実施形態は、適用できる他の実施形態の１または複数の態様を組み合わせることができる。特定の実施形態の態様、特長、及び／または利点の説明は、他の実施形態または請求項を制限するとして解釈されてはならない。

いくつかの実施形態に係る、単一内部メソッドを有する、ＥＡＰサーバとＥＡＰピアとの間のＥＡＰ−ＥＸＴメッセージシーケンスを説明する図。 いくつかの実施形態に係る、複数の内部メソッドを有する、ＥＡＰサーバとＥＡＰピアとの間のＥＡＰ−ＥＸＴメッセージシーケンスを説明する図。 ＥＡＰ−ＥＸＴに関連するいくつかの例示的な実施形態に係るメッセージフォーマットを説明する図。 ＥＡＰ−ＥＸＴに関連するいくつかの例示的な実施形態に係るケイパビリティフィールドを説明する図。 ＥＡＰ−ＥＸＰに関連するいくつかの例示的な実施形態に係るＴＬＶフォーマットを説明する図。 本発明のいくつかの例示的な実施形態に係るメッセージフォーマットを説明する図。 本発明のＢＫＥ機能を適用したいくつかの実施形態係るメッセージシーケンスを示し、クライアント／ピア、サーバ及びＫＤＣの間のメッセージシーケンスを示す。 本発明のＢＫＥ機能を適用したいくつかの実施形態係るメッセージシーケンスを示し、クライアント／ピア、サーバ、オーセンティケータ及びＫＤＣの間のメッセージシーケンスを示す。 ＢＫＥ機能を適用したいくつかの実施形態係る他のメッセージシーケンスを示し、さらにＴＧＳ−ＲＥＱ／ＲＥＰを含む。 参考のためにケルベロスメッセージシーケンスを示した図。 参考のためにＥＡＰメッセージシーケンスを示した図。 いくつかの実施形態に係る機器に適用されることのあるくつかのアーキテクチャ構成要素を示す図。

本発明の好ましい実施形態は、例によって説明されるが、添付の図面に限定されることはない。

本発明は、多くの異なる形態で実施され得るが、説明された多くの実施形態は、本開示は本発明の要旨の例を与えるものとして考慮されること、及び、これら例は本発明をここに記載、及び／または説明された好ましい実施形態に限定するものではないことを理解した上で、ここに開示されている。

いくつかの好ましい実施形態によれば、ＥＡＰからケルベロスをブートするためのシステム及び方法が提供される（本願ではＢＫＥと呼ばれている）。とりわけ、複数のネットワークアプリケーションをサポートするために、好ましい実施形態は、有利に、ケルベロスをＥＡＰから利用できるようにする。

とりわけ、好ましい実施形態は、例えば、ＥＡＰ−ＥＸＴメソッド（ＥＡＰ−ＥＸＴに関連する背景技術の説明参照）内に新たなケイパビリティを定義し、これは、ケルベロスのための新しいケイパビリティビットを含む。

１．イントロダクション
ケルベロス［ＲＦＣ４１２０］は、共有秘密鍵暗号を使用することにより、オープン（保護されていない）ネットワーク上で多様なネットワークアプリケーションのエンドポイントのアイデンティティを検証する手段を提供する第三者認証プロトコルである。ケルベロスへの拡張は、認証プロトコルの特定のフェーズの間の公開鍵暗号の使用に備えることができる［ＲＦＣ４５５６］。

ＥＡＰ（Extensible Authentication Protocol拡張認証プロトコル）は、「ＥＡＰメソッド」［ＲＦＣ３７４８］として知られている複数の認証アルゴリズムをサポートする認証プロトコルである。しかしながら、ＥＡＰの適用性は、ネットワークアクセスの認証のためである。ＥＡＰは、多様なネットワークアプリケーションに認証を与えるために設計されていない。

参考のために、以下のテーブル１は、ケルベロスとＥＡＰの相違点のいくつかを浮き彫りにするチャートである。

アクセスしたドメインまたはホームドメインにおいてネットワークアクセスのための初回認証が、リンク層プロトコルからアプリケーション層プロトコルに及ぶ、ドメイン内で使用される複数の異なるプロトコルにセッション鍵をセットアップできる単一サインオンに対する新しいニーズがある。

特に、リンク層プロトコルにセッション鍵をセットアップすると、オーセンティケータ内ハンドオーバ及びオーセンティケータ間ハンドオーバを含む、ドメイン内のあらゆるハンドオーバのためにＥＡＰシグナリングを排除することによりリンク層ハンドオーバ性能を最適化できる。

本願は、ＥＡＰが初回ネットワークアクセス認証のために使用され、ケルベロスが複数の異なるプロトコルにセッション鍵をセットアップするために使用される、ＥＡＰからケルベロスをブートするための機構を説明する。本願は、この機構を実現するためにＥＡＰ−ＥＸＴ方法論を利用する。

２．好ましい実施形態の概要
好ましい実施形態によれば、ケルベロスのための新しいケイパビリティビットを含む、新しいケイパビリティが（前述された）ＥＡＰ−ＥＸＴ方法論の中で定義される。

この好ましい実施形態は、ケイパビリティフィールドで新しいケイパビリティビット（Ｋ）、及びＥＡＰ−ＥＸＴの新しいＴＬＶ（例えば、ＫＲＢ−ＢＯＯＴ ＴＬＶとＫＲＢ−ＭＳＧ ＴＬＶ）も定義する。この好ましい実施形態では、この新しいケイパビリティビット（Ｋ）とこれらの新しいＴＬＶは以下のように利用される。

ＥＡＰ−ＥＸＴ交換では、ピアとサーバは、本発明の機能（このような機能は本願ではＢＫＥと呼ばれている）を使用することを望む場合、ケイパビリティフィールドにＫ−ビットを設定する。ピアとサーバの両方ともＡＵＴＨ ＴＬＶとともにＫ−ビットを設定する場合、好ましい実施形態では、システムは以下のように追加のＥＡＰ−ＥＸＴ交換を利用する。

サーバは、最初にケルベロスブートストラッピングパラメータをピアに送信する。好ましくは、ケルベロスブートストラッピングパラメータは、ケルベロス−ブート（ＫＲＢ−ＢＯＯＴ）ＴＬＶに含まれている。次に、ピアがケルベロスＡＳ−ＲＥＱメッセージをサーバに送信し、ここではＡＳ−ＲＥＱメッセージは、ケルベロス−メッセージ（ＫＲＢ−ＭＳＧ）ＴＬＶに含まれている。次にサーバはＡＳ−ＲＥＱメッセージをケルベロスＫＤＣ（鍵配布センタ）に転送する。それから、ＫＤＣはＡＳ−ＲＥＰをサーバに戻すが、シグナリングのこの部分はＥＡＰ−ＥＸＴの外部で実行される。サーバは、ピアにＡＳ−ＲＥＰを転送し、ＡＳ−ＲＥＰはＫＲＢ−ＭＳＧ ＴＬＶに含まれている。

最後に、ピアはサーバに確認を送信し、サーバはＥＡＰ−成功メッセージまたはＥＡＰ−失敗メッセージをピアに送信する。好ましい実施形態では、これらの交換のすべては、ＡＵＴＨ ＴＬＶで保護される必要がある。

ケルベロスがＥＡＰからブートされた後にどのように使用されるのかは、状況に基づき当業者が決定することができ、これに関連する詳細は本発明の目的のために必要とされていない。

図１は、ＢＫＥを用いるＥＡＰ−ＥＸＴメッセージシーケンスの例を示す。

３．新しいメッセージフォーマット
好ましい実施形態によれば、上記に示されたように、ＥＡＰ−ＥＸＴのケイパビリティフラグの中に新しいビット―すなわち、新しいＫビットが定義される。

図４に、本願の好ましい実施形態に係るＥＡＰ−ＥＸＴメッセージフォーマットに対する変更を示す。

このＫビットは、ＥＡＰからケルベロスをブートするためのサポートを示している（本願ではＢＫＥと呼ばれている）。好ましい実施形態では、いったんピアとサーバの両方が、ＫビットをＡＵＴＨ ＴＬＶとともに設定すると、追加の交換が前述されたようにＥＡＰ−ＥＸＴの中で実行される。

４．新しい鍵
好ましい実施形態では、１つの新しい鍵が、本発明の機能を提供するために定義される。この新しい鍵は、ＥＡＰ−ＫＲＢ−ＫＥＹと呼ばれている。ＥＡＰ−ＫＲＢ−ＫＥＹは、ケルベロスによって必要とされる事前共有鍵として使用される。好ましい実施形態では、ＥＲＰ−ＫＲＢ−ＫＥＹの長さ及びライフタイムは、ＥＡＰ−ＥＸＴの中でサーバからピアに通信される。例えば、ＥＲＰ−ＫＲＢ−ＫＥＹの長さはＥＡＰ−ＥＸＴの中で交渉される。好ましい実施形態では、ＥＡＰ−ＫＲＢ−ＫＥＹ鍵は、ＥＡＰ−ＥＸＴからエクスポートされるＥＭＳＫから導出され、その際、例えば、以下のように、上記に参照により組み込まれる参考文献［I-D.salowey-eap-emsk-deriv］で定義されるＵＳＲＫ誘発アルゴリズムを使用する。

ＥＡＰ−ＫＲＢ−ＫＥＹ＝ＫＤＦ（ＥＭＳＫ，“ＥＡＰ−ＥＸＴ−ケルベロス− ブートストラッピング−鍵”，長さ）
ＫＤＦでは、ＥＡＰ−ＥＸＴ−ＫＲＢは、［I-D.salowey-eap-emsk-deriv］に指定されるデフォルトのＰＲＦを使用する。

５．新しいＥＡＰ−ＥＸＴ ＴＬＶ
好ましい実施形態によれば、以下の新しい複数のＴＬＶが定義される。

５．１ ケルベロス−ブート（ＫＲＢ−ＢＯＯＴ）ＴＬＶ
好ましい実施形態によれば、ケルベロスブートストラッピングパラメータを含む新しいケルベロス−ブート ＴＬＶ（タイプ６）が確立される。好ましい実施形態では、以下のケルベロスブートストラッピングパラメータが、この順で含まれる。

ａ）ＥＡＰ−ＫＲＢ−ＫＥＹ長（２オクテット）
好ましい実施形態では、このフィールドはオクテット単位でＥＡＰ−ＫＲＢ−ＫＥＹの長さを示す。

ｂ）ＥＡＰ−ＫＲＢ−ＫＥＹ ライフタイム（２オクテット）
好ましい実施形態では、このフィールドは秒単位でＥＡＰ−ＫＲＢ−ＫＥＹのライフタイム（有効期間）を示す。ライフタイム、ＥＭＳＫのライフタイムを超える必要がある。

ｃ）プリンシパルネーム（可変長）
好ましい実施形態では、このフィールドには、ピアのケルベロスプリンシパルネームが入り、ＡＳＮ．１（抽象構文記法１:Abstract Syntax NotaionOne）のＤＥＲ（識別符号化規則：Distinguished Encoding Rules）によって符号化される。ＡＳＮ．１の識別符号化規則は、Ｘ．５０９による基本符号化規則（ＢＥＲ:basic encoding rule）符号化に課される制約から引き出された国際規格である。抽象構文記法１（ＡＳＮ．１）は、コンピュータ間で送信されるデータ構造が、どのようにして符号化、及び復号されるのかを決定する以下の規則セットを定義する。つまり、基本符号化規則（ＢＥＲ）、正規化符号化規則（ＣＥＲ:Canonical Encoding Rules）、識別符号化規則（ＤＥＲ:Distinguished Encoding Rules）、及びパック符号化規則（ＰＥＲ:Packed Encoding Rules）である。元の規則セットは、ＢＥＲ仕様によって定義されていた。ＣＥＲとＤＥＲはＢＥＲの特殊化された部分集合として後に作成された。ＰＥＲは、ＢＥＲまたはその変形を使用してデータを送信するために必要とされる帯域幅の量についての批判に応えて開発された。ＰＥＲはかなりの節約を与える。ＤＥＲは安全なデータ転送のためにＸ．５０９仕様の要件を満たすために作成された。例えば、信任状登録ＡＰＩ（Certificate Enrollment API）はＤＥＲを独占的に使用する。参考のために、International Telecommunication Union, Information Technology - ASN.1 Encoding Rules - Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER), and Distinguished Encoding Rules (DER), ITU-T Recommendation X.690, July 2002を参照されたい。この全体的な開示は、参照によりここに組み込まれる。

ｄ）Ｒｅａｌｍ（レルム）（可変長）
好ましい実施形態では、このフィールドは、ピアのケルベロスレルムと、ＫＤＣを含み、ＡＳＮ．１（抽象構文記法１）のＤＥＲ（識別符号化規則）によって符号化される。

ｅ）ＩＰアドレス長（１オクテット）
好ましい実施形態では、このフィールドにはＫＤＣのＩＰアドレスの長さが入る。

ｆ）ＫＤＣのＩＰアドレス（４または１６オクテット）
好ましい実施形態では、このフィールドにはＫＤＣのバイナリ符号化されたＩＰアドレスが入る。ＩＰアドレス長が４である場合、このフィールドには好ましくはＩＰｖ４アドレスが入る。ＩＰアドレス長が１６である場合、このフィールドには好ましくはＩＰｖ６アドレスが入る。

５．２ ケルベロス−メッセージ（ＫＲＢ−ＭＳＧ）ＴＬＶ
好ましい実施形態では、ケルベロス−メッセージ ＴＬＶ（ケルベロス−メッセージ）（タイプ７）が、ＡＳ−ＲＥＱメッセージとＡＳ−ＲＥＰメッセージ等のケルベロスメッセージ（例えばＤＥＲで符号化されたメッセージ）を含む。

６．０ メッセージ交換シーケンスの具体例
図５から図９は、構成要素またはモジュール間の通信の具体例を描く、いくつかのメッセージ交換シーケンスを示す。

この点で、図５から図７は、本発明の好ましい実施形態のＢＫＥ機能を利用するいくつかの具体的な実施形態によるメッセージシーケンスを示す。ここでは、図５は、クライアント／ピア１０、サーバ３０、及び鍵配布センタ（ＫＤＣ）４０の間のメッセージシーケンスを示し、図６と図７は、クライアント／ピア１０、サーバ３０、オーセンティケータ２０、及びＫＤＣ（４０）の間のメッセージシーケンスを示す。

この点で、クライアント／ピア１０は、好ましい実施形態では、例えば携帯電話、パーソナルコンピュータ、ラップトップコンピュータ、ウェアラブルコンピュータ、ＰＤＡ等のモバイルノードまたはモバイル機器に含まれる。この点で、クライアント／ピア１０は、（図６と図７で緑で表されている）ＥＡＰピアと、（図６と図７で赤で表されている）ケルベロスクライアントの機能を含むことができる。

図５に示されるように、クライアント／ピア１０、サーバ３０、及び鍵配布センタ（ＫＤＣ）４０の間のような通信は、ＢＫＥを利用するいくつかの実施形態において以下のようである場合がある。

第１に、図５のａ）で示されるように、サーバ３０は随意にＥＡＰ−リクエスト／アイデンティティをピア１０に送信し、ピア１０は、図５のｂ）に示されるように随意にＥＡＰ−レスポンス／アイデンティティをサーバ３０に送信することができる。

次に、図５のｃ）で示されるように、サーバ３０はピア１０にＥＡＰ−リクエスト／ＥＸＴ｛Ｃａｐ．（Ｋ），メソッド｝を送信する。ここで、Ｃａｐ．（Ｋ）は、メッセージがケイパビリティフィールドセットのＫビットを有することを示し、メソッドはメソッドＴＬＶに関連する。これに応じて、図５のｄ）で示されるように、ピア１０は、サーバ３０にＥＡＰ−レスポンス／ＥＸＴ｛Ｃａｐ．（Ｋ），メソッド｝メッセージを送信できる。

次に、図５のｅ）に示されるように、サーバ３０は、ピア１０にＥＡＰ−リクエスト／ＥＸＴ｛Ｃａｐ．（Ｋ），ＡＵＴＨ｝メッセージを送信する。ここでは、Ｃａｐ．（Ｋ）は、メッセージがケイパビリティフィールドセットのＫビットを有することを示し、ＡＵＴＨはＡＵＴＨ ＴＬＶに関連する。これに応じて、図５のｆ）に示されるように、ピア１０は、サーバ３０にＥＡＰ−レスポンス／ＥＸＴ｛Ｃａｐ．（Ｋ），ＡＵＴＨ｝メッセージを送信できる。

次に、図５のｇ）に示されるように、サーバ３０はピア１０にＥＡＰ−リクエスト／ＥＸＴ｛Ｃａｐ．（Ｋ），ＫＲＢ−ＢＯＯＴ，ＡＵＴＨ｝メッセージを送信する。ここでは、Ｃａｐ．（Ｋ）は、メッセージがケイパビリティフィールドセットのＫビットを有することを示し、ＫＲＢ−ＢＯＯＴ（ケルベロスブートストラッピングパラメータを含む）は、ケルベロスブートＴＬＶに関連し、ＡＵＴＨはＡＵＴＨ ＴＬＶに関連する。これに応じて、図５のｈ）に示されるように、ピア１０はサーバ３０にＥＡＰ−レスポンス／ＥＸＴ｛Ｃａｐ．（Ｋ），ＫＲＢ−ＭＳＧ，ＡＵＴＨ｝メッセージを送信できる。ここでは、ＡＳ−ＲＥＱメッセージは、ケルベロス−メッセージＴＬＶ（ＫＲＢ−ＭＳＧ）に含まれている。

図５のｌ）に示されるように、サーバ３０は、ＫＤＣにケルベロスブートストラッピングパラメータも送信する。

加えて、図５のｍ）に示されるように、次にサーバ３０はＡＳ−ＲＥＱメッセージをケルベロスＫＤＣ（鍵配布センタ）に転送する。その後、図５のｎ）に示されるように、ＫＤＣは、サーバにＡＳ−ＲＥＰメッセージを返す。シグナリングのこの部分はＥＡＰ−ＥＸＴの外部で実行される。

次に、図５のｉ）に示されるように、サーバ３０はピア１０にＡＳ−ＲＥＰを転送し、ＡＳ−ＲＥＰはＫＲＢ−ＭＳＧ ＴＬＶに含まれている。その点で、サーバ３０は、示されているように、ｉ）でＥＡＰ−リクエスト／ＥＸＴ｛Ｃａｐ．（Ｋ），ＫＲＢ−ＭＳＧ，ＡＵＴＨ｝メッセージを送信する。

最後に、ピアはサーバに確認を送信し、サーバはピアにＥＡＰ−成功メッセージまたはＥＡＰ−失敗メッセージを送信する。ここでは好ましくは、図５のｊ）に示されるように、ピア１０はサーバ３０にＥＡＰ−レスポンス／ＥＸＴ｛Ｃａｐ．（Ｋ），ＡＵＴＨ｝メッセージを送信し、サーバ３０はピア１０にＥＡＰ−成功メッセージを送信する。

好ましい実施形態は、これらの交換のすべてはＡＵＴＨ ＴＬＶで保護される必要がある。

図６に関して、この図は図５に示されているメッセージシーケンスに実質的に類似している。しかしながら、図６は、さらにオーセンティケータ２０に関してメッセージ交換を示す。この点で、図５のステップｊ）の後、図６のｘ）に示されるように、サーバはオーセンティケータ２０にＭＳＫを送信し、次にｙ）で、ピア／クライアントとオーセンティケータの間に安全なアソシエーションが確立される。

図７は、ＢＫＥ機能を適用し、さらにＴＧＳ−ＲＥＱ／ＲＥＰを含む、いくつかの具体的な実施形態に係る他のメッセージシーケンスである。背景技術の参照として、ケルベロスでは、クライアントはチケット交付サーバ（ＴＧＳ）に、アプリケーションサーバと通信するために必要とされるチケットを要求する。ＴＧＳによって生成されるチケットは、すべてアプリケーションサーバの鍵で暗号化されるクライアントのアイデンティティと、セッション鍵とを含む。ＴＧＳは、すべてクライアントの鍵で暗号化されているチケットとセッション鍵のコピーをクライアントに返す。しかしながら、この交換は、独力でクライアントのアイデンティティの保証を提供しない。クライアントのアイデンティティの保証は、チケットを検証することに基づくクライアントとアプリケーションサーバの間の別の交換によって行われる。ＴＧＳは、チケットを発行することによってクライアントのアイデンティティに合意する。クライアントとアプリケーションサーバは、ＴＧＳによって発行されるチケットを検証することによってクライアントのアイデンティティに合意する。クライアントのアイデンティティに関する三者合意が、クライアントとアプリケーションサーバの間のセッション鍵の所有の暗号証拠に基づいて安全に行われ、チケットはセッション鍵とクライアントのアイデンティティの間に結合を有する。

図７を参照すると、ｘ１）に示されるように、ピア１０はサーバ３０にＥＡＰ−レスポンス／ＥＸＴ｛Ｆ，ＫＲＢ−ＭＳＧ（ＴＧＳ−ＲＥＱ），ＡＵＴＨ｝のメッセージを送信し、ｘ２）に示されるように、サーバ３０はＫＤＣにＴＧＳ−ＲＥＱを送信する。次にＫＤＣは、図７のｙ２）に示されるようにＴＧＳ−ＲＥＰを返す。次に、サーバ３０は、ＥＡＰ−リクエスト／ＥＸＴ｛Ｆ，ＫＲＢ−ＭＳＧ（ＴＧＳ−ＲＥＰ），ＡＵＴＨ｝のフォーマットのメッセージをピア１０に送信する。その後、ピアは前述されたものと同様なＥＡＰ−レスポンス／ＥＸＴ｛Ｆ，ＡＵＴＨ｝を送信する。

参考のために、図８には、アプリケーションクライアント（Ｃ）、アプリケーションサーバ（Ｓ）、及び鍵配布センタ（ＫＤＣ）の関与するケルベロスメッセージシーケンスの具体例が示され、ＫＤＣはチケット交付サーバ（ＴＧＳ）と、認証サーバ（ＡＳ）とを含む。この具体例では、次の３つのメッセージステップが示されている。つまり、ａ）シーケンスのステップＳ１は、オーセンティケータを提示し、ＴＧＴを取得することを含む。（これに関し、１００に示されるように、ＡＳ＿ＲＥＱメッセージがオーセンティケータサーバ（ＡＳ）に送信され、１１０に示されるように、ＡＳ＿ＲＥＰメッセージがオーセンティケータサーバから送信される。）２）シーケンスのステップＳ２は、ＴＧＴを提示し、チケットを取得することを含む。（これに関し、１２０に示されるように、ＴＧＳ＿ＲＥＱメッセージがチケット交付サーバ（ＴＧＳ）に送信され、１３０に示されるように、ＴＧＳ＿ＲＥＰメッセージがＴＧＳサーバから送信される。）
参考のために、図９は、ピア、オーセンティケータ、及びサーバが関与するＥＡＰメッセージシーケンスの具体例を示す。この図では、メッセージ２００はサーバからのＥＡＰ−リクエストを示し、メッセージ２０１はピアからのＥＡＰ−レスポンスを示し、メッセージ２０２はサーバからのＥＡＰ−成功メッセージを示し、メッセージ２０３はサーバからのＭＳＫメッセージを示し、２０４は確立された安全なアソシエーション（下位層）を示す。ここでは、オーセンティケータはピアにネットワークアクセスサービスを提供する。いくつかの実施形態では、オーセンティケータとサーバは別々の装置で実現できるが、いくつかの実施形態では、オーセンティケータとサーバは、同じ装置で実現されてよい。別々の装置で実現されるとき、オーセンティケータは、ピアとサーバとの間のＥＡＰメッセージの「通過地点」転送者の役割を務める。

コンピュータアーキテクチャの具体例：
図１０は、いくつかの具体的な実施形態において、例えばピア、クライアント、サーバ、オーセンティケータ、モバイル機器、アクセスポイント等のデバイスまたはエンティティによって実行されるプロセスステップ及び通信を実現するために使用できるコンピュータまたはこれに類似する構造の具体例を示す。いくつかの実施形態では、このようなデバイスまたはエンティティは、バス３２６上で１つまたは複数の入力／出力（Ｉ／Ｏ）デバイス３２４と通信できる中央演算処理装置（ＣＰＵ）３２２を含む。Ｉ／Ｏデバイス３２４は、例えば、１つまたは複数のキーパッド、１または複数のディスプレイ、及び／または他のデバイスを含むことがある。デバイスは、通信のために送信機、受信機、及び／または（例えば、アンテナ等を適用する）トランシーバを含むことがあり、通信は、本開示に基づいて当業者に理解されるように適切な装置機能を実現するために、無線通信、有線通信等を適宜に含むことがある。ＣＰＵ３２２は、バス３２６でコンピュータ読み取り可能媒体（例えば、従来の揮発性または不揮発性のデータ記憶デバイス）３２８（以後「メモリ３２８」）と通信できる。ＣＰＵ３２２、Ｉ／Ｏデバイス３２４、バス３２６、及びメモリ３２８の間の相互作用は、当分野で公知のものである。メモリ３２８は、例えばデータ３３０を含むことがある。メモリ３２８は、ソフトウェア３３８を記憶することもある。ソフトウェア３３８はプロセスのステップを実現するための多くのモジュール３４０を含むことがある。従来のプログラミング技法は、これらのモジュールを実現するために使用されてよい。メモリ３２８は、上記の及び／または他の１つまたは複数のデータファイルも含むことがある。いくつかの実施形態では、本願に説明されている多様な方法は、コンピュータシステムと使用するためにコンピュータプログラムを介して実現されてよい。このインプリメンテーションは、例えば、コンピュータ読み取り可能な媒体（例えば、ディスケット、ＣＤ−ＲＯＭ、ＲＯＭ等）上に固定される、あるいは例えばモデム等のインタフェース装置を介してコンピュータシステムに送信できる一連のコンピュータ命令を含んでよい。通信媒体は、実質的には有形（例えば通信回線）であってよい、及び／あるいは実質的に無形（例えばマイクロ波、光、赤外線等を使用する無線媒体）であってよい。コンピュータ命令は、多様なプログラミング言語で作成されてもよく、及び／または例えば半導体デバイス（例えば、チップまたは回路）、磁気デバイス、光学デバイス、及び／または他の記憶デバイス等の１つまたは複数の記憶デバイスに記憶することができる。多様な実施形態では、伝送は任意の適切な通信技術を使用してよい。

Claims (17)

1. モバイル機器が拡張認証プロトコル（以下「ＥＡＰ」）からケルベロスをブートするための方法であって、
   ＥＡＰが前記モバイル機器の初回ネットワークアクセス認証のために使用され、ケルベロスが、複数のネットワークアプリケーションをサポートするために複数の異なるプロトコルにセッション鍵をセットアップするために使用され、
   ａ）ケルベロスに関連するＥＡＰ拡張機能に関するケイパビリティについてＥＡＰサーバと交渉するＥＡＰピアをもつモバイルノードを構成し、ケルベロス機能に関して、該ＥＡＰサーバと該ＥＡＰピアとの間のケイパビリティ交換を提供するＥＡＰ拡張メソッド（ＥＡＰ−ＥＸＴ）を適用することを含み、
   ｉ）前記ＥＡＰピアが、ケルベロス機能に関連するケイパビリティフィールドの中に新しいケイパビリティビット（Ｋ）を有する、前記ＥＡＰサーバから送信されるリクエストメッセージを受信することと、
   ｉｉ）前記ＥＡＰピアに、前記ケルベロス機能に関連するケイパビリティフィールドに新しいケイパビリティビット（Ｋ）を有するレスポンスメッセージを送信させることと、を含む方法。
2. 前記ＥＡＰピアが前記ＥＡＰサーバからリクエストメッセージを受信するときと、前記ＥＡＰピアがＡＵＴＨ ＴＬＶが設定されたＫビットをもつレスポンスメッセージを送信するときとの両方で、前記ＥＡＰピアに、前記ＥＡＰサーバから送信されるケルベロスブートストラッピングパラメータを受信させることとをさらに含む、請求項１記載の方法。
3. 前記ＥＡＰピアに、新しいケルベロスブートＴＬＶ（ＫＲＢ−ＢＯＯＴ）を適用する前記ＥＡＰサーバから送信されるケルベロスブートストラッピングパラメータを受信させることをさらに含む、請求項２記載の方法。
4. 前記ＥＡＰピアに、その後、前記ＥＡＰサーバへのケルベロスＡＳ−ＲＥＱメッセージを送信させることをさらに含み、前記ＡＳ−ＲＥＱメッセージはケルベロスメッセージＴＬＶ（ＫＲＢ−ＭＳＧ）に含まれる請求項３記載の方法。
5. 前記ＥＡＰサーバに、その後、ケルベロス鍵配布センタへの前記ＡＳ−ＲＥＱメッセージを送信させることと、
   前記鍵配布センタに、ＡＳ−ＲＥＰを前記ＥＡＰサーバに返させることと、
   前記ＥＡＰサーバに、前記ＡＳ−ＲＥＰを前記ＥＡＰピアに転送させることと、
   をさらに含み、前記ＡＳ−ＲＥＰがＫＲＢ−ＭＳＧ ＴＬＶに含まれている請求項４記載の方法。
6. 前記ＥＡＰ拡張メソッド（ＥＡＰ−ＥＸＴ）からエクスポートされるＥＭＳＫから導出されるケルベロスによって必要とされる事前共有鍵（ＥＡＰ−ＫＲＢ−ＫＥＹ）を生成することをさらに含む、請求項５記載の方法。
7. ＥＡＰ−ＫＲＢ−ＫＥＹ＝ＫＤＦ（ＥＭＳＫ，“ＥＡＰ−ＥＸＴ−ケルベロス−ブートストラッピング−鍵”，長さ）であるＵＳＲＫ誘導アルゴリズムを用いて、ＥＡＰ−ＥＸＴからエクスポートされるＥＭＳＫから導出される、ケルベロスによって必要とされる事前共有鍵（ＥＡＰ−ＫＲＢ−ＫＥＹ）を生成することをさらに含む、請求項６記載の方法。
8. アクセスしたドメインまたはホームドメインでのネットワークアクセスのための初回認証が、当該ドメインの中で使用される複数の異なるプロトコルにセッション鍵をセットアップするために使用される単一サインオンをモバイルノードが実行するための方法であって、
   ａ）拡張認証プロトコル（以下「ＥＡＰ」）が初回ネットワークアクセス認証のために使用され、ケルベロスが複数の異なるプロトコルにセッション鍵をセットアップするために使用されるＥＡＰから、ケルベロスをブートするように前記モバイル機器を構成することと、
   ｂ）前記ドメインの中でのハンドオーバのためにＥＡＰシグナリングを排除することにより、リンク層ハンドオーバパフォーマンスを最適化するためにリンク層プロトコルにセッション鍵をセットアップすることと、
   を含み、
   ケルベロス機能に関して、前記ＥＡＰサーバと前記ＥＡＰピアとの間のケイパビリティ交換を提供するＥＡＰ拡張メソッド（ＥＡＰ−ＥＸＴ）を適用することと、
   前記ＥＡＰピアに、前記ケルベロス機能に関連するケイパビリティフィールドに新しいケイパビリティビット（Ｋ）を有する、前記ＥＡＰサーバから送信されるリクエストメッセージを受信させることと、
   前記ＥＡＰピアに、ケルベロス機能に関連するケイパビリティフィールドに新しいケイパビリティビット（Ｋ）を有するレスポンスメッセージを送信させることと、
   を含む方法。
9. ドメインの中でのネットワークアクセスのための初回認証が、前記ドメインの中で使用される複数の異なるプロトコルにセッション鍵をセットアップするために使用される単一サインオンをモバイル機器が実行するためのシステムであって、
   ａ）拡張認証プロトコル（以下「ＥＡＰ」）がモバイル機器の初回ネットワークアクセス認証のために使用され、ケルベロスが複数のネットワークアプリケーションをサポートするために複数の異なるプロトコルにセッション鍵をセットアップために使用される、どちらもＥＡＰからケルベロスをブートするように構成されたモバイル機器及びサーバを含み、
   ｂ）前記モバイル機器及び前記サーバは、ケルベロス機能に関してＥＡＰサーバとＥＡＰピアの間でケイパビリティ交換を提供するＥＡＰ拡張メソッド（ＥＡＰ−ＥＸＴ）を適用することを含み、ケルベロスに関連するＥＡＰ拡張機能に関するケイパビリティについて交渉するように構成され、
   ｉ）前記サーバは、ケルベロス機能に関連するケイパビリティフィールドに新しいケイパビリティビット（Ｋ）をもつリクエストメッセージをＥＡＰピアに送信するように構成されたＥＡＰサーバを有し、
   ｉｉ）前記モバイル機器は、前記ケルベロス機能に関連するケイパビリティフィールドの中に新しいケイパビリティビット（Ｋ）をもつレスポンスメッセージを送信するように構成された前記ＥＡＰピアを有するシステム。
10. 前記ＥＡＰサーバは、前記ＥＡＰサーバが前記ＥＡＰピアにリクエストメッセージを送信するときと、前記ＥＡＰサーバが前記ＥＡＰピアからＫビットをもち、ＡＵＴＨ ＴＬＶが設定されているレスポンスメッセージを受信するときとの両方で、前記ＥＡＰサーバが前記ＥＡＰピアにケルベロスブートストラッピングパラメータを送信するように構成されている請求項９記載のシステム。
11. 前記ＥＡＰサーバは、新しいケルベロスブートＴＬＶ（ＫＲＢ−ＢＯＯＴ）を適用して、前記ＥＡＰピアにケルベロスブートストラッピングパラメータを送信するように構成されている請求項１０に記載のシステム。
12. 前記ＥＡＰピアは、次に、ケルベロスＡＳ−ＲＥＱメッセージを前記ＥＡＰサーバに送信するように構成され、前記ＡＳ−ＲＥＱメッセージはケルベロスメッセージＴＬＶ（ＫＲＢ−ＭＳＧ）の中に含まれている請求項１１記載のシステム。
13. 前記ＥＡＰサーバは、前記ＡＳ−ＲＥＱメッセージをケルベロス鍵配布センタに転送するように構成されている請求項１２記載のシステム。
14. 前記ＥＡＰサーバにＡＳ−ＲＥＰを返すように構成される鍵配布センタをさらに含む、請求項１３記載のシステム。
15. 前記ＡＳ−ＲＥＰを前記ＥＡＰサーバに転送するように構成されている前記ＥＡＰサーバをさらに含み、前記ＡＳ−ＲＥＰはＫＲＢ−ＭＳＧ ＴＬＶに含まれている請求項１４記載のシステム。
16. 前記システムは、ケルベロスによって必要とされる事前共有鍵（ＥＡＰ−ＫＲＢ−ＫＥＹ）を生成するように構成される請求項９記載のシステム。
17. ケルベロスによって必要とされる前記事前共有鍵（ＥＡＰ−ＫＲＢ−ＫＥＹ）は、
    ＥＡＰ−ＫＲＢ−ＫＥＹ＝（ＥＭＳＫ，“ＥＡＰ−ＥＸＴ−ケルベロス−ブートストラッピング−鍵”，長さ）である、ＵＳＲＫ誘導アルゴリズムを使用してＥＡＰ拡張メソッド（ＥＡＰ−ＥＸＴ）からエクスポートされるＥＭＳＫから導出される請求項１６記載のシステム。

Images