リアクティブオペレーションのために最適化されるケルベロス化ハンドオーバキーイング
【課題】サーバ、オーセンティケータ及びモバイルノードの間の安全キー配信のためにケルベロスを使用するメディア独立ハンドオーバキー管理アーチテクチャを提供する。
【解決手段】好適実施形態では、キー配信のための信号伝達は再キーイングに基づいており、ＥＡＰ（拡張認証プロトコル）及び初期ネットワークアクセス認証と同様なＡＡＡ（認証、許可及び課金）信号伝達を要求する再認証から切り離す。このフレームワークにおいて、モバイルノードはハンドオーバ以前に１セットのオーセンティケータと通信しないでそれらとのセキュリティ関連性を動的に確立するために必要とするマスタセッションキーを取得できる。再キー動作を再認証から分離することによって、提案のアーチテクシャは事前モード動作のためにより最適化される。それはモバイルノードとターゲットアクセスノードとの間でキー配信役割を逆転することによってリアクティブモード動作のために最適化もし得る。
【解決手段】好適実施形態では、キー配信のための信号伝達は再キーイングに基づいており、ＥＡＰ（拡張認証プロトコル）及び初期ネットワークアクセス認証と同様なＡＡＡ（認証、許可及び課金）信号伝達を要求する再認証から切り離す。このフレームワークにおいて、モバイルノードはハンドオーバ以前に１セットのオーセンティケータと通信しないでそれらとのセキュリティ関連性を動的に確立するために必要とするマスタセッションキーを取得できる。再キー動作を再認証から分離することによって、提案のアーチテクシャは事前モード動作のためにより最適化される。それはモバイルノードとターゲットアクセスノードとの間でキー配信役割を逆転することによってリアクティブモード動作のために最適化もし得る。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はメディア独立ハンドオーバキー管理アーチテクチャに関する。
【背景技術】
【０００２】
本出願は２００７年３月１日付で提出した、ケルベロス化ハンドオーバキーイングの改良として名称付けた、仮出願番号：６０／８９２，５３２の非仮出願であるとして米国特許法１１９に基づいて請求している。
【０００３】
一般的背景検討
背景出願
背景文献として、次の特許出願の各々の全開示は参照することにより本明細書に援用される。１）２００７年１月１９日付で提出され、ケルベロス化ハンドオーバキーイングと名称付けられた、仮出願：Ｎｏ．６０／８８５，７９５、２）全ての追加を含む、２００７年３月１日付で提出された、ケルベロス化ハンドオーバキーイングの改良と名称付けられた、仮出願：Ｎｏ．６０／８９２，５３２、３）２００７年１０月４日付で提出された、ＥＡＰ拡張（ＥＡＰ−ＥＸＴ）のためのＥＡＰ方法と名称付けられた、非仮出願：Ｎｏ．１１／８６７，６５９、及び４）２００７年１１月２４日付で提出された、ＥＡＰからケルベロスのブートストラップと名称付けられた、非仮出願：Ｎｏ． １１／９４４，６０５。
【０００４】
ネットワーク及びインターネット（登録商標）プロトコル
多様なコンピュータネットワークがあり、インターネットは最も有名である。インターネットは、コンピュータネットワークの世界規模のネットワークである。今日、インターネットは、何百万人ものユーザが利用可能な、公衆の自律的ネットワークである。インターネットは、ＴＣＰ／ＩＰ（すなわち、伝送制御プロトコル／インターネットプロトコル）と呼ばれる１組の通信プロトコルを使って各ホストを接続する。インターネットは、インターネットバックボーンとして呼ばれる通信インフラストラクチャを有する。インターネットバックボーンへのアクセスは大部分企業及び個人へのアクセスを再販するインターネットサービスプロバイダ（ＩＳＰ）によって制御される。
【０００５】
ＩＰ（インターネットプロトコル）に関して、これは、ネットワーク上である装置（電話機、ＰＤＡ［携帯情報端末］、コンピュータなど）から別の装置にデータを送るためのプロトコルである。今日、ＩＰｖ４、ＩＰｖ６などを含めて、様々なＩＰのバージョンがある。ネットワーク上の各ホスト装置は、独自の一意の識別子である少なくとも１つのＩＰアドレスを有する。
【０００６】
ＩＰはコネクションレス型プロトコルである。通信時の端点間接続は連続的ではない。ユーザがデータ又はメッセージを送信し、又は受信するとき、データ又はメッセージは、パケットと呼ばれる要素に分割される。各パケットは、独立のデータ単位として扱われる。
【０００７】
インターネット又は同様なネットワークを介した地点間の伝送を標準化するために、ＯＳＩ（開放型システム間相互接続）モデルが確立された。ＯＳＩモデルは、ネットワーク中の２地点間の通信プロセスを７つの階層に分け、各層は独自の機能セットを付加する。各装置は、送信側端点では各層を通る下り回線（downward flow）があり、受信側端点では各層を通る上り回線（upward flow）があるようにメッセージを取り扱う。７つの機能層を提供するプログラミング及び／又はハードウェアは、通常、デバイスオペレーティングシステム、アプリケーションソフトウェア、ＴＣＰ／ＩＰ及び／又は他のトランスポート及びネットワークプロトコル、並びに他のソフトウェア及びハードウェアの組み合わせである。
【０００８】
通常、上位４層は、メッセージがユーザから、又はユーザへ渡されるときに使用され、下位３層は、メッセージが装置（ＩＰホスト装置など）を通過するときに使用される。ＩＰホストは、サーバ、ルータ、ワークステーションなど、ＩＰパケットを送受信することのできるネットワーク上の任意の装置である。他の何らかのホストに向けられているメッセージは、各上位層には通過させないが、他のホストに送られる。ＯＳＩモデル及び他の同様なモデルでは、ＩＰが層３、ネットワーク層にある。
【０００９】
無線ネットワーク：
無線ネットワークは、例えば、セルラ及び無線電話機、ＰＣ（パーソナルコンピュータ）、ラップトップコンピュータ、装着型コンピュータ、コードレス電話機、ポケットベル、ヘッドセット、プリンタ、ＰＤＡなど、多種多様なモバイル機器を組み込むことができる。例えば、モバイル機器は、音声及び／又はデータの高速無線伝送を確保するデジタルシステムを含むことができる。一般的なモバイル機器は、次の構成要素の一部又は全部、即ち送受信機（すなわち、例えば、送信機、受信機及び、必要に応じて、他の機能が統合されたシングルチップ送受信機などを含む、送信機及び受信機）、アンテナ、プロセッサ、１つ又は複数の音声変換器（例えば、音声通信用機器でのスピーカやマイクロホンなど）、電磁データ記憶（データ処理が提供される機器の場合などでの、ＲＯＭ、ＲＡＭ、デジタルデータ記憶など）、メモリ、フラッシュメモリ、フルチップセット又は集積回路、インターフェース（ＵＳＢ、ＣＯＤＥＣ、ＵＡＲＴ、ＰＣＭなど）及び／又は同種のものを含む。
【００１０】
モバイルユーザが無線接続を介してローカルエリアネットワーク（ＬＡＮ）に接続することのできる無線ＬＡＮ（ＷＬＡＮ）が、無線通信に用いることができる。無線通信には、例えば、光、赤外線、電波、マイクロ波などの電磁波を介して伝搬する通信などが含めることができる。現在、ブルートゥース（登録商標）、ＩＥＥＥ８０２．１１、ＨｏｍｅＲＦなど、様々なＷＬＡＮ標準が存在する。
【００１１】
一例として、ブルートゥース製品は、モバイルコンピュータ、モバイル電話機、携帯式ハンドヘルド機器、携帯情報端末（ＰＤＡ）、及び他のモバイル機器の間のリンク、並びにインターネットへの接続を提供するのに使用できる。ブルートゥースは、モバイル機器が、短距離無線接続を使って、相互に、また非モバイル機器と、どのようにして容易に相互接続し合うことができるかを詳述するコンピュータ及び電気通信業界仕様である。ブルートゥースは、ある機器と別の機器との間でデータを同期させ、整合させ続けることを必要とする、様々なモバイル機器の普及から生じるエンドユーザ問題に対処して、異なるベンダからの装置を相互にシームレスに動作させるデジタル無線プロトコルを作成する。ブルートゥース機器は、共通の名称概念に従って名称付けできる。例えば、ブルートゥース機器は、ブルートゥース機器名（ＢＤＮ）又は一意のブルートゥース機器アドレス（ＢＤＡ）に関連付けられた名称を持ち得る。また、ブルートゥース機器は、インターネットプロトコル（ＩＰ）ネットワークに参加することもできる。ブルートゥース機器がＩＰネットワーク上で機能する場合、この機器は、ＩＰアドレス及びＩＰ（ネットワーク）名を備えることができる。よって、ＩＰネットワークに参加するように構成されたブルートゥース機器は、ＢＤＮ、ＢＤＡ、ＩＰアドレス及びＩＰ名などを含むことができる。「ＩＰ名」という用語は、インターフェースのＩＰアドレスに対応する名称を指す。
【００１２】
ＩＥＥＥ標準であるＩＥＥＥ８０２．１１は、無線ＬＡＮ及び機器の技術の仕様を定める。８０２．１１を使えば、各単一基地局がいくつかの機器をサポートする無線ネットワークが実現できる。いくつかの例では、機器に無線ハードウェアが事前装備されていることもあり、ユーザが、アンテナを含めることができ、カードなどの別個のハードウェアをインストールすることもできる。例えば、８０２．１１で使用される機器は、通常、機器がアクセスポイント（ＡＰ）であるか、移動局（ＳＴＡ）であるか、ブリッジであるか、ＰＣＭＣＩＡカードであるか、それとも別の機器であるか否かを問わず、無線送受信機、アンテナ、及びネットワークにおける各点間のパケットの流れを制御するＭＡＣ（媒体アクセス制御）層という３つの注目すべき要素を含む。
【００１３】
更に、いくつかの無線ネットワークでは、複数インターフェース機器（ＭＩＤ）が利用できる。ＭＩＤは、ブルートゥースインターフェースと８０２．１１インターフェースなど、２つの独立のネットワークインターフェースを含むことができ、よって、ＭＩＤが２つの別個のネットワーク上に参加すると同時に、ブルートゥース機器ともインターフェースすることが可能になる。ＭＩＤは、ＩＰアドレス、及びＩＰアドレスに関連付けられた共通ＩＰ（ネットワーク）名を持つことができる。
【００１４】
無線ネットワーク機器には、それだけに限らないが、ブルートゥース機器、複数インターフェース機器（ＭＩＤ）、８０２．１１ｘ機器（８０２．１１ａ、８０２．１１ｂ、８０２．１１ｇ機器などを含む、ＩＥＥＥ８０２．１１機器）、ＨｏｍｅＲＦ（家庭内無線周波数）機器、Ｗｉ−Ｆｉ（Wireless Fidelity）機器、ＧＰＲＳ（汎用パケット無線システム）機器、３Ｇセルラ機器、２．５Ｇセルラ機器、ＧＳＭ（移動通信用グローバルシステム）機器、ＥＤＧＥ（Enhanced Data for GSM Evolution）機器、ＴＤＭＡ型（時分割多重接続）機器、又はＣＤＭＡ２０００を含むＣＤＭＡ型（符号分割多重接続）機器が含めることができる。各ネットワーク機器は、それだけに限らないが、ＩＰアドレス、ブルートゥース機器アドレス、ブルートゥース共通名、ブルートゥースＩＰアドレス、ブルートゥースＩＰ共通名、８０２．１１ＩＰアドレス、８０２．１１ＩＰ共通名、又はＩＥＥＥ ＭＡＣアドレスを含む、様々な種類のアドレスを含むことができる。
【００１５】
また、無線ネットワークは、例えば、モバイルＩＰ（インターネットプロトコル）システム、ＰＣＳシステム、及び他のモバイルネットワークシステムにおいて見られるメソッド及びプロトコルも関与できる。モバイルＩＰでは、これに、インターネット技術標準化委員会（ＩＥＴＦ）によって作成された標準通信プロトコルが関与する。モバイルＩＰでは、モバイル機器ユーザは、これらの一旦割り当てられたＩＰアドレスを維持しつつ、各ネットワークにまたがって移動することができる。コメントリクエスト（ＲＦＣ）３３４４を参照されたい。注：ＲＦＣはインターネット技術標準化委員会（ＩＥＴＦ）の公式文書である。モバイルＩＰは、インターネットプロトコル（ＩＰ）を拡張し、モバイル機器のホームネットワーク外部に接続するときに、モバイル機器にインターネットトラフィックを転送する手段を付加する。モバイルＩＰは、各モバイルノードに、これのホームネットワーク上のホームアドレスと、ネットワーク及びこれのサブネット内の機器の現在位置を識別する気付アドレス（ＣｏＡ）を割り当てる。機器が異なるネットワークに移動すると、機器は、新しい気付アドレスを受け取る。ホームネットワーク上のモビリティエージェントは、各ホームアドレスを、これの気付アドレスと関連付けることができる。モバイルノードは、インターネット制御メッセージプロトコル（ＩＣＭＰ）などを使って、これの気付アドレスを変更する都度ホームエージェントにバインディング更新を送ることができる。
【００１６】
（例えば、モバイルＩＰ外部などの）基本的なＩＰ経路指定において、経路指定機構は、各ネットワークノードが、常に、インターネットなどへの一定の接続点を有し、かつ各ノードのＩＰアドレスが、これが接続されているネットワークリンクを識別するという仮定を利用する。本明細書において、「ノード」という用語は、例えば、データ伝送のための再配信点や端点などを含むことができ、他のノードへの通信を認識し、処理し、及び／又は転送することのできる接続点を含む。例えば、インターネットルータは、機器のネットワークを識別するＩＰアドレスなどを調べることができる。次いで、ネットワークレベルにおいて、ルータは、特定のサブネットを識別するビットセットを調べることができる。次いで、サブネットレベルにおいて、ルータは、特定の機器を識別するビットセットを調べることができる。一般的なモバイルＩＰ通信の場合、ユーザが、例えば、インターネットなどからモバイル機器を切断し、これを新しいサブネットで再接続しようとする場合、機器は、新しいＩＰアドレス、適正なネットマスク及びデフォルトのルータを用いて再構成する必要がある。そうでなければ、経路指定プロトコルは、パケットを適正に配信することができないはずである。
【００１７】
ケルベロス（Kerberos）に関する背景
ケルベロスはネットワーク認証プロトコルである。http://web.mit.edu/Kerberos/を参照。それは秘密キー暗号文を用いてクライアント／サーバアプリケーションの認証を行う。このプロトコルの自由な実施はマサチューセッツ工科大学から利用可能である。ケルベロスは更に多くの商品に利用できる。
【００１８】
ケルベロスはコンピュータネットワークにおけるサービスの要求を認証するための確実な方法である。ケルベロスはユーザに認証プロセスから暗号化チケットを要求させる。このとき、認証プロセスはサーバから特定のサービスを要求するために使用できる。ユーザのパスワードはネットワークを通過する必要がない。
【００１９】
ケルベロス［ＲＦＣ１５１０］は認証、許可及びキー配信を与える周知のセキュリティプロトコルである。それは複数のプロトコルを確保するために使用される。
【００２０】
ケルベロスはユーザがパスワードを再入力する必要がなくクライアントＡがチケット付与サービス（Ticket Granting Service (TGS)）をアクセスする初期チケットを取得することを可能にする。その初期チケットはクライアントＡがサービスＢをアクセスするための他のチケットを得るためＴＧＳとのケルベロル取り決めを開始することを可能にする。この方法を用いることによって、ケルベロスもＡが（ビジテッドドメイン（visited domain）において）ローカルＴＧＳをアクセスするため（Ａのホームドメインにおける）リモートＴＧＳからチケットを回復できる場合にクロスレルムオペレーション（cross-realm operation）を可能にする。しかしながら、ケルベロスは３人のメンバ間で時間同期を必要とする。
【００２１】
幾つかの例では、ＥＡＰフレームワークの柔軟性と大学でのケルベロスの幅広い展開とを組合すことによってケルベロスチケット付与チケットをブートすることが可能になる。このときこのケルベロスチケット付与チケットは各種プロトコルと共に使用するためサービスチケットを探索するために使用できる。ＥＡＰプロトコル相互作用を利用してケルベロスチケットをブートするこの方法は［I-D.tschofenig-pana-bootstrap-kerberos］に開示されている。その全ての開示は参照することにより本願に援用される。
【００２２】
ＥＡＰとケルベロスとを組み合わせる他の方法はＥＡＰ利用事前認証機構（EAP-based pre-authentication mechanism）をケルベロスに統合することである。しかしながら、証明をブートする一般的なプロトコルを使用することは（ＭＩＰｖ６ブートストラッピングワーク［I-D.ietf-mip6-bootstrap-ps］の一部として検討されているような）使用モバイルＩＰのための対象キーをブートするためにも又は公開／個人キーをブートするためにも利用できる。故に、一時公開及び個人キー対をエンドホストに送ることを機密保護する必要がある。このキー対は取り消し機構を多分必要としないで、短寿命であり、（ＩＫＥｖ２又はＴＬＳを含む）公開キー利用機構を利用する全てのセキュリティプロトコルにおいて使用できる。対称暗号化に基づく認証プロトコルはなおＥＡＰ内で使用できるので、回避された公開キー基盤が大きな利点となる。以下のセクションで検討するように、拡張可能認証プロトコル（Extensible Authentication Protocol (EAP)）［全体的に本願に引用して援用されるＲＦＣ３７４８を参照］が認証メソッドを提供する。幾つかの例では、ＰＡＮＡプロトコル［I-D.ietf-pana-pana］はアクセスネットワークにおいてＰａＣ（ＰＡＮＡクライアント）とＰＡＡ（ＰＡＮＡ認証エージェント）と間でＥＡＰメッセージを伝える。
【００２３】
ＥＡＰに関する背景
（以下に引用する）Ａｂｏｂａ，ＲＦＣ ３７４８を参照すると、拡張可能認証プロトコル（ＥＡＰ）の具体的態様が説明されている。ＥＡＰは複数の認証メソッドをサポートする認証フレームワークである。ＥＡＰは一般的にはＩＰを必要としない、ポイントツーポイントプロトコル（ＰＰＰ）又はＩＥＥＥ８０２のような複数のデータリンク層上で直接に実行する。ＥＡＰは二重削除及び再送信のため独自のサポートを備えているが、下位層順の保証に依存する。断片化はＥＡＰ自体内でサポートされないが、個々のＥＡＰメソッドがこれをサポートできる。
【００２４】
ＥＡＰは切換回路だけでなく、専用リンクに使用でき、無線リンクだけでなく有線であってもよい。今まで、ＥＡＰはＰＰＰ ［ＲＦＣ１６６１］を用いて切換回路又はダイアルアップネットワークを介して接続するホスト及びルータによって実現されていた。それはまたＩＥＥＥ ８０２［ＩＥＥＥ−８０２］を用いてスイッチ及びアクセスポイントによっても実現されていた。ＩＥＥＥ ８０２有線媒体に関するＥＡＰカプセル化が［ＩＥＥＥ−８０２．１Ｘ］に説明されており、ＩＥＥＥ無線ＬＡＮｓに関するカプセル化は［ＩＥＥＥ−８０２．１１ｉ］に開示されている。
【００２５】
ＥＡＰアーチテクチャの利点の１つはその柔軟性にある。ＥＡＰは、特定の認証機構を選択するため、一般的にはオーセンティケータ（authenticator）が使用すべき特定の認証メソッドを決定するためにより多くの情報を要求した後に選択するために使用される。各新しい認証メソッドをサポートするために更新されることをオーセンティケータが必要とする以外に、ＥＡＰは幾つか又は全てのメソッドに対するパススルーとして行動するオーセンティケータ及びピアによって、幾つか又は全ての認証メソッドを実施できるバックエンド認証サーバの使用を可能にする。
【００２６】
この後者の引用文献の中で、オーセンティケータがパススルーとして行動するか否かに関係なくオーセンティケータの要求が適用される。要求がオーセンティケータ又はバックエンド認証サーバのいずれかに適用されることを意味している場合、ＥＡＰ認証が終了される場所に依存して、用語「ＥＡＰサーバ」が使用されている。
【００２７】
ＥＡＰは再送信のサポートを行っている間、それは下位層によって提供される順序付け保証を仮定し、故に異常のある受信はサポートされない。
【００２８】
ＥＡＰは断片化及び再構築をサポートしないので、最小ＥＡＰ ＭＴＵより大きなペイロードを生成するＥＡＰ認証メソッドは断片化サポートを提供する必要がある。
【００２９】
ＥＡＰ−ＴＬＳのような認証メソッドは断片化及び再構築を提供するが、この後者の引用文献で定義されたＥＰＡメソッドは行わない。その結果、ＥＡＰパケットサイズがリンクのＥＡＰ ＭＴＵを越えれば、これらのメソッドは困難に合うことになる。
【００３０】
ＥＡＰ認証はサーバ（オーセンティケータ）によって初期化されるが、多くの認証プロトコルはクライアント（ピア）によって初期化される。その結果、ＥＡＰを通過するために１つ又は２つの追加メッセージ（多くとも１往復）を追加することが認証アルゴリズムに必要となるかもしれない。
【００３１】
証明利用認証がサポートされる場合、追加往復の数は証明書チェーン（certificate chains）の断片化によりかなり多くなるかもしれない。一般的に、断片化ＥＰＡパケットは断片があるだけ多くの往復で送る必要がある。例えば、サイズが１４９６０オクテットの証明書チェーンは１４９６オクテットＥＡＰ ＭＴＵで１０往復する必要がある。ＥＡＰが重大なパケットロスを起こす下位層を繰り返す場合、又はオーセンティケータと認証サーバとの接続が重要なパケットロスを起こす場合、多くの往復を必要とするＥＡＰメソッドは困難に直面することもある。これらの状況において、少ない往復を用いたＥＡＰメソッドの使用が望まれる。
【００３２】
ＥＡＰ認証交換は次のように処理される。
【００３３】
［１］オーセンティケータはピアを認証するためリクエスト（Request）を送る。リクエストは要求されているものを示すタイプフィールドを有する。リクエストタイプの例は識別（Identity）、ＭＤ５−チャレンジなどを含む。ＭＤ５−チャレンジタイプはＣＨＡＰ認証プロトコルに密接に対応する［ＲＦＣ１９９４参照］。一般的には、オーセンティケータは初期認証リクエストを送ることになるが、初期認証リクエストは必要とされなく、バイパスされないこともある。例えば、識別はピアが接続されているポート（専用回線、専用スイッチ又はダイアルアップポート）によって決定される場合、又は識別が（ＭＤ５−チャレンジレスポンスなどのネームフィールドにおいて、呼出局識別又はＭＡＣアドレスを介して）他のメソッドで得られる場合には要求されないこともある。
【００３４】
［２］ピアは有効リクエストに答えてレスポンスパケット（Response packet）を送る。リクエストパケットと同様に、レスポンスパケットはリクエストのタイプフィールドに対応するタイプフィールドを含む。
【００３５】
［３］オーセンティケータは追加リクエストパケットを送り、ピアはレスポンスで答える。リクエスト及びレスポンスのシーケンスは必要なだけ継続する。ＥＡＰは‘横並び（lock step）’プロトコルであり、故に、初期リクエスト以外は、新たなリクエストは有効なレスポンを受理する前に送ることができない。オーセンティケータはリクエストを再送信する責任がある。適正数の再送信の後には、オーセンティケータはＥＡＰ対話を終了すべきである。オーセンティケータは再送信するとき、又はピアからのレスポンスが得られないときには成功又は失敗パケットを送る必要がない。
【００３６】
［４］対話はオーセンティケータがピア（１以上のリクエストに対して受入れがたいレスポンス）を認証できなくなるまで続けられる。この場合、オーセンティケータの実行にはＥＡＰ失敗（コード４）を送信する必要がある。あるいは、認証対話は認証が成功したことをオーセンティケータが決定するまで継続する。この場合、オーセンティケータはＥＡＰ成功（コード３）を送信する必要がある。
【００３７】
他の利点では、ＥＡＰプロトコルは特定のものを事前に取り決めする必要が無く多くの認証機構をサポートできる。更に、ネットワークアクセスサーバ（ＮＡＳ）装置（例えば、スイッチ又はアクセスポイント）は各認証メソッドを理解する必要が無く、バックエンド認証サーバに対するパススルーエージェントとして動作できる。パススルーのためのサポートは随意的である。オーセンティケータはローカルピアを認証でき、更に、同時に非ローカルピア及びローカル的には実行しない認証メソッドに対するパススルーとして作用する。更に、バックエンド認証サーバからオーセンティケータを分離することによって証明管理及びポリシー決定を簡単にする。
【００３８】
概念的に、ＥＡＰ実施は次の要素からなる。
【００３９】
［ａ］下位層。下位層はピアとオーセンティケータとの間でＥＡＰを送受信する義務がある。ＥＡＰはＰＰＰ，有線ＩＥＥＥ８０２ラン［ＩＥＥＥ−８０２．１Ｘ］， IEEE 802.11 wireless LANs ［ＩＥＥＥ−８０２．１１］，ＵＤＰ（Ｌ２ＴＰ ［ＲＦＣ２６６１］及びＩＫＥｖ２参照）及びＴＣＰを含む各種下位層上で実行していた。
【００４０】
［ｂ］ＥＡＰ層。ＥＡＰ層は下位層を介してＥＡＰパケットを送受信し、二重検出及び再送信を実行し、ＥＡＰメッセージをＥＡＰピア及びオーセンティケータ層に送信し、オーセンティケータ層から受信する。
【００４１】
［ｃ］ＥＡＰピア及びオーセンティケータ層。コードフィールドに基づいて、ＥＡＰ層は入力ＥＡＰパケットをＥＡＰピア及びオーセンティケータ層に分離する。一般的には、所定ホストでのＥＡＰ実行はピア又はオーセンティケータ機能のいずれかをサポートすることになるが、ホストがＥＡＰピア及びオーセンティケータの両方として作用することを可能にする。そのような実行においては、ＥＡＰ及びオーセンティケータ層の両方が存在することになる。
【００４２】
［ｄ］ＥＡＰメソッド層。ＥＡＰメソッドはオーセンティケータアルゴリズムを実行し、ＥＡＰピア及びオーセンティケータ層を介してＥＡＰメッセージを送受信する。断片化のサポートはＥＡＰ自体によっては得られないが、これはＥＡＰメソッドの責任である。ｉｄ．
以後の参考文献はここに参照として引用される次の定義を説明している。
【００４３】
オーセンティケータ：
ＥＡＰ認証を初期化するリンクの終端。期間オーセンティケータは［ＩＥＥＥ−８０２．１Ｘ］に使用され、この文献では同様の意味を有する。
【００４４】
ピア：
オーセンティケータに応答するリンクの終端。［ＩＥＥＥ−８０２．１Ｘ］では、この終端はサプリカント（Supplicant）として知られている。
【００４５】
バックエンド認証サーバ：
バックエンド認証サーバは認証サービスをオーセンティケータに提供するエンティティ（entity）である。使用時には、このサーバは一般的にはオーセンティケータのためにＥＡＰメソッドを実行する。この専門用語は［ＩＥＥＥ−８０２．１Ｘ］に使用されている。
【００４６】
ＡＡＡ：
ＥＡＰサポートを持つ認証、許可、及び課金（Authentication, Authorization, and Accounting(ＡＡＡ)）プロトコルはＲＡＤＩＵＳ及びダイアミタ（Diameter）を含む。この文献では、用語“ＡＡＡサーバ”及び“バックエンド認証サーバ”は交換可能に使用される。
【００４７】
ＥＡＰサーバ又はサーバ：
ピアによってＥＡＰ認証メソッドを終了するエンティティ。バックエンド認証サーバが使用されない場合には、ＥＡＰサーバはオーセンティケータの一部である。オーセンティケータがパススルーモードで動作する場合、ＥＡＰサーバはバックエンド認証サーバに設けられる。
【００４８】
成功した認証：
この文献の内容では、「成功した認証」はＥＡＰメッセージの交換であり、その結果オーセンティケータはピアによってアクセスできることを決定し、ピアがこのアクセスを使用することを決定する。オーセンティケータの決定は一般的には認証及び許可面の両方を含み、ピアはオーセンティケータに首尾良く証明できるが、アクセスは政策的理由によりオーセンティケータによって拒絶されるかもしれない。
【００４９】
マスタセッションキー（ＭＳＫ）：
ＥＡＰピアとサーバ間で得られ、ＥＡＰメソッドによって転送されるキーイングマテリアル。ＭＳＫは長さが少なくとも６４オクテットである。既存の実施では、ＥＡＰサーバとして作用するＡＡＡサーバはＭＳＫをオーセンティケータに送る。
【００５０】
拡張マスタセッションキー（ＥＭＳＫ）：
ＥＡＰクライアントとサーバとの間で得られ、ＥＡＰ法によって転送される追加キーイングマテリアル。ＥＭＳＫは長さが少なくとも６４オクテットである。ＥＭＳＫはオーセンティケータ又は任意の他の第三者によっては共有されない。ＥＭＳＫはまだ定義されていない将来の使用のために予約される。
【００５１】
ＥＡＰ拡張：
参考のため、出願人は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.を参照する。この参考文献は次のようにＥＡＰ再認証プロトコルのためのＥＡＰ拡張を説明している。拡張可能認証プロトコルは２つのグループを認証するメソッドの搬送のための総括フレームワークであり、認証は一方向又は相互のいずれかである。主要目的はネットワークアクセス制御であり、キー生成メソッドはアクセス制御を実施するために推奨される。ＥＡＰキーイング階層は２つのキーを定義する。これらのキーはトップレベルで、即ちマスタキーセッション（ＭＳＫ）及び拡張ＭＳＫ（ＥＭＳＫ）で得られる。最も一般的な展開シナリオにおいては、ピア及びサーバはオーセンティケータとして知られている第三者を介して互いに認証する。オーセンティケータ又はオーセンティケータによって管理されるエンティティはアクセス制御を実施する。認証の成功後には、サーバはＭＳＫをオーセンティケータに搬送し、オーセンティケータ及びピアはＭＳＫを認証キー又はキー誘導キーとして用いて一時セッションキー（ＴＳＫ）を取得し、単位パケットアクセス実施のためにＴＳＫを使用する。Ｉｄ。ピアがあるオーセンティケータから他のオーセンティケータに移動するときは、完全ＥＡＰ認証を避けることが望ましい。ＥＡＰメソッドの他の実行との完全ＥＡＰ交換は完了するために数回の往復及びかなりの時間を取り、ハンドオフ時間に遅延が生じる。幾つかのＥＡＰメソッドは計算オーバヘッドを減じることによって再認証を最適化するために初期認証からの状態の使用を特定するが、メソッド特定再認証は殆どのケースでは少なくとも２往復する。殆どのメソッドは再認証に対するサポートを提供しないことに留意することも重要でもある。故に、個々のメソッドにおけるよりもＥＡＰにおいて効果的な再認証サポートを受けるのがよい。
【００５２】
オーセンティケータにわたって共有するキーはハンドオフタイムを低減するため現実的な解決法として時々使用される。その場合、オーセンティケータの譲歩が他のオーセンティケータを介して確立されるＥＡＰセッションの譲歩となる。ｌｄ。要するに、再びＥＡＰメソッドを実行することを必要としないでピアとオーセンティケータ間にフレッシュキーを確立することを可能にする有効ＥＡＰ再認証機構を設計する必要がある。ｌｄ。この文献はＥＡＰを用いて有効再認証のためにＥＡＰ再認証拡張（ＥＲＸ）を特定している。ＥＲＸに基づくＥＡＰ再認証プロトコル（ＥＲＰ）はピアに対するＥＡＰメソッド非依存再認証をサポートする。このピアは以前に実行されたＥＡＰ認証からの有効な残りキーマテリアルを有する。プロトコル及びＥＡＰ再認証に必要なキー階層がこの文献に記載されている。ｌｄ。
【００５３】
ＥＡＰの拡張（ＥＡＰ−ＥＸＴ）：
本願はいずれも「ＥＡＰ拡張（ＥＡＰ−ＥＸＴ）のためのＥＡＰ方法」と名称付けられ、Y. Oba, et al.による２００７年１０月４日付提出の本譲渡人の先願米国非仮出願番号１１／８６７，６５９及びY. Oba, et al.による２００６年１２月８日付提出の米国仮出願番号６０／８６９，１１３に記載されているような発明を越える更なる進展を提供している。両出願の全開示は全てここに記載されているようにここに引用して援用される。背景参照として、本譲渡人の前記背景出願の技術に関する情報は次のパラグラフに含まれる。
【００５４】
１．ＥＡＰ−ＥＸＴの序論
上記検討に加えて、ＥＡＰ（拡張可能認証プロトコル）は“ＥＡＰメソッド”［ＲＦＣ３７４８］として知られている多くの認証アルゴリズムを支援する認証プロトコルである。ＥＡＰでは、ＥＡＰピア及びＥＡＰサーバはＥＡＰキーイングマテリアル、即ち、ＭＳＫ（マスタセッションキー）及びＥＭＳＫ（拡張マスタセッションキー）を生成する。ＭＳＫの生成、搬送及び使用の詳しいフレームワークは［I-D.ietf-eap-keying］に記載されている。
【００５５】
ＥＭＳＫ用法の１つが再認証である場合にＥＭＳＫ（拡張マスタセッションキー）の幾つかの用法を定義することによってＥＡＰ ［ＲＦＣ３７４８］の拡張機能がある。ＥＡＰの他の拡張機能は［I-D.ohba-eap-channel-binding］に定義されているチャネル結合方式（channel binding scheme）である。チャネル結合に関する追加の背景文献として、２００６年４月２０日にＹ．Ｏｈｂａによって出願された、CHANNEL BINDING MECHANISM BASED PARAMETER BINDING IN KEY DERIVATIONと名称付けられた同時継続出願番号１１／３７９，５６８の全開示が全体として参照することによって本明細書に援用される。ＥＡＰの拡張機能をサポートする実施は拡張機能をサポートしない実施と相互運用する必要があり、故に、前者の実施は後者の実施と通信するとき拡張機能を無効にするので、ＥＡＰピアに対する機構が必要となり、ＥＡＰの拡張機能に関してケイパビリティを取り決めるＥＡＰサーバが必要となる。
【００５６】
ＥＡＰ機能を拡張するために２つの基本的な方法がある。１つの方法は既存の方法、即ち、リクエスト、レスポンス、成功及び失敗に加えて拡張ＥＡＰ機能を実現するために新たなＥＡＰコードを定義することである。しかしながら、この方法はＲＦＣ３７４８への変更を必要とし、下位層プロトコルへの変更も必要とするかもしれない。他の方法は拡張機能を実現するために新たなＥＡＰメソッドを定義することである。この文献は既存のＥＡＰ展開への攻撃を最小にする後者の方法と取る。
【００５７】
ＥＡＰ−ＥＸＴはＥＡＰ機能を拡張するＥＡＰメソッドを説明している。幾つかの好適実施形態では、拡張ＥＡＰ機能はチャネル結合及び再認証を含む。また、ＥＡＰ−ＥＸＴメソッドはその内部の多くのＥＡＰメソッドの順序づけを可能にする。
【００５８】
２．ＥＡＰ−ＥＸＴ概要
好適実施形態では、ＥＡＰ−ＥＸＴはケイパビリティ交換を提供する。これに関して、メッセージ内のビットはケイパビリティの表示に使用できる。幾つかの実施形態では、１ビット（Ｒ−ビット）は再認証ケイパビリティに使用される。幾つかの実施形態では、１ビット（Ｃ−ビット）はチャネル結合ケイパビリティを示すために使用される。
【００５９】
ＥＡＰ−ＥＸＴが使用されると、サーバは第１のＥＡＰリクエストを送る前にサーバにピアの識別が知られれば先のＥＡＰ−識別交換が省略できる。この点について、ピアの識別をサーバに提供する、例えば、オーセンティケータとサーバとの間でピアの識別を転送する幾つかのアウトバンド（outband）機構がある。
【００６０】
ＥＡＰ−ＥＸＴにおいて、チャネル結合及び再認証のような拡張ＥＡＰケイパビリティはピア及びサーバ間で交換される。同時に、少なくとも１つのＥＡＰメソッド（例えば、ＥＡＰ−ＴＬＳ）はピアを認証するためのＥＡＰ−ＥＸＴ内で実行される。内部メソッドがＥＡＰキーイングマテリアルを生成するまで、ＡＵＴＨ ＴＬＶ（Type-Length-Value）は含まれず、ケイパビリティは保護されない。故に、１つの内部ＥＡＰメソッドだけがあれば、ＡＵＴＨ ＴＬＶを有するがメソッドＴＬＶを有さない追加のＥＡＰ−ＥＸＴがＥＡＰ成功又はＥＡＰ失敗メッセージを送る前に実行される。ＴＬＶｓ（Type-Length-Value）に関する背景参照として、データ通信プロトコルにおいて情報はType-Length-Value又はプロトコルの内部のＴＬＶ要素として符号化できることを留意する。一例として、タイプ及び長さフィールドはサイズが（例えば、数バイトに）固定され、値フィールドは一般的には可変サイズである。これらのフィールドは一般的には次のように使用される、即ち、タイプはメッセージのこの部分が表すフィールドの種類を示す数値コード、長さ、即ち値フィールドのサイズ（一般的にはバイトで）、及び値、即ちメッセージのこの部分に対するデータを含む可変サイズのバイトセットを用いた。ＴＬＶ表現を用いる利点の幾つかはＴＬＶシーケンスが発生した構文解析関数を用いて容易に探索されること、古いノードで受信される新しいメッセージ要素が支障なく省略でき、メッセージの残りが構文解析できること、そしてＴＬＶ要素が一般的に早く構文解析を行い、データを小さくする二進形式で使用されることを含む。
【００６１】
内部ＥＡＰメソッドはＥＡＰキーイングマテリアルを生成した後、ＥＡＰ−ＥＸＴメッセージはＡＵＴＨ ＴＬＶによってサポートする必要がある。ＥＡＰ−ＥＸＴメッセージの中のＡＵＴＨ ＴＬＶｓは最後に成功した内部メソッドのＥＡＰキーイングマテリアルから生成されるＥＡＰ−ＥＸＴ−ＫＥＹを用いて計算する必要がある。これはＥＡＰ−ＥＸＴ内部で順次実行される複数の内部ＥＡＰメソッドがあれば、新たなＥＡＰ−ＥＸＴ−ＫＥＹがシーケンスの内部ＥＡＰメソッドがＥＡＰキーイングマテリアルを生成する毎に生成されることを意味する。任意の内部ＥＡＰメソッドはＥＡＰキーイングマテリアルを生成できる用になる必要がある。
【００６２】
成功したＥＡＰ−ＥＸＴ実行の最後に、最後に成功した内部ＥＡＰメソッドによって生成されるＥＡＰキーイングマテリアルはＥＡＰ層に転送される。Ｆ−ビットはＥＸＰ−ＥＸＴ交換の終了を示すために使用される。
【００６３】
図１は単一の内部ＥＡＰメソッドを持つＥＡＰ−ＥＸＴメッセージシーケンスの例を示す。図２は複数の内部ＥＡＰメソッドを有するＥＡＰ−ＥＸＴメッセージシーケンスの例を示す。
【００６４】
３．エラー処理
エラーは複数の理由、例えば、内部ＥＡＰメソッド認証の失敗又は異常、未知、紛失ＥＡＰ−ＥＸＴ ＴＬＶにより生じるかもしれない。エラーはピア又はサーバのいずれかによって検出できる。エラーを起こしたＥＡＰ−ＥＸＴメッセージは誤りメッセージと見なされる。Ｅ−ビットセットを持つＥＡＰ−ＥＸＴメッセージはエラー表示のために使用される。これらのメッセージはエラー表示と見なされる。エラー表示はＡＵＴＨ ＴＬＶを含める必要があり、他のＴＬＶｓを含めるべきでない。
【００６５】
有効ＡＵＴＨ ＴＬＶを持たない（間違ったエラー表示を含む）どんな間違いメッセージも無許可で破棄する必要がある。
【００６６】
有効ＡＵＴＨ ＴＬＶを持つ間違いリクエストに対して、ピアはエラー表示レスポンスを送る。有効ＡＵＴＨ ＴＬＶを伴わない間違いレスポンスに対して、サーバはエラー表示リクエストを送り、このリクエストはエラー表示レスポンスでピアによって応答される。サーバは有効ＡＵＴＨ ＴＬＶを伴うエラー表示レスポンスに応答してＥＡＰ失敗メッセージを送り返す。
【００６７】
４．完全性保護キー
ＥＡＰ−ＥＸＴは２種類のキー、即ち、１）ＥＡＰ−ＥＸＴ−ＫＥＹ及び２）ＥＡＰ−ＲＥＡＵＴＨ−ＫＥＹを定義する。
【００６８】
４．１．ＥＡＰ−ＥＸＴ−ＫＥＹは完全性保護ＥＡＰ−ＥＸＴメッセージのためにＡＵＴＨ ＴＬＶｓの計算に使用される。ＨＭＡＣ−ＳＨＡ−２５６（上記文献に含まれる参考［ｓｈａ２５６］を参照）は完全性アルゴリズムに使用されると、ＥＡＰ−ＥＸＴ−ＫＥＹのレングスは３２オクテットである。ＥＡＰ−ＥＸＴ−ＫＥＹは次のように定義されるＵＳＲＫ（Usage Specific Root Key）誘導アルゴリズムを用いて内部ＥＡＰメソッドによって生成されるＥＭＳＫから得られる（例えば、上記に参照することによって援用される参考［I-D.salowey-eap-emsk-deriv］を参照）。
【００６９】
ＥＡＰ−ＥＸＴ−ＫＥＹ＝ＫＤＦ（EMSK, [Epsilon]AP-EXT-Integrity-Key”, length）．
ＫＤＦでは、ＥＡＰ−ＥＸＴ−ＫＥＹは上記に参照することによって援用される参考文献［I-D.salowey-eap-emsk-deriv］に特定されているデフォルトＰＲＦを用いる。
【００７０】
背景参考として、ＵＳＲＫキー誘導関数（ＫＤＦ）は拡張マスタセッションキー（ＥＭＳＫ）、キーラベル、オプションデータ及び出力レングスからＵＳＲＫを求める。ＫＤＦは同じ入力に対して同じ出力を与えるはずである。基本キー誘導関数はＵＳＲＫ ＝ ＫＤＦ（ＥＭＳＫ、キーラベル、オプションデータ、レングス）である。Ｉｄを参照。一般的には、キーラベルは各使用定義に独特のプリント可能なＡＳＣＩＩストリングであり、最大２５５バイトである。Ｉｄを参照。一般的には、それらはドメインがＵＳＲＫの使用定義の仕様を管理する組織（organization）であるところのフォームlabel-string@domainである。キーラベルは広域的特異性を持つ。これらラベルの割り当てのルールは［I-D.salowey-eap-emsk-deriv］のセクション７に示されている。
【００７１】
前記文献に説明されているように、ＥＭＳＫキー誘導関数は次の関数プロトタイプを持つ仮想ランダム関数に基づいている。
【００７２】
ＫＤＦ＝ＰＲＦ（key,data）。Ｉｄを参照。ＵＳＲＫｓをＥＭＳＫから得るために使用されるデフォルトＰＲＦはＨＭＡＣ−ＳＨＡ−２５６に基づいて［ＲＦＣ４３０６］に由来するＰＲＦ＋キー拡張ＰＲＦから引き出される。ｐｒｆ＋構成が［ＲＦＣ２２４６］に使用されるもののような他のＰＲＦｓを超えるその簡単さ及び効率のために選択された。［ＲＦＣ４３０６］によるＰＲＦ＋の定義は以下に示される。
【００７３】
ｐｒｆ＋（Ｋ，Ｓ）＝Ｔ１｜Ｔ２｜Ｔ３｜Ｔ４｜．．．
但し
Ｔ１＝ｐｒｆ（Ｋ，Ｓ｜０ｘ０１）
Ｔ２＝ｐｒｆ（Ｋ，Ｔ１｜Ｓ｜０ｘ０２）
Ｔ３＝ｐｒｆ（Ｋ，Ｔ２｜Ｓ｜０ｘ０３）
Ｔ４＝ｐｒｆ（Ｋ，Ｔ３｜Ｓ｜０ｘ０４）
キーマテリアルの必要レングスを計算するために必要に応じて継続する。
【００７４】
キーＫはＥＭＳＫであり、Ｓは［I-D.salowey-eap-emsk-deriv］のセクション１に定義されたデータである。Ｉｄを参照。図のように、ＰＲＦはＨＭＡＣ−ＳＨＡ−２５６と考えられる。Ｉｄを参照。
【００７５】
４．２．ＥＡＰ−ＲＥＡＵＴＨ−ＫＥＹ
ＥＡＰ−ＲＥＡＵＴＨ−ＫＥＹは再認証機構に使用されるＥＡＰメソッドによって要求される事前共有キーとして使用される。ＥＡＰ−ＲＥＡＵＴＨ−ＫＥＹのレングスは再認証機構に依存する。ＥＡＰ−ＲＥＡＵＴＨ−ＫＥＹは上記で援用される参考文献［I-D.salowey-eap-emsk-deriv］に次のように定義されるＵＳＲＫ誘導アルゴリズムを用いてＥＡＰ−ＥＸＴから転送されるＥＭＳＫから得られる。
【００７６】
ＥＡＰ−ＲＥＡＵＴＨ−ＫＥＹ＝ＫＤＦ（EMSK,“EAP-EXT-Reauthentication-Key”, length）
５．メッセージフォーマット
ＥＡＰ−ＥＸＴは（ＩＡＮＡによって割り当てられるべき）ＥＡＰ Ｔｙｐｅ Ｘを用いる。［ＲＦＣ３７４８］に定義された共通ＥＡＰフィールド（例えば、コード、識別子、長さ及び種類）を含むメッセージフォーマットは図３（Ａ）に示される。
【００７７】
Ｆ：
このビットはこれが送信者からの最後のＥＡＰ−ＥＸＴメッセージであることを示すように設定する必要がある。そうでなければ、このビットは設定する必要がない。
【００７８】
このビットはメッセージがエラー表示であるときに設定される。このビットが設定されると、Ｆビットも設定する必要がある。エラー表示に関する詳細な説明のセクション３を参照。
【００７９】
バージョン：
この８ビットフィールドはＥＡＰ−ＥＸＴメソッドのバージョンを示す。この文献はバージョン１を定義している。
【００８０】
予約（Reserved）：
この６ビットフィールドは将来の拡張のために予約される。このフィールドは送信者によってゼロに設定する必要があり、受信者はこのフィールドを無視する必要がある。
【００８１】
ケイパビリティ
ケイパビリティが扱うこのフィールドは拡張ＥＡＰケイパビリティを含む。ケイパビリティは図３（Ｂ）に示されるフォーマットを扱う。
【００８２】
各ビットは特定ケイパビリティに対応する。各ビットの意味は次の通りである。
【００８３】
Ｃ：
このビットは送信者がＭＳＫのための［I-D.ohba-eap-channel-binding］に定義されるチャネル結合機構をサポートすることを示すために設定される。このビットはリクエスト及びレスポンスの両方に対して設定され、ＥＡＰ−ＥＸＴメソッドが首尾よく完了すると、ピア及びサーバはチャネル結合機構を可能にする必要がある。ｐｒｆ＋用デフォルトハッシュアルゴリズム（default hash algorithm）はＡＵＴＨ＿ＨＭＡＣ＿ＳＨＡ１＿１６０である。
【００８４】
Ｒ：
このビットは送信者が再認証ＥＡＰメソッドをサポートすることを示すために設定される。このビットは最後のリクエスト／ＥＸＴメッセージに設定されると（即ち、Ｆビットを有するリクエスト／ＥＸＴが設定されると）、メッセージはサーバＩＤ ＴＬＶ及びピアＩＤ ＴＬＶを含める必要があり、Reauth-Key-Lifetime ＡＶＰを含めることができる。このビットが最後のリクエスト／ＥＸＴ及びレスポンス／ＥＸＴメッセージ交換に設定されると、ピア及びサーバはＥＡＰ−ＲＥＡＵＴＨ−ＫＥＹを発生する必要がある。サーバＩＤ及びピアＩＤはサーバＩＤ及びピアＩＤ ＴＬＶｓに含められ、ＥＡＰ−ＲＥＡＵＴＨ−ＫＥＹは再認証ＥＡＰメソッドに使用される。デフォルト再認証機構はこの開示に基づく従来技術のそれらによって選択できる。
【００８５】
他のビットは将来の使用のために予約され、送信者によってゼロに設定する必要があり、受信者によって無視される必要がある。
【００８６】
ＴＬＶ（Type-Length-Value's）：
ゼロ，１以上のＴＬＶｓ。ＴＬＶフォーマットは図３（Ｃ）に示される。
【００８７】
タイプ：
このフィールドはこのＴＬＶのタイプを示す。
【００８８】
レングス：
このフィールドは種類及びＴＬＶのレングスフィールドを含めて、オクテットでこのＴＬＶのレングスを示す。
【００８９】
バリュー：
このフィールドはＴＬＶタイプに特定されるデータを含む。
【００９０】
６．ＥＡＰ−ＥＸＴ ＴＬＶｓ
次のＴＬＶｓが定義される。
【００９１】
６．１．メソッドＴＬＶ
メソッドＴＬＶ（タイプ１）はタイプフィールドから開始するＥＡＰメソッドペイロードを含む。
【００９２】
６．２．ＡＵＴＨ ＴＬＶ
ＡＵＴＨ ＴＬＶ（タイプ２）はＥＡＰ−ＥＸＴメッセージを保護するために使用される完全性データを含む。ＥＡＰ−ＥＸＴ−ＫＥＹはＡＵＴＨ ＴＬＶｓを計算するために使用される。
【００９３】
ＴＬＶバリューフィールドはこのフィールドを含む全体のＥＡＰメッセージわたって計算される。完全性データを計算する前に、このフィールドは全てゼロに初期化する必要がある。このフィールドのレングスは使用時に完全性アルゴリズムに依存する。完全性チェックが失敗すると、メッセージは無許可で破棄する必要がある。デフォルト完全性アルゴリズムはＨＭＡＣ−ＳＨＡ−２５６である（例えば、以下で援用されている文献［ｓｈａ２５６］を参照）。
【００９４】
６．３．ピアＩＤ ＴＬＶ
ピアＩＤ ＴＬＶ（タイプ３）は再認証に使用されるピアの識別を含む。
【００９５】
６．４．サーバＩＤ ＴＬＶ
サーバＩＤ ＴＬＶ（タイプ４）は再認証に使用されるサーバの識別を含む。
【００９６】
６．５．Ｒｅａｕｔｈ−Ｋｅｙ−Ｌｉｆｅｔｉｍｅ ＴＬＶ
Ｒｅａｕｔｈ−Ｋｅｙ−Ｌｉｆｅｔｉｍｅ ＴＬＶ（タイプ５）はＥＡＰ−ＲＥＡＵＴＨ−ＫＥＹの寿命を秒単位で含む。
【００９７】
７．安全性考察
内部ＥＡＰメソッドがＥＡＰキーイングマテリアルを送る前にケイパビリティ交換は保護されない。故に、ＥＡＰキーイングマテリアルの作成後の追加サポートメッセージ交換は能力情報がピア及びサーバによって検出されないで攻撃者によって変更されるのを避けるために義務付けられる。
【００９８】
ＥＡＰ−ＥＸＴはその中の多くのＥＡＰメソッドの順序付けを可能にする。複数の入れ子又は順序認証メソッド（multiple nested or sequential authentication methods）を暗号的に結合しないでそれらで構成される複合認証メソッドが介入者攻撃（man-in-the-middle attack）に対して無防備である。ＥＡＰ−ＥＸＴはシーケンスにおいて前に成功した内部メソッドによって生成されるキーを用いて外部ＥＡＰメソッド（即ち、ＥＡＰ−ＥＸＴ）と共に各内部ＥＡＰメソッドを保護し、最後に成功した内部ＥＡＰメソッドによって生成されるＥＡＰキーイングマテリアルを最終的に転送することによって必要な暗号化的結合を作ることができる。暗号化結合を達成するために、ＥＡＰ−ＥＸＴはＥＡＰキーイングマテリアルを生成できる内部ＥＡＰメソッドを必要とする。
【００９９】
ブートストラッピングケルベロス
１．序論
ケルベロス［ＲＦＣ４１２０］は共有秘密キー暗号化を用いてオープン（非保護）ネットワーク上の各種ネットワークアプリケーションの端点（end-points）の同一性を証明する手段を提供する第三者認証プロトコルである。ケルベロスに対する拡張は認証プロトコル［ＲＦＣ４５５６］のある段階中の公開キー暗号化の使用のために提供できる。
【０１００】
ＥＡＰ（拡張可能認証プロトコル）は“ＥＡＰメソッド”［ＲＦＣ３７４８］として知られている複数の認証アルゴリズムをサポートする認証プロトコルである。しかしながら、ＥＡＰの適用はネットワークアクセス認証のためである。ＥＡＰは各種ネットワークアプリケーションに対して認証を提供するためには予定されていない。
【０１０１】
参考として、以下の表はケルベロスとＥＡＰとの差の幾つかを強調している表である。
【表１】
【０１０２】
新たなシングルサインオン（single sign-on）の必要性があり、シングルサインオンでは、ビジテッド又はホームドメインにおけるネットワークアクセスのための初期認証がリンク層からアプリケーション層に及んで、ドメイン内で使用される複数の異なるプロトコルにセッションキーを与えることができる。
【０１０３】
特に、セッションキーをリンク層プロトコルに与えることによって、リンク層ハンドオーバ性能がオーセンティケータ内及びオーセンティケータ間ハンドオーバを含めてドメイン内でハンドオーバ毎にＥＡＰ信号経路を除去することによって最適化できる。このセクションはＥＡＰからケルベロスをブートする機構を説明しており、このセクションでは、ＥＡＰが初期ネットワークアクセス認証のために使用され、ケルベロスは複数の異なるプロトコルにセッションキーを付与するために使用される。このセクションでは、機構を実現するためにＥＡＰ−ＥＸＴ暗号化が使用される。
【０１０４】
２．ＥＡＰ−ＥＸＴの再検討
幾つかの好適実施形態によると、新たなキャパビリティはケルベロスの新たなキャパビリティを含めて、（上述した）ＥＡＰ−ＥＸＴ暗号化内で定義される。
【０１０５】
これらの実施形態はキャパビリティフィールドに新たなキャパビリティビット（Ｋ）を定義し、ＥＡＰ−ＥＸＴの新たなＴＬＶｓ（例えば、ＫＲＢ−ＢＯＯＴ ＴＬＶ及びＫＲＢ−ＭＳＧ ＴＬＶ）も定義する。好適実施形態では、新たなキャパビリティビット（Ｋ）及びこれらの新たなＴＬＶｓは次のように使用される。
【０１０６】
ＥＡＰ−ＥＸＴ交換においては、ピア及びサーバが機能性（ＢＫＥとしてここに参照されているような機能性）を使用することを望めばピア及びサーバはキャパビリティフィールドにＫビットを設定する。ピア及びサーバの両者はＡＵＴＨ ＴＬＶセットによってＫビットを設定すれば、そのとき、好適実施形態では、システムは以下の方法で追加のＥＡＰ−ＥＸＴ交換を使用する。
【０１０７】
最初にサーバはケルベロスブートストラッピングパラメータをピアに送る。好ましくは、ケルベロスブートストラッピングパラメータはケルベロスブート（ＫＲＢ−ＢＯＯＴ）ＴＬＶに含まれる。このとき、ピアはケルベロスＡＳ−ＲＥＱメッセージをケルベロスＫＤＣ（Key Distribution Center）に送る。このとき、信号伝達のこの部分がＥＡＰ−ＥＸＴ外で行われる場合、ＫＤＣはＡＳ−ＲＥＰをサーバに戻す。ＡＳ−ＲＥＰがＫＲＢ−ＭＳＧ ＴＬＶに含まれる場合、サーバはＡＳ−ＲＥＰをピアに送る。
【０１０８】
最後に、ピアは確認をサーバに送り、サーバはＥＡＰ成功又はＥＡＰ失敗メッセージをピアに送る。好適実施形態では、これら交換の全てはＡＵＴＨ ＴＬＶによって保護される必要がある。
【０１０９】
ケルベロスがＥＡＰからブートされた後にケルベロスが使用される方法は環境に基づいて当業者によって決定でき、それに関する詳細はここでの目的のためには必要としない。
【０１１０】
図１はＢＫＥを持つＥＡＰ−ＥＸＴメッセージの例を示している。
【０１１１】
３．新たなメッセージフォーマット
好適実施形態によると、上記で示すように、ＥＡＰ−ＥＸＴのキャパビリティフラグの新たなビット、即ち新Ｋビットが定義される。
【０１１２】
図４を参照して、好適実施形態に従ったＥＡＰ−ＥＸＴメッセージフォーマットへの変更について説明する。
【０１１３】
ＫビットはＥＡＰ（ここではＢＫＥと称する）からケルベロスをブートするためのサポートを示す。好適実施形態では、ピア及びサーバの両者は一度ＡＵＴＨ ＴＬＶセットによってＫビットを設定すると、そのとき付加交換が上述したようにＥＡＰ−ＥＸＴ内で行われる。
【０１１４】
４．新キー
好適実施形態では、１つの新キーがここで説明された機能性を提供するために定義される。この新キーはＥＡＰ−ＫＲＢ−ＫＥＹと称される。ＥＡＰ−ＫＲＢ−ＫＥＹはケルベロスによって要求される事前共有キーとして使用される。好適実施形態では、ＥＲＰ−ＫＲＢ−ＫＥＹのレングス及び寿命はＥＡＰ−ＥＸＴ内でサーバからピアに伝えられる。例えば、ＥＲＰ−ＫＲＢ−ＫＥＹのレングスがＥＡＰ−ＥＸＴ内で取決められる。好適実施形態では、ＥＲＰ−ＫＲＢ−ＫＥＹキーは例えば、上記参照によって援用される文献［I-D.salowey-eap-emsk-deriv］に定義されたＵＳＲＫ誘導アルゴリズムを用いてＥＡＰ−ＥＸＴから転送されるＥＭＳＫから次のように得られる。
【０１１５】
ＥＡＰ−ＫＲＢ−ＫＥＹ＝ＫＤＦ（EMSK, “EAP-EXT-Kerberos-Bootstrapping-Key”, length）
ＫＤＦでは，ＥＡＰ−ＥＸＴ−ＫＲＢは［I-D.salowey-eap-emsk-deriv］に明記されたデフォルトＰＲＦを使用する。
【０１１６】
５．新ＥＡＰ−ＥＸＴ ＴＬＶｓ
好適実施形態によると、次の新ＴＬＶｓが定義される。
【０１１７】
５．１．ケルベロスブート（ＫＲＢ−ＢＯＯＴ）ＴＬＶ
好適実施形態では、ケルベロスブートストラッピングパラメータを含む新ケルベロスブートＴＬＶ（タイプ６）が確立される。好適実施形態では、次のケルベロスブートストラッピングパラメータが出現順に含まれる。
【０１１８】
ａ）ＥＡＰ−ＫＲＢ−ＫＥＹレングス（２オクテット）
好適実施形態では、このフィールドはＥＡＰ−ＫＲＢ−ＫＥＹのレングスをオクテットで示す。
【０１１９】
ｂ）ＥＡＰ−ＫＲＢ−ＫＥＹ寿命（２オクテット）
好適実施形態では、このフィールドはＥＡＰ−ＫＲＢ−ＫＥＹの寿命はＥＭＳＫの寿命を超える必要がある。
【０１２０】
ｃ）主要名（可変長）
好適実施形態では、このフィールドはＡＳＮ．１（Abstract Syntax Notation One）のＤＥＲ（Distinguished Encoding Rules）によって符号化される、ピアのケルベロス主要名を含む。ＡＳＮ．１の有名な符号化ルールがＸ．５０９によって基本符号化ルール（ＢＥＲ）符号化を行う制約から得られる国際基準である。抽象シンタックス概念１（Abstract Syntax Notation One ：ＡＳＮ．１）はコンピュータ間で送られているデータ構造がどのように符号化及び復号化されているかを制御する次のルールセット、即ち、基本符号化ルール（ＢＥＲ）；正規符号化ルール（ＣＥＲ）；有名符号化ルール（ＤＥＲ）；及びパック符号化ルール（ＰＥＲ）を定義する。オリジナルルールセットはＢＥＲ仕様によって定義された。ＣＥＲ及びＤＥＲはＢＥＲの特定サブセットとして最近開発された。ＰＥＲはＢＥＲ又はその改良型を用いてデータを送信するために必要な帯域幅量についての批判に応じて開発された。ＰＥＲは大きな省力をもたらす。ＤＥＲは安全なデータ転送のためＸ．５０９仕様の要求を満たすように作られた。例えば、証明登録（Certificate Enrollment）ＡＰＩはＤＥＲを単独に使用する。参考までに、INTERNATIONAL TELECOMMUNICATION UNION, Information Technology - ASN.1 Encoding Rules - Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER)及びDistinguished Encoding Rules (DER), ITU-T Recommendation X.690, July 2002を参照。これらの全開示は参照として援用される。
【０１２１】
ｄ）レルム（可変長）
好適実施形態では、このフィールドはＡＳＮ．１（Abstract Syntax Notation One)のDER (Distinguished Encoding Rules）によって符号化された、ピア及びＫＤＣのケルベロスレルムを含む。
【０１２２】
ｅ）ＩＰアドレスレングス（１オクテット）
好適実施形態では、このフィールドはＫＤＣのＩＰアドレスを含む。
【０１２３】
ｆ）ＫＤＣのＩＰアドレス（４又は１６オクテット）
好適実施形態では、このフィールドはＫＤＣの二進符号化ＩＰアドレスを含む。ＩＰアドレスレングスが４であれば、それは好ましくはＩＰｖ４アドレスを含む。ＩＰアドレスレングスが１６であれば、それは好ましくはＩＰｖ６アドレスを含む。
【０１２４】
５，２．ケルベロスメッセージ（ＫＲＢ−ＭＳＧ）ＴＬＶ
好適実施形態では、ケルベロスメッセージＴＬＶ（タイプ７）はＡＳ−ＲＥＱ及びＡＳ−ＲＥＰのようなケルベロスメッセージ（例えば、ＤＥＲ符号化メッセージ）を含む。
【０１２５】
６．０具体的メセージ交換シーケンス
図５乃至９はコンポーネント又はモジュール間の具体的通信を記載した、幾つかの具体的メッセージ交換シーケンスを示す。
【０１２６】
これに関して、図５乃至７はＢＫＥ機能を採用している幾つかの具体的実施形態に従ったメッセージシーケンスを示す。ここでは、図５はクライアント／ピア１０、サーバ３０及びキー配信センタ（ＫＤＣ）４０の間のメッセージシーケンスを示し、図６及び７はクライアント／ピア１０、サーバ３０、オーセンティケータ２０及びＫＤＣ（４０）の間のメッセージシーケンスを示す。
【０１２７】
これに関して、クライアント／ピア１０は、好適実施形態では、例えば、携帯電話、パーソナルコンピュータ、卓上コンピュータ、ウェラブルコンピュータ、ＰＤＡなどのようなモバイルノード又は装置に含めることができる。この際、クライアント／ピア１０は（図６及び７に緑で表された）ＥＡＰピアの機能性及び（図６及び７に赤で表された）ケルベロスクライアントを含むことができる。
【０１２８】
図５に示すように、クライアント／ピア１０、サーバ３０及びキー配信センタ（ＫＤＣ）４０の間のような通信がＢＫＥを採用する幾つかの実施例において次のようにできる。
【０１２９】
最初に、図５にａ）で示すように、サーバ３０はＥＡＰリクエスト／識別をピア１０に選択的に送信でき、ピアは、図５にｂ）で示すように、ＥＡＰリクエスト／識別をサーバ３０に選択的に送信できる。
【０１３０】
次に、図５のｃ）に示されるように、サーバ３０はＥＡＰリクエスト／ＥＸＴ｛Ｃａｐ．（Ｋ），メソッド｝メッセージをピア１０に送信する。ここで、Ｃａｐ．（Ｋ）はメッセージがキャパビリティフィールドセット有し、メソッドはメソッドＴＬＶに関することを示す。応答として、図５にｄ）で示されるように、ピア１０はＥＡＰレスポンス／ＥＸＴ｛Ｃａｐ．（Ｋ），メソッド｝メッセージをサーバ３０に送信できる。
【０１３１】
次に、図５にｅ）で示されるように、サーバ３０はＥＡＰ−リクエスト／ＥＸＴ｛Ｃａｐ．（Ｋ），ＡＵＴＨ｝メッセージをピア１０に送信する。ここで、Ｃａｐ．（Ｋ）はメッセージがキャパビリティフィールドセットのＫビットを有し、ＡＵＴＨがＡＵＴＨ ＴＬＶに関連することを示している。応答として、図５にｆ）で示すように、ピア１０はＥＡＰ−レスポンス／ＥＸＴ｛Ｃａｐ．（Ｋ），ＡＵＴＨ｝メッセージをサーバ３０に送信できる。
【０１３２】
次に、図５にｇ）で示すように、サーバ３０はＥＡＰ−リクエスト／ＥＸＴ｛Ｃａｐ．（Ｋ），ＫＲＢ−ＢＯＯＴ，ＡＵＴＨ｝メッセージをピア１０に送信する。ここで、Ｃａｐ．（Ｋ）はキャパビリティフィールドセットを有し、ＫＲＢ−ＢＯＯＴは（ケルベロスブートストラッピングパラメータを含む）ケルベロスブートＴＬＶに関連し、かつＡＵＴＨはＡＵＴＨ ＴＬＶに関連する。応答として、図５にｈ）で示されるように、ピア１０はＥＡＰ−レスポンス／ＥＸＴ｛Ｃａｐ．（Ｋ），ＫＲＢ−ＭＳＧ，ＡＵＴＨ｝メッセージをサーバ３０に送信できる。ここで、ＡＳ−ＲＥＱメッセージはケルベロスメッセージＴＬＶ（ＫＲＢ−ＭＳＧ）に含まれる。
【０１３３】
図５にｌ）で示されるように、サーバ３０もケルベロスブートストラッピングパラメータをＫＤＣに送信する。
【０１３４】
更に、図５にｍ）で示されるように、サーバ３０はこのときＡＳ−ＲＥＱメッセージをケルベロスＫＤＣ（キー配信センタ）に送る。それから、図５にｎ）で示されるように、信号伝達のこの部分がＥＡＰ−ＥＸＴ外で行われる場合、ＫＤＣはＡＳ−ＲＥＰメッセージをサーバに返す。
【０１３５】
次に、図５にｉ）で示されるように、ＡＳ−ＲＥＰがＫＲＢ−ＭＳＧ ＴＬＶに含まれる場合、サーバ３０はＡＳ−ＲＥＰをピア１０に送る。その際、サーバ３０は図示のようにｉ）でＥＡＰ−リクエスト／ＥＸＴ｛Ｃａｐ．（Ｋ），ＫＲＢ−ＭＳＧ，ＡＵＴＨ｝メッセージを送信する。
【０１３６】
最後に、ピアは確認をサーバに送り、サーバはＥＡＰサクセス（成功）又はＥＡＰフェイラ（失敗）メッセージをピアに送る。ここで、好ましくは、図５にｊ）で示されるように、ピア１０はＥＡＰ−レスポンス／ＥＸＴ｛Ｃａｐ．（Ｋ），ＡＵＴＨ｝メッセージをサーバ３０に送り、サーバ３０はＥＡＰサクセスメッセージをピア１０に送る。
【０１３７】
好適実施形態では、これら交換の全てはＡＵＴＨ ＴＬＶによって保護される必要がある。
【０１３８】
図６を参照して、この図は図５に示されるメッセージシーケンスと実質的に同じである。しかしながら、図６は更にオーセンティケータ２０に関してメッセージ交換を示している。これに関して、図６にｘ）で示されるように図５に示されるステップｊ）後に、サーバはＭＳＫをオーセンティケータ２０に送信し、それからｙ）にて、安全関連性（Secure Association）がピア／クライアントとオーセンティケータとの間に確立される。
【０１３９】
図７はＢＫＥ機能性を採用し、更にＴＧＳ−ＲＥＱ／ＲＥＰを含む幾つかの具体的実施形態に従った他のメッセージシーケンスである。背景参考のために、ケルベロスにおいて、クライアントはチケット付与サービス（ＴＧＳ）にアプリケーションサーバと通信するために必要なチケットを問い合わせる。ＴＧＳによって生成されたチケットは全てアプリケーションサーバキーによって暗号化された、クライアントの識別及びセッションキーを含む。ＴＧＳは全てクライアントキーで暗号化された、チケット及びセッションキーのコピーをクライアントに戻す。しかしながら、この交換はクライアントの識別のいかなる認証も単独で提供しない。クライアントの識別の認証はチケット検証に基づいてクライアントとアプリケーションサーバとの他の交換によって成される。ＴＧＳはチケットを発行することによってクライアントの識別に同意する。クライアント及びアプリケーションサーバはＴＧＳによって発行されたチケットを検証することによってクライアントの識別に同意する。クライアント識別に関する第三者の同意は、チケットがセッションキーとクライアントの識別との結合を持つ場合、クライアントとアプリケーションサーバとの間にセッションキーを保有する暗号証明に基づいて安全になされる。
【０１４０】
図７を参照して、ｘ１）で示されるように、ピア１０はフォーマットＥＡＰレスポンス／ＥＸＴ｛Ｆ，ＫＲＢ−ＭＳＧ（ＴＧＳ−ＲＥＱ），ＡＵＴＨ｝のサーバ３０にメッセージを送信し、ｘ２）で示すように、サーバ３０はＴＧＳ−ＲＥＱをＫＤＣに送信する。このとき、ＫＤＣは図７にｙ２）で示すようにＴＧＳ−ＲＥＰを返信する。次に、サーバ３０はメッセージをフォーマットＥＡＰリクエスト／ＥＸＴ｛Ｆ，ＫＲＢ−ＭＳＧ（ＴＧＳ−ＲＥＰ），ＡＵＴＨ｝のピア１０へ送信する。このとき、ピアは上記と同様にＥＡＰレスポンス／ＥＸＴ｛Ｆ，ＡＵＴＨ｝を送信する。
【０１４１】
参考のため、図８はアプリケーションクライアント（Ｃ），アプリケーションサーバ（Ｓ）、及びキー配信センタ（ＫＤＣ）を含む具体的なケルベロスメッセージシーケンスを示す。ＫＤＣはチケット発行サーバ（ＴＧＳ）及び認証サーバ（ＡＳ）を含む。この具体的実施例では、３つのメッセージ交換ステップが示される。即ち、ａ）シーケンスのステップＳ１はオーセンティケータを紹介し、ＴＧＴを取得する（この際、１００で示すように、ＡＳ＿ＲＥＱメッセージは認証サーバ（ＡＳ）に送信され、１１０で示すように、ＡＳ＿ＲＥＰメッセージが認証サーバから送信される）。ｂ）シーケンスのステップＳ２はＴＧＴを紹介し、チケットを取得する（この際、１２０で示されるように、ＴＧＳ＿ＲＥＱメッセージがチケット発行サーバ（ＴＧＳ）に送信され、１３０で示されるように、ＴＧＳ＿ＲＥＰメッセージがＴＧＳサーバから送信される）。
【０１４２】
参考のために、図９はピア、オーセンティケータ及びサーバを含む具体的ＥＡＰメッセージシーケンスを示す。図では、メッセージ２００はサーバからのＥＡＰリクエストを示し、メッセージ２０１はピアからのＥＡＰレスポンスを示し、メッセージ２０２はサーバからのＥＡＰサクセスメッセージを示し、メッセージ２０３はサーバからのＭＳＫメッセージを示し、２０４は確立された安全関連性（下位層）を示す。ここでは、オーセンティケータはピアへネットワークアクセスサービスを提供する。幾つかの実施形態では、オーセンティケータ及びサーバは同じ装置で実行できるが、幾つかの実施形態では、オーセンティケータ及びサーバは分離された装置で実行できる。分離された装置で実行されるとき、オーセンティケータはピアとサーバとのＥＡＰメッセージの「パススルー」転送者として機能する。
【先行技術文献】
【非特許文献】
【０１４３】
【非特許文献１】Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, March 1997 (Referred to herein as [RFC2119]).
【非特許文献２】Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, “Extensible Authentication Protocol (EAP),” RFC 3748, June 2004 (Referred to herein as [RFC3748]).
【非特許文献３】Aboba, B., “Extensible Authentication Protocol (EAP) Key Management Framework”, draft-ietf-eap-keying-16 (work in progress), January 2007 (Referred to herein as [I-D.ietf-eap-keying]); and [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 （ここでは［ｓｈａ２５６］と称する）．
【非特許文献８】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 （ここでは［ＲＦＣ４３０６］と称する）．
【非特許文献１０】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 （ここでは［ＲＦＣ４１２０］と称する）．
【非特許文献１３】Zhu, L. and B. Tung, “Public Key Cryptography for Initial Authentication in Kerberos (PKINIT)”, RFC 4556, June 2006 （ここでは［ＲＦＣ４５５６］と称する）． 各種方式及び方法は知られているが、改良された方式及び方法の必要性がある。
【発明の開示】
【０１４４】
本発明は、上述したシステム及び方法を含む、既存のシステム及び方法を改良する。
【０１４５】
幾つかの好適実施形態によると、サーバ、オーセンティケータ及びモバイルノードの間の安全なキー配信のためにケルベロスを使用するメディア独立ハンドオーバキー管理アーチテクチャが記載されている。このアーチテクチャを用いて、好適実施形態では、キー配信のための信号伝達は再キーイングに基づいており、初期ネットワークアクセス認証と同様なＥＡＰ（Extensible Authentication Protocol（拡張認証プロトコル））及びＡＡＡ（Authentication（認証），Authorization（許可）及びAccounting（課金））信号伝達を要求する再認証から切り離される。このフレームワークにおいて、モバイルノードはハンドオーバ前に一組のオーセンティケータと通信しないでそれらとのセキュリティ関連付けを動的に確立することを要求するマスタセッションキーを取得することを可能にする。再キー動作を再認証から分離することによって、提案アーチテクチャは事前動作モードに対してより最適化される。それはモバイルノードとターゲットアクセスノードとの間でキー配信を逆にすることによってリアクティブオペレーションモードに対して最適化もし得る。
【０１４６】
幾つかの好適実施形態によると、ハンドオーバ後にチケット配送を採用するリアクティブモードにおいてケルベロス化ハンドオーバキーイングを用いてサーバ、オーセンティケータ及びモバイルノード間の安全キー配信のためのメディア独立ハンドオーバキー管理のためのシステム及び／又は方法はａ）モバイルノードにＡＳ−ＲＥＱをキー配信センタに送信させ、モバイルノードにチケット付与チケット（ＴＧＴ）によってキー配信センタからＡＳ−ＲＥＰを受け取らせること、ｂ）ターゲットオーセンティケータに対するモバイルノードのハンドオーバ後に、ターゲットオーセンティケータにＴＧＳ−ＲＥＱをキー配信センタに送信させ、モバイルノードのためのチケット（Ｔ）を取得するためターゲットオーセンティケータにキー配信センタからＴＧＳ−ＲＥＰを受信させること、及び（ｃ）オーセンティケータにＡＰ−ＲＥＱをモバイルノードに送信させ、モバイルノードを認証するためにモバイルノードにＡＰ−ＲＥＰメッセージをオーセンティケータに送信させることを含む。幾つかの例では、本方法はチケット（Ｔ）を用いてモバイルノードとターゲットオーセンティケータとの間に安全関連性を確立することを含む。幾つかの例では、本方法はステップｂ）の前に、ターゲットオーセンティケータに対するモバイルノードのハンドオーバ後に、モバイルノードにトリガメッセージをターゲットオーセンティケータに送信させることを更に含む。幾つかの例では、本方法はターゲットオーセンティケータが許可のためのハンドオーバ後にＡＡＡ信号伝達無しにアクセス制御を行うようにチケット承諾データに承諾情報を埋め込ませることを更に含む。
【０１４７】
幾つかの他の実施形態によると、サーバ、オーセンティケータ及びモバイルノードの間の安全キー配信のためのメディア独立ハンドオーバキー管理アーチテクチャが設けられる。これはＥＡＰサーバと通信するように構成されるＥＡＰピアを持つモバイルノードを含む。モバイルノードは個別のケルベロスクライアントを有する少なくとも１つのターゲットネットワークに対する少なくとも１つのオーセンティケータと通信するように構成されるケルベロスサーバを更に有する。モバイルノードは少なくとも１つのオーセンティケータを介して少なくとも１つのターゲットネットワークにハンドオーバに関してセキュリティ信号伝達を行うように構成され、ＥＡＰ及びＡＡＡ信号伝達を用いて再認証しないで少なくとも１つのオーセンティケータを介してセキュリティ関連性を動的に確立するためケルベロスを用いてマスタセッションキーを取得するネットワークアクセス認証及びキー管理信号伝達を含む。
【０１４８】
幾つかの他の実施形態によると、サーバ、オーセンティケータ及びモバイルノードの間の安全キー配信のためのメディア独立ハンドオーバキー管理のためのシステム及び／又は方法はａ）ＥＡＰ方法を用いてネットワークアクセス認証証明からブートストラップを介して初期ネットワークアクセス認証中にモバイルノードにキー配信センタの識別及びアプリケーションサーバと共有するシークレットキーを取得させること、及びｂ）ハンドオーバ後にセキュリティを用いて１セットのオーセンティケータによってモバイルノードにセキュリティに関連性を持たせることを含む。幾つかの例では、本方法はモバイルノードにオーセンティケータの個別のケルベロスクライアントと通信するケルベロスサーバを含ませる。
【０１４９】
上記及び／又は発明、態様、種々の実施形態の特徴及び／又は利点は添付図面と関連して次の説明を鑑みて更に理解される。種々実施形態は適用可能である場合異なる態様、特徴及び／利点を含める及び／又は除外できる。更に、種々実施形態は適用可能な場合他の実施形態の１以上の態様又は特徴を組合すことができる。特定の実施形態の態様、特徴及び／又は利点の説明は他の実施形態又は請求の範囲を限定するように解釈されるべきでない。
【図面の簡単な説明】
【０１５０】
【図１】幾つかの実施形態に従った単一の内部方法によってＥＡＰサーバとＥＡＰピアとの間の具体的ＥＡＰ−ＥＸＴメッセージシーケンスを示す図である。
【図２】幾つかの実施形態に従った複数の内部方法によってＥＡＰサーバとＥＡＰピアとの間の具体的ＥＡＰ−ＥＸＴメッセージシーケンスを示す図である。
【図３】（Ａ）は、ＥＡＰ−ＥＸＰに関する幾つかの例示的実施例に従った具体的メッセージフォーマットを示す図である。（Ｂ）は、ＥＡＰ−ＥＸＰに関する幾つかの例示的実施例に従った具体的キャパビリティフィールドを示す図である。（Ｃ）は、ＥＡＰ−ＥＸＰに関する幾つかの例示的実施例に従った具体的ＴＬＶフォーマットを示す図である。
【図４】本発明の幾つかの例示的実施形態に従った具体的メッセージフォーマットを示す図である。
【図５】ＢＫＥ機能の幾つかの具体的実施形態に従ったメッセージシーケンスを示し、クライアント／ピア、サーバ及びＫＤＣ１の間のメッセージシーケンスを示す。
【図６】ＢＫＥ機能の幾つかの具体的実施形態に従ったメッセージシーケンスを示し、クライアント／ピア、サーバ、オーセンティケータ及びＫＤＣ１の間のメッセージシーケンスを示す。
【図７】ＢＫＥ機能を採用し、更にＴＧＳ−ＲＥＱ／ＲＥＰを含む幾つかの具体的実施形態に従った他のメッセージシーケンスである。
【図８】基準のためのケルベロスメッセージシーケンスを示す背景図である。
【図９】基準のためのＥＡＰメッセージシーケンスを示す背景図である。
【図１０Ａ】本発明の幾つかの実施形態に従ったケルベロス化ハンドオーバキーイングメッセージシーケンスを示す図である。
【図１０Ｂ】リアクティブオペレーションのために最適化されている、本発明の幾つかの実施形態に従ったケルベロス化ハンドオーバキーイングメッセージシーケンスを示す図である。
【図１１】ＥＡＰ機能及びパススルーオーセンティケーションを持つＥＡＰを示す図である。
【図１２】図８に示されるものと同様のケルベロスメッセージシーケンスを示す背景図である。
【図１３】リアクティブモードにおいて、図１０（Ａ）に示されるものと同様な、幾つかの実施形態に従ったケルベロスハンドオーバキーイングメッセージシーケンスを示す図である。
【図１４】リアクティブモードにおいて、図１０（Ｂ）に示されるものと同様な、幾つかの実施形態に従ったケルベロスハンドオーバキーイングメッセージシーケンスを示す図である。
【図１５】本発明の幾つかの事前モード及びリアクティブモード実施形態に従った承諾及び課金のためのＡＡＡ相互関係を示すアーチテクチャ図である。
【図１６】ＡＡＡドメインと複数のケルベロスレルムとの間の一例のそう関係を示す概略図である。
【図１７】幾つかの実施形態に従ったケルベロスブートストラップキャパビリティを持つＥＥＡＰ−ＥＸＴメッセージフォーマットを示す図である。
【図１８】幾つかの実施例に従ったケルベロスブートストラップシーケンスを示す図である。
【図１９】幾つかの実施形態に従った装置内で採用し得る幾つかの具体的アーチテクチャコンポーネントを示す図である。
【発明を実施するための形態】
【０１５１】
本発明は多くの異なる形態で実施してもよいが、本開示は本発明の原理の実施例を提供するとして考慮されるべきであり、そのような実施例は本発明をここに説明され及び／又はここに示された好適実施形態に限定されると意図していないとの理解の下に複数の具体的実施形態が説明されている。
【０１５２】
ケルベロス化ハンドオーバキーイング概要
ハンドオーバキーイングのためのケルベロス利用法
本発明の幾つかの好適実施形態によると、ハンドオーバキーイングのためにケルベロス使用法が採用される。その際、ケルベロスは、例えば、ケルベロスアップリケーションサーバを各ネットワーク接着点（point of attachment：ＰｏＡ）（例えば、アクセスポイント、基地局及び／又はアクセスルータ）に配置することによってハンドオーバキー管理に利用可能にすることができる。
【０１５３】
特に、この実施は次の及び／又は他の利点及び利益を達成できる。
【０１５４】
ａ）ＥＡＰ／ＡＡＡを用いた認証信号伝達はケルベロスレルム内でハンドオーバ毎に除外できる。
【０１５５】
ｂ）同じフレームワークは、例えばＦＭＩＰｖ６，ＨＭＩＰｖ６，ＨＭＩＰｖ［theta］，ＨＣＰ認証などに対して任意の層で使用される任意のプロトコルをブートするために適用できる。
【０１５６】
ケルベロス化ハンドオーバキーイングステップ
図１０を参照して、本発明の幾つかの具体的実施形態に従って、ケルベロスハンドオーバキーイングは次のステップを採用できる。
【０１５７】
図１０Ａに示される実施形態では、第１ステップ、ステップ１，は初期接着点（ＰｏＡ）を介して初期ネットワークアクセス認証の時にチケット付与チケット（ＴＧＴ）の取得を含む。この際、ＡＳ−ＲＥＱ／ＡＳ−ＲＥＰ交換はＲＦＣ ４１２０（i.e., Neuman, C., Yu, T., Hartman, S., and K. Raeburn, “The Kerberos Network Authentication Service (V5)”, RFC 4120, July 2005 ここに参照により援用される）に特定されているようにＴＣＰ又はＵＤＰを介して、若しくは（上述したようなＥＡＰからケルベロスをブートする）ＢＫＥを持つＥＡＰ−ＥＸＴを介して使用され及び搬送できる。図示のように、ＡＳ−ＲＥＱは（例えば、モバイル装置又はノード内の）アプリケーションクライアントＣからキー配信センタ（ＫＤＣ）に送信されることになる。
【０１５８】
図１０Ａに示される実施形態において、第２ステップ、ステップ２は候補ＰｏＡ毎にＰｏＡ当たりの事前チケット取得（proactive per-PoA ticket acquisition）を含む。この際、ＴＧＳ−ＲＥＱ／ＴＧＳ−ＲＥＰ交換がＲＦＣ ４１２０において特定されたようなＴＣＰ又はＵＤＰ若しくは上述したようなＥＡＰ−ＥＸＴにわたって使用され、転送される。そのような場合、クライアントＣはそれが引き継がれるかもしれないＰｏＡ毎にチケットを取得する。例えば、図９はクライアントＣが第１接着点ＰｏＡ１を発見し、それに関連するチケットＴ１を取得し、そしてクライアントＣが第２接着点ＰｏＡ２を発見し、それに関連するチケットＴ２を取得する具体的な事例を示している。図示のように、接着点毎に、ＴＧＳ−ＲＥＱはアプリケーションクライアントＣからキー配信センタ（ＫＤＣ）に送信されることになり、ＴＧＳ−ＲＥＰはキー配信センタ（ＫＤＣ）からアプリケーションクライアントＣに送信されることになる。
【０１５９】
図１０Ａに示される実施形態において、第３ステップ、ステップ３、は取得したチケットを用いて目標ＰｏＡ（ｓ）に対する安全関連性を確立することを含む。
【０１６０】
このステップ３では、ＫＲＢ−ＳＡＦＥ又はＫＲＢ−ＰＲＩＶ交換が選択的に後続するＡＰ−ＲＥＱ／ＡＰ−ＲＥＰ交換はＲＦＣ ４１２０において特定されているようにＴＣＰ又はＵＤＰにわたり、若しくはＩＰ接続性がなければリンク層にわたり使用及び配送できる。これらメッセージがリンク層にわたり配送される場合に、それらはａ）ケルベロス交換をサポートするための新たなＥＡＰ認証方法、又はｂ）ケルベロス交換をサポートするための新たなＥＡＰコードを規定することによってＥＡＰメッセージ内に取り込むことができる。そうでなければ、メディア特定情報がＫＲＢ−ＳＡＦＥ又はＫＲＢ−ＰＲＩＶ交換に取り込まれる。
【０１６１】
このステップ３において、安全関連性信号送信の幾らかの部分はハンドオーバ前に積極的に行うことができる。例えば、ＡＰ−ＲＥＱ／ＡＰ−ＲＥＰ交換は候補ＰｏＡｓにおいてセッションキーの記憶個所を作成するためにハンドオーバ前に行うことができる。
【０１６２】
ＰｏＡディスカバリ
上述のようにステップ２においてＰｏＡ当たりのチケットを取得するために、ＰｏＡｓはステップ２においてＰｏＡ当たりのチケットを得ることを見つける必要がある。その際、ＰｏＡディスカバリを実施するために、ＩＥＥＥ ８０２．２１情報サービスが採用できる。Draft Standard for Local and Metropolitan Area Networksと名称付けられた２００７年２月発行のＩ．Ｅ．Ｅ．Ｅ．Ｐ８０２．２１ＴＭ／Ｄ０４．００を参照する。この全体の開示は省略せずに個々に記載されているように参照によって援用される。
【０１６３】
キー寿命
チケットは寿命を有することは知られている。その際、この寿命は（サブ）セッションキー寿命を決定する。ここで、（サブ）セッションキーの寿命はチケット寿命より長くないことが必要である。
【０１６４】
許可
幾つかの実施形態によると、許可情報がチケットに含めることができる。その際、（ＴＧＴｓを含む）チケットの寿命はＡＡＡ許可寿命より長くない必要がある。ここで、オーセンティケータはチケットがそのような許可情報を含むならば許可信号送信のためにＡＡＡ信号伝達を必要としない。そうでなければ、許可のためのＡＡＡ信号伝達は行われるべきである。
【０１６５】
再キーイング
幾つかの好適実施形態によると、リンク層暗号キーの再キーイングはホームＡＡＡサーバに行き着くまでＥＡＰ再認証無しに行うことができる。例えば、これはステップ２において新たなチケットを再発行し、それから上述のようにステップ３を実行することによって達成できる。
【０１６６】
再認証
幾つかのケースでは、認証寿命を延ばす必要があればＥＡＰ再認証が必要となる。幾つかの好適実施形態では、これは新たなＴＧＴを再発行し、それからＰｏＡ当たりのチケットを再発行することによって達成できる。
【０１６７】
ＡＡＡドメイン間オペレーション（Inter-AAA Domain Operation）
ＡＡＡドメイン間オペレーションに関して、ケルベロスはクロスレルム動作を有利に可能にする。更に、１つはＡＡＡドメイン当たりのケルベロスレルム（又は複数のレルム）を形成できる。
【０１６８】
クロスレルム／ドメインオペレーションのために、クライアントはＴＧＴをビジテッドレルム／ドメイン（visited realm/domain）に使用されるそのローカルＡＳから得る必要がある。
【０１６９】
初期エントリ発行
幾つかの好適実施形態によると、初期ＰｏＡはＢＫＥのためのＥＡＰ オーセンティケータとして作用する。幾つかの実施形態では、初期ＰｏＡはＰＭＫを生成するためにＥＡＰ ＭＳＫを用いることができる。これは初期ＰｏＡがケルベロスをサポートしなければ使用されるべきである。幾つかの代替実施例では、初期ＰｏＡは成功したＥＡＰ認証後にステップ３を実行することによってＰＭＫを生成するためにケルベロスチケットを使用できる。この後者の例では、ステップ１だけでなくステップ２もＢＫＥ内で行われる必要がある。更に、成功したＥＡＰ認証自体はこの後者の例において安全関連性をトリガしない。これは初期ＰｏＡがケルベロスをサポートすれば使用されるべきである。
【０１７０】
リアクティブオペレーション（Reactive Operation）のために最適化されるケルベロス化ハンドオーバキーイング
幾つかの代替実施形態では、ケルベロス化ハンドオーバキーイングはリアクティブオペレーションのために最適化されるように変形できる。この際、幾つかの実施形態では、１０Ａを参照した上記のケルベロス化ハンドオーバキーイングステップが変形できる。例えば、幾つかの具体的実施形態では、図１０Ｂに示されるように、下記のステップが採用できる。
【０１７１】
第１ステップ１は初期接着点（ＰｏＡ）を介して初期ネットワークアクセス認証のときにチケット付与チケット（ＴＧＴ）取得を含めることができる。これは図１０Ａを参照した上記通常動作と同じ方法で行うことができる。
【０１７２】
第２ステップ２は目標ＰｏＡに対するＰｏＡ当たりのリアクティブチケット取得及びチケットを用いた目標ＰｏＡに対する安全関連性を含むことができる。この際、モバイルノード（ＭＮ）はトリガメッセージを目標ＰｏＡに送ることができ、又は目標ターゲットはリンク層指標を介してモバイルノードを見つけることができる。リアクティブオペレーション実施形態では、目標ＰｏＡはケルベロスクライアントとして作用し、モバイルノードのためにチケットを得るためＴＧＳ−ＲＥＱ／ＴＧＳ−ＲＥＰ交換を初期化する。目標ＰｏＡがモバイルノードのためのチケットを取得した後、それは（チケット導入のための）モバイルノードによってＡＰ−ＲＥＱ／ＡＰ−ＲＥＰ交換を初期化し、次いで（メデイア特定情報交換のための）ＫＲＢ−ＳＡＦＥ又はＫＲＢ−ＰＲＩＶ交換を初期化する、
幾つかの実施形態に関する追加の検討
このセクションはサーバ、オーセンティケータ及びモバイルノード間の安全キー配信のためケルベロスを使用するメディア独立ハンドオーバキー管理の具体的実施形態を更に説明する。このアーチテクチャに関して、キー配信のための信号伝達は再キーイングに基づいており、初期ネットワークアクセス認証と同様なＥＡＰ（拡張認証プロトコル）及びＡＡＡ（認証、許可及び課金）信号伝達を必要とする再認証から切り離される。このフレームワークでは、モバイルノードはハンドオーバ前に一組のオーセンティケータと通信しないでそれらとの安全関連性を動的に確立するために必要なマスタセッションキーを得ることができる。再認証から再キー動作を分離することによって、提案のアーチテクチャは事前動作モードに対してより最適化される。それはまたモバイルノードと目標アクセスノードとの間のキー配信役割を逆にすることによってリアクティブオペレーションモードのために最適化できる。このセクションはまたこの現アーチテクチャがどのように（例えば、ＩＥＥＥ ８０２．１１及び８０２．１６を含む）既存のリンク層技術に適用でき、複数のＡＡＡドメインにわたることを示している。このセクションはまたどのようにケルベロスがＥＡＰメソッドを用いて初期アクセス認証からブートできるかを説明している。
【０１７３】
１．序論
無線ネットワーク技術は多くの異なるリンク層技術にわたりシームレスオーバヘッドを可能にするために発展している。例えば、Ｉ．Ｅ．Ｅ．Ｅ．８０２．２１（下記文献１を参照）はリンク層と上位層プロトコルに対する統一的インターフェースによってメディア独立ハンドオーバ（ＭＩＨ）関数を定義している。この関数は幾つかのサービスをモビリティ管理エンティティに提供し、これらサービスを届けるためのプロトコルをリモートモードで他のＭＩＨ関数に提供することによってハンドオーバを容易にする。ハンドオーバ中の安全信号伝達最適化はシームレスハンドオーバを達成するための重要な要素の一つであるが、それは最近ではＩ．Ｅ．Ｅ．Ｅ．８０２．２１仕様の範囲外である。ハンドオーバ中の安全信号伝達はネットワークアクセス認証及びリンク層暗号化のための次のキー管理信号伝達を含む。ＩＥＴＦ（Internet Engineering Task Force）はＥＡＰ （Extensible Authentication Protocol）（下記文献［２］参照）を定義する。ＥＡＰはＵＤＰ／ＩＰ（例えば、下記文献［６］及び［７］参照）にわたってだけでなくイーサネット（登録商標）、Ｉ．Ｅ．Ｅ．Ｅ．８０２．１１及びＩ．Ｅ．Ｅ．Ｅ．８０２．１６（下記文献［３］［４］［５］参照）のような幾つかのリンク層技術にわたりさまざまな認証方法のサポートによってネットワークアクセス認証のための統一的機構を提供する。上述したように、ＥＡＰメソッドはピア（例えば、モバイルノード）とサーバ（例えば、バックエンド認証サーバ）との間で認証メソッドを実行する２グループ認証プロトコルであり、これに対して、ＥＡＰは図１１に示されるようにオーセンティケータ（例えば、Ｉ．Ｅ．Ｅ．Ｅ．８０２．１１の場合のアクセスポイント）を介してＥＡＰメソッドを搬送するためのコンテナ、即ちパススルーオーセンティケータを持つＥＡＰに過ぎない。
【０１７４】
ＥＡＰはネットワークアクセス認証のためのメディア独立機構を提供するが、その基本設計はピアが特定のＥＡＰメソッドを除いてハンドオーバにより１つのオーセンティケータから他のオーセンティケータに変更するときその信号伝達を最適化することを十分考慮していなかった。特定ＥＡＰメソッドはこの問題を扱うためにセッション回収を用いてエンハンスメントを与えることによってこの問題を扱う（例えば下記文献［８］参照）。しかしながら、そのようなエンハンスメントは他のＥＡＰメソッドが初期ネットワークアクセス認証に使用されるとき利用できない。
【０１７５】
最近、ハンドオーバ用ＥＡＰ最適化のための機構及びプロトコルを定義するためＩＥＴＦはＨＯＫＥＹ（ハンドオーバキーイング）ワーキンググループを着手した（例えば、下記文献［９］参照）。ＨＯＫＥＹワーキンググループは３つの要素、例えば低待ち時間再認証（又はＨＯＫＥＹ再認証）、ハンドオーバキー管理及び事前認証を定義している。ＨＯＫＥＹ再認証は前回のＥＡＰセッションによって生成されたキーイングマテリアルを利用してメッセージ往復を最小限にするためにＥＡＰに拡張を定義する。ハンドオーバキー管理はサーバからオーセンティケータへのキー配信機構だけでなく複数のオーセンティケータに及ぶ新たなキー階層を定義する。事前認証はピアがサービングアクセスネットワークから候補目標オーセンティケータに対するＥＡＰを実行する事前ハンドオーバ最適化技術である（例えば、下記文献［１０］参照）。
【０１７６】
しかしながら、ＨＯＫＥＹ要素に関する２つの問題がある。第１に、ＨＯＫＥＹ再認証はピアにサーバと通信することをなおも要求する。このサーバは家に在住する又はビジタオペレータネットワークに属し、ピアの場所から物理的に離れている可能性のあるＡＡＡサーバと通常同じ場所にいる。（注：ビジタオペレータネットワークのＡＡＡサーバはオペレータのサブスクライバのためのホームＡＡＡサーバとしても寄与する。）故に、ＨＯＫＥＹ再認証にがリアルタイムアプリケーションの性能に影響しない程度にハンドオーバ待ち時間を減少するのは困難である。第２に、ＨＯＫＥＹ事前認証はモバイルノードの動きの正確な予想を必要とする。しかしながら、隣接ネットワークに多くの候補オーセンティケータが存在するとき動き予測は困難である。
【０１７７】
上述したように、好適実施形態は、とりわけ、ＨＯＫＥＹに関する問題を扱うためにケルベロスを用いるハンドオーバキー管理のためのケルベロスハンドオーバキーイングと呼ばれる新たなアーチテクチャを確立する（例えば、下記文献［１１］参照）。
【０１７８】
好適実施形態では、ケルベロスハンドオーバキーイング（ＫＨＫ）は次の特徴を提供する。即ち、ａ）ＫＨＫはモバイルノードが積極的にｐｅｒ−オーセンティケータキーを取得している限り認証及び許可のためにポストハンドオーバＡＡＡ信号伝達を必要としなく、ｂ）ポストハンドオーバ信号伝達待ち時間は下位層安全関連プロトコルのケルベロスチケット導入及び実行のためピアとオーセンティケータとの若干のメッセージ交換に基づいてアクセスネットワーク内での伝搬遅延の程度まで減少されることが予想され、ｃ）ＫＨＫは各オーセンティケータがハンドオーバ前にモバイルノードのキーを記憶する必要がないので事前キーイングオペレーションのための必要なキーキャッシュのサイズを減少できる。
【０１７９】
ネットワークアクセス認証及びキー管理のためにケルベロスを使用する既存ワークＥＡＰ−ＧＳＳ（下記文献［１２］参照）がある。ワークは最初Ｉ．Ｅ．Ｅ．Ｅ．８０２．１１ｉの候補として考えられていた。しかしながら、ＫＨＫとは異なり、ワークはハンドオーバ最適化を考慮もしなく、任意のＥＡＰメソッドが初期ネットワークアクセス認証のために使用されるのを可能にしない。
【０１８０】
２．ケルベロスの追加的概略
上記の検討に加えて、ケルベロス（下記文献［１０］参照）は対称的キーに基づく３グループ認証及びキー管理プロトコルである。ケルベロスに３つの基本構成がある。即ち、クライアント、サーバ及びキー配信センタ（ＫＤＣ）がある。更に、ＫＤＣは２つの特別なサーバ、即ち、認証サーバ（ＡＳ）及びチケット許可サーバ（ＴＧＳ）を提供する。そのような事例では、各クライアント及びサーバは秘密キーに基づいてＫＤＣとの事前に確立された信頼関係を持つことが仮定とされる。ケルベロスにおいて、セッションを安全に確立するためクライアント及びサーバによって使用されるセッションキーはＫＤＣによって生成され、クライアントに配信される。それから、クライアントは「チケット」を用いてセッションをサーバに配信し、又はクライアントが自らの証明に役立てるためにＫＤＣによって生成される記録をサーバに配信する。チケットはクライアントの識別、セッションキー、タイムスタンプ及び他の情報を含み、（チケットバージョン番号、領域及びサーバ名を除く）全てのそのような情報がＫＤＣによってだけ共有されるサーバ秘密キーを用いて暗号化される。ケルベロスプロトコルは初期交換が一度だけ行われる場合に３つの交換を含む。ケルベロスシーケンスとして表記された図１２はケルベロスの代表的プロトコルシーケンスを示す。
【０１８１】
図１２に示すように、初期交換（ＡＳ−ＲＥＱ／ＡＳ−ＲＥＰ交換）において、クライアントはチケット付与チケット（ＴＧＴ）、又は他のチケットをＡＳから生成するために使用される特別のチケットを要求する。ＡＳはＴＳＧ用セッションキー（ＴＳＧセッションキー）を含むＴＧＴを生成し、クライアントとだけ共有される秘密キーによって暗号化されるＴＳＧセッションキーのコピーと共にＴＧＴをクライアントに送る。
【０１８２】
第２交換、ＴＧＳ−ＲＥＱ／ＴＧＳ−ＲＥＰ交換では、クライアントは同じＴＧＳセッションキーを保有することをＴＳＧが証明できるようにＴＧＳセッションキーを用いて作られる証明と共にクライアントはサーバ識別及びＴＧＴをＴＧＳに送る。証明の確認が成功した後、ＴＧＳはサーバ用セッションキーを含むチケットを生成し、そのチケット及びクライアントとだけ共有される秘密キーによって暗号化されるセッションキーのコピーをクライアントに送る。
【０１８３】
第３交換、ＡＰ−ＲＥＱ／ＡＰ−ＲＥＰ交換において、クライアントがセッションキーを保有することをサーバが証明できるようにクライアントはセッションキーを用いてクライアントによって計算されたメッセージ認証コードと共に、第２交換に含まれるチケットを送る。ＡＰ−ＲＥＰメッセージはクライアントがサーバを認証する必要がなければ省略できる。信用の確認が成功した後、クライアント及びサーバはこれらのアプリケーションプロトコルを保護するためにセッションキーを用いることができる。
【０１８４】
３．ケルベロス化ハンドオーバキーイング（ＫＨＫ）。
【０１８５】
好適実施形態によると、ケルベロスハンドオーバキーイング（ＫＨＫ）が採用される。ここでは、モバイルノード及びオーセンティケータ（例えば、アクセスポイント又は基地局）がクライアント又はケルベロスのサーバとして作用する。
【０１８６】
これに関して、クライアント及びサーバの役割はチケットがオーセンティケータに送付されるときのタイミングに応じて逆転される。幾つかの実施形態によると、オーセンティケータへのチケット送付がハンドオーバ前に発生する事前モードが採用される。他方、実施形態によると、オーセンティケータへのチケット送付がハンドオーバ後に起きるリアクティブモードが採用される。
【０１８７】
事前モードはモバイルノードがハンドオーバ後にＫＤＣと通信することを必要としないので事前モード実施形態はリアクティブモード実施形態よりも最適化される。そのような事例では、ハンドオーバ後の信号伝達待ち時間が、ある実施形態では、Ｉ．Ｅ．Ｅ．Ｅ．８０２．１１ｉ ４−方向ハンドシェイク（Ｉ．Ｅ．Ｅ．Ｅ．８０２．１１ｉ 4-way handshake）（下記文献［４］参照）のためのものに類似し、ある例では２０ｍｓｅｃ以下であるとして知られている（下記文献［１３］参照）。
【０１８８】
好適実施形態によって、ＫＨＫアーチテクチャは事前モードにおいてさえ、ハンドオーバ前にモバイルノードのために任意の状態を作ることをオーセンティケータに要求しない。好適実施形態では、最初に、モバイルノードはＫＤＣの識別及びセクション４において以下に記載されているようにブートストラッピング機構を用いて初期ネットワークアクセス認証中にＡＳと共有する秘密キーを取得する。初期化後に、上記のセクション２で説明されているケルベロスの３つのステップが実行される。３つのステップは事前及びリアクティブモードにおいて異なって実行される。これらの違いの詳細は３．１及び３．２に説明されている。
【０１８９】
３．１事前モード
このセクションでは、事前モードはＫＨＫ事前モードと表記された図１３を参照して説明する。最初に、モバイルノード（ＭＮ）はＴＧＴを取得するためにＫＤＣでＡＳ−ＲＥＱ／ＡＳ−ＲＥＰ交換を実行する。ＭＮがセクション３．４で説明されているようにオーセンティケータ発見機構を用いて１以上のオーセンティケータ（例えば、事象Ｄ１，Ｄ２）を見つけると、それは発見されたオーセンティケータ（例えば、Ａ１及びＡ２）ごとにチケットを得るためにＫＤＣによってＴＧＳ−ＲＥＱ／ＴＧＳ−ＲＥＰ交換を実行する。ＭＮが発見したオーセンティケータの１つ（例えば、事象Ｈ１）に対してハンドオーバを作成すると、それはオーセンティケータでＡＰ−ＲＥＱ／ＡＰ−ＲＥＰ交換を実行する（ＡＰ−ＲＥＰメッセージは選択的である）。ＭＮが異なるオーセンティケータ（例えば、事象Ｈ２）に対して他のハンドオーバを作成すると、それはオーセンティケータによってＡＰ−ＲＥＱ／ＡＰ−ＲＥＰ交換を実行する。この場合、モバイルノード及び目標オーセンティケータはクライアント及びケルベロスのサーバとしてそれぞれ作用する。
【０１９０】
ＡＰ−ＲＥＱ／ＡＰ−ＲＥＰ交換の後に、１以上の追加ＫＲＢ−ＳＡＦＥメッセージ又はリンク層特定ＳＡＰ（Secure Association Protocol（安全関連性プロトコル））メッセージがモバイルノードとオーセンティケータとのリンク層安全関連性を確立するためにモバイルノードと目標オーセンティケータとの間で交換される。これらメッセージはリンク層暗号組パラメータのようなリンク層特定パラメータを有する。ＫＲＢ−ＳＡＦＥメッセージの使用によってアーチテクチャはリンク層技術から独立できる。そして、各リンク層技術はＫＲＢ−ＳＡＦＥに保有されるべきリンク層特定パラメータのフォーマット及びセマンティックスだけでなくモバイルノードとオーセンティケータとの間にケルベロストランスポートを定義することを必要とするに過ぎない。ＩＥＥＥ ８０２．１１の事例では、リンク層認証フレームがモバイルノードとオーセンティケータとの間のケルベロストランスポートとして使用でき、８０２．１１ｉ ４−方向ハンドシェイクはＫＲＢ−ＳＡＦＥメッセージの代わりにＳＡＰとして使用できる。同様に、ＩＥＥＥ ８０２．１６の事例では、新たなＰＫＭ（Privacy Key Management）メッセージタイプが移動局と基地局との間にケルベロスメッセージを搬送するよう定義でき、ＰＫＭ ３−方向ハンドシェイクがＫＲＢ−ＳＡＦＥメッセージの代わりにＳＡＰとして使用できる。これらの両事例では、リンク層仕様に変更を加える必要がある。
【０１９１】
３．２リアクティブモード
このセクションでは、リアクティブモードがＫＨＫリアクティブモードとして表記された図１４を参照して説明する。
【０１９２】
まず、モバイルノード（ＭＮ）は事前モードと同じ方法で、ＴＧＴを得るためＫＤＣによってＡＳ−ＲＥＱ／ＡＳ−ＲＥＰ交換を実行する。
【０１９３】
しかしながら、リアクティブモードでは、モバイルノード及び目標オーセンティケータのケルベロスの役割が逆転する、即ち、モバイルノードと目標オーセンティケータはサーバとクライアントとしてそれぞれ作用する。好ましくは、目標オーセンティケータに対するハンドオーバの後に、モバイルノードは最初にトリガメッセージを目標オーセンティケータに送る。それから、目標オーセンティケータはモバイルノード用チケットを取得するためにＫＤＣによってＴＧＳ−ＲＥＱ／ＴＧＳ−ＲＥＰ交換を実行し、その後、モバイルノードによってＡＰ−ＲＥＱ／ＡＰ−ＲＥＰ交換を実行する（ＡＰ−ＲＥＰメッセージはＫＲＢ安全又はＳＡＰ交換前にモバイルノード（ＭＮ）を認証するために必須である）。
【０１９４】
ＡＰ−ＲＥＱ／ＡＰ−ＲＥＰ交換後に、１以上の追加ＫＲＢ−ＳＡＦＥメッセージ又はリンク層特定ＳＡＰ（Secure Association Protocol）メッセージがモバイルノードとオーセンティケータとの間にリンク層安全関連性を確立するためにモバイルノードと目標オーセンティケータとの間で交換される。この交換は事前モードと同様の方法で行うことができる。
【０１９５】
トリガメッセージが保護されていなければ、資源消費ＤｏＳ（Denial of Service）攻撃がリアクティブモードに対して可能性がある。従って、追加機構がそのようなＤｏＳ攻撃を緩和するために採用できる。
【０１９６】
リアクティブモードのためのハンドオーバ後の信号伝達待ち時間は実質的に事前モードの待ち時間＋オーセンティケータとＫＤＣ間の１往復になることが予想される。故に、リアクティブモードのためのリアルタイムアップリケーションに対するハンドオーバ性能はＫＤＣの位置に依存する。以下のセクション３．６に説明されるように、ＫＤＣはクロスレルムオペレーションを用いてオーセンティケータに近い位置に配置できる。しかしながら、ハンドオーバ性能はＫＤＣの位置に依存しないので事前モードを使用することがリアクティブモードにわたり多くの環境においてより望ましい。
【０１９７】
３．３キー寿命
ケルベロスチケットはキー寿命を含むので、異機種リンク層技術（heterogeneous link-layer technologies）に対するキー管理に柔軟性を得るために、（限定されないが）リンク層タイプに依存する異なるオーセンティケータに対して異なるキー寿命（又はキー寿命が認証時間と同じであれば異なる許可寿命（authorization lifetimes））を割り当てることが可能である。
【０１９８】
３．４ オーセンティケータディスカバリ
ＫＨＫの事前モードにおいて、モバイルノードは隣接ネットワークにおいてオーセンティケータを見つける必要がある。オーセンティケータディスカバリ機構は少なくとも次の情報を得るために必要である。
【０１９９】
・ＫＤＣからオーセンティケータのためのチケットを得るときにモバイルノードが認識できるようにオーセンティケータの識別の発見。単一のオーセンティケータ識別は複数のネットワーク接着点（例えば、アクセス点、基地局及び／又はアクセスルータ）に対して使用できることを留意する。
【０２００】
・モバイルノードがＡＰ−ＲＥＱ／ＡＰ−ＲＥＰ交換に対してオーセンティケータと通信できるようにオーセンティケータのアドレスの発見。アドレスはリンク層アドレス又はＩＰアドレスでできる。単一オーセンティケータ識別は複数のネットワーク接着点のために使用されるとき、オーセンティケータ識別は複数のアドレスと関連する。
【０２０１】
ＩＥＥＥ ８０２．１１ｒ（例えば、下記文献［１４］参照）において、ビーコンフレーム（Beacon frame）において通知されたＲ０ＫＨ−ＩＤ及びＢＳＳＩＤはオーセンティケータの識別及びアドレスにそれぞれ対応するが、それはＩＥＥＥ ８０２．１１リンク層だけに適用できる。他方、メディア独立オーセンティケータディスカバリ機構（media-independent authenticator discovery mechanism）は、例えば、上述した全ての情報を提供するために望ましい。例えば、ＩＥＥＥ ８０２．２１、情報サービス（例えば、下記文献［１］参照）を参照する。ＩＥＥＥ ８０２．２１情報サービスはハンドオーバ意思決定プロセス（handover decision-making process）を容易にするために隣接ネットワークに関する種々の情報を提供し、任意のメディアを徹底的に調査するために設計されるのでＩＥＥＥ ８０２．２１情報サービスはそのような機構を提供できる。
【０２０２】
３．５ 許可及び課金
ケルベロスは許可情報がＫＤＣ発行許可データ要素によってカプセル化されるときチケットの許可データに埋め込むことを可能にする。ＫＤＣによって発行される許可証明がアクセス制御を行うためオーセンティケータによって必要とされる全許可情報を含むならば、認証のためだけでなく許可のためにもハンドオーバ後にＡＡＡ信号伝達を廃止することを可能になる。
【０２０３】
ケルベロス化ハンドオーバキーイングに使用される好適な許可モデルは次のように説明される。
【０２０４】
・ＫＤＣを実施するノードは許可目的のためにＡＡＡサーバと通信するためＡＡＡクライアントも実施する。
【０２０５】
・ＫＤＣがケルベロスクライアント（即ち、事前モードのモバイルノード又はリアクティブモードのオーセンティケータ）からＴＧＳ−ＲＥＱメッセージを受信すると、それはケルベロスクライアントに対する許可情報をＡＡＡクライアントに要請する。ＡＡＡクライアントはＡＡＡプロトコルを用いてＡＡＡサーバから許可情報を取得し、取得した情報をＫＤＣに戻す。
【０２０６】
・ＫＤＣはＴＧＳ−ＲＥＰメッセージに含まれるべきチケットの許可データフィールドに許可情報を埋め込む。
【０２０７】
好適実施形態では、許可モデルは次の２つの要求を有する。第１に、許可証明のフォーマット及びセマンティクスは相互接続のために標準化される。第２に、リアクティブモードの事例では、許可情報はリアクティブモードでのケルベロスクライアント（例えば、オーセンティケータ）がモバイルノードに使用されるべき許可情報を取得できるようにＴＧＳ−ＲＥＰメッセージの暗号化データ部分に取り込まれる。
【０２０８】
課金は既存のリンク層技術において行われるようにオーセンティケータに行われ、例えば、オーセンティケータを実施し、課金のためのＡＡＡクライアントをも実施するノードで行われる。課金記録を妥当な許可セッションと関連するため、好ましくは許可セッション識別子は許可証明に含まれる。幾つかの実施形態に従った許可及び課金のためのＡＡＡ相互作用が図１５に示されている。許可及び課金に関して事前モードとリアクティブモード間の注目すべき差はＫＤＣが事前モードでモバイルノードを介してオーセンティケータに許可情報を好ましくは間接的に通過させ、これに対してＫＤＣがリアクティブモードにおいてオーセンティケータに許可情報を好ましくは直接的に通過させることである。
【０２０９】
オーセンティケータノードのＡＡＡクライアントも初期ネットワークアクセスのための認証機能性を持っている。
【０２１０】
３．６ ＡＡＡドメインへのケルベロスレルムのマッピング
上述のように、ケルベロスは組織的境界にわたり動作するように設計されている。例えば、１組織のクライアントは他の組織のサーバに認証され得る。この際、ケルベロスサーバを実施する各組織の願望は自らの「レルム」を確立する。クライアントは登録されているレルム名はローカルレルムと呼ばれる。
【０２１１】
「インタレルム」キーを確立することによって、２つのレルムのアドミニストレイタはローカルレルムで認証されたクライアントが他のレルムのサーバに対してその識別を立証することを可能にする。この際、レルム間キーの交換が各レルムのチケット許可サービスを他のレルムの主体として登録する。それから、クライアントはリモートレルムチケット許可サービスのためのＴＧＴをそのクライアントローカルレルムから取得できる。そのＴＧＴが使用されると、リモートチケット許可サービスはＴＧＴを解読するため（自己の標準ＴＧＳキーとは通常異なる）レルム間キーを使用する。好ましくは、リモートチケット許可サービスによって発行されるキーはクライアントが他の領域から認証されたことをエンドサービスに示すことになる。
【０２１２】
一般的に、ケルベロルレルム及びＡＡＡドメインは独立している。しかしながら、単純化した具体例の代わりに、我々は典型的な実施面で妥当なモデルを導入する。ここで、我々はケルベロス化ハンドオーバキーイングがＤＮＳドメイン名をケルベロスレルム名及びＡＡＡドメイン名として使用するものとする。
【０２１３】
Ｄ（ｎ）はＤＮＳメイン名がｎであるＡＡＡドメインを示すものとする。Ｒｎはレルム名がそれらの添え字ｎを含むケルベロスレルムのセットであるとする。ＫＨＫにおけるＡＡＡドメインとケルベロスレルムとの関係は次のように表される。
【０２１４】
Ｄ（ｎ）＝Ｒｎ
この式はＡＡＡドメインがケルベロスレルムのセットを有すること及び特定のケルベロスレルムがケルベロスレルム名及びＡＡＡドメイン名を用いて特定のＡＡＡドメインに属するか否かをモバイルノードが伝えることができることを表している。具体的ＡＡＡドメインと複数の具体的ケルベロスレルムとの間のマッピングを示す具体的実施例がＡＡＡドメインとケルベロスレルムとの例示的関係を表記した図１６に示されている。モバイルノードにできるだけ物理的に近づくような位置にＫＤＣを配置することによって信号伝達待ち時間を減じるだけでなくＫＨＫが拡張可能であるために単一ＡＡＡドメイン内に複数のレルムを定義することが望ましい。
【０２１５】
好適実施形態では、ＡＡＡドメインにわたってシームレスハンドオーバをサポートするために、互いにローミング関係にある２つのＡＡＡドメイン間にケルベロスレルム間キーが予め確立されることが望ましい。モバイルノードがＡＡＡドメインを横切ってサービングオーセンティケータから目標オーセンティケータに移動すると、それはホームＡＡＡドメインのローカルＫＤＣに接触することによってビジテッドＡＡＡドメインのリモートＫＤＣに有効なクロスレルムＴＧＴを取得する。好ましくは、ローカルとリモートレルム間に１以上の中間領域があれば、モバイルノードが認証路に沿ってＴＧＴ取得手順を繰り返す。ローカルＫＤＣによって生成される許可証明はリモートＫＤＣに使用されたクロスレルムＴＧＴに保存される必要がある。
【０２１６】
２つのＡＡＡドメインが一般的にはＤＮＳドメイン階層の異なる分岐に属するので、認証経路の決定プロセスが重要である。この場合、認証経路は下記文献［１５］に明記されているように、ＫＤＣｓの照会を用いて動的に決定し得る。更に、下記文献［１６］に記載されているように、ＴＧＴ取得手順の繰り返しを排除するより最適化された機構も存在する。
【０２１７】
ケルベロスのクロスレルムオペレーションも同じＡＡＡドメイン内のハンドオーバに対して可能である。モバイルノードが同じドメイン内のケルベロスレルムを横切ってサービングオーセンティケータから目標オーセンティケータに移動するとき、それはサービングＫＤＣ（即ち、サービングオーセンティケータのためのＫＤＣ）に接触することによって目標ＫＤＣ（即ち、目標オーセンティケータのためのＫＤＣ）に有効なcross-realm ＴＧＴを取得する。同じＡＡＡドメイン内の２つのＫＤＣ間に１以上の中間レルムが存在する場合、好ましくはモバイルノードは認証経路に沿ったＴＧＴ取得手順を繰り返す。サービングＫＤＣによって作成される認証証明は目標ＫＤＣに使用されるクロスレルムＴＧＴに保存される必要がある。認証経路はＤＮＳドメイン階層に基づいて構成できる。このＤＮＳドメイン階層はインタードメインの事例よりも容易な認証経路を横切る。
【０２１８】
リアクティブモードでは、クロスレルムオペレーションに必要なＴＧＴ取得手順の繰り返しがモバイルノードの代わりに目標オーセンティケータによって行われる。これはモバイルノードとオーセンティケータとの間のリンクにわたりケルベロスメッセージ交換を効果的に減少する。
【０２１９】
４．ＥＡＰからのケルベロスブートストラッピング
複数のＡＡＡドメイン間のローミングをサポートするために、機構はローカルＫＤＣの主要名及びそのためにできるだけ使用される秘密キーを動的に構成するために定義される。この目的のために、機構は、上述された及び以下の文献［１７］で検討された新たなＥＡＰメソッドであるＥＡＰ−ＥＸＴを用いてネットワークアクセス認証証明からケルベロスをブートストラップすることを提示している。上述したように、ＥＡＰ−ＥＸＴは任意のＥＡＰ認証メソッドをカプセル化するトンネルメソッドであり、新たに定義された機能性が可能とされるキャパビリティネゴシエーションを提供する。既存のＥＡＰメソッドにどのような変更もしないでそれらをなおも用いながら利用できる新たな機能性を作るのでＥＡＰ−ＥＸＴは既存のＥＡＰ認証メソッドに対して下位互換性を与える。ＥＡＰ−ＥＸＴは現在若干のキャパビリティ、例えば、チャネル結合及び再認証を定義する。しかしながら、これに関連して、新たなキャパビリティがケルベロスとしてＥＡＰ−ＥＸＴに加えられる。ケルベロスブートストラッピングのために付加的キャパビリティビット（例えば、‘Ｋ’ビット）を持つＥＡＰ−ＥＸＴメッセージフォーマットがケルベロスブートストラッピングキャパビリティを持つＥＡＰ−ＥＸＴメッセージフォーマットと表記された図１７に示されている。
【０２２０】
好ましくは、ピア及びサーバの両方が内部ＥＡＰ認証メソッドから転送されるキーを用いて保護された完全性である最終ＥＡＰ−ＥＸＴメッセージ交換に‘Ｋ’ビットを設定すると、ピア及びサーバはケルベロスをブートする。次の情報、即ちａ）モバイルノードとローカルＫＤＣとで共有される秘密キー（ＥＡＰ−ＫＲＢ−ＫＥＹ）の長さ及び寿命、ｂ）ローカルＫＤＣの主要名及びレルム並びにｃ）ローカルＫＤＣのＩＰアドレスがケルベロスをブートするために必要とされ、‘Ｋ’ビットが設定された最終ＥＡＰ−ＥＸＴ要求メッセージのケルベロスブート（ＫＲＢ−ＢＯＯＴ）ＴＬＶ（Type-Length-Value）で搬送される。
【０２２１】
ＥＡＰ−ＫＲＢ−ＫＥＹは次のようにＥＭＳＫ（EAP Master Session Key）からＵＳＲＫ（Usage Specific Root Key） （例えば、下記文献［１８］参照）として得られる。但し、ＫＤＦは文献［１８］に定義されたキー導出関数を示し、ｌｅｎｇｔｈは取得キーの長さを示す。
【０２２２】
ＥＡＰ−ＫＲＢ−ＫＥＹ＝ＫＤＦ（ＥＭＳＫ，“EAP-EXT-Kerberos-Boot-Key”, length）
ＥＡＰサーバもケルベロスブートストラッピングシーケンスとして表記された図８に示されるようにＫＲＢ−ＢＯＯＴ ＴＬＶに搬送された情報をローカルＫＤＣにインストールする。但し、「メソッド」はＥＡＰメソッドペイロードを保有するメソッドＴＬＶを示し、ＡＵＴＨは完全保護データを保有するＡＵＴＨ ＴＬＶを示す。
【０２２３】
ケルベロスブートストラッピング手順を簡単化するために、最も好ましくは、ＥＡＰサーバ及びローカルＫＤＣはＥＡＰサーバ及びローカルＫＤＣに対して同じ識別子を用いて同じノードにおいて実行される。そうでなければ、秘密キーを秘密に搬送するために３グループキー配信プロトコルがＥＡＰピア、ＥＡＰサーバ及びローカルＫＤＣの間でキー配信を必要とされることになる。
【０２２４】
５．結末注記
上記セクションは複数の問題を扱うためケルベロスを用いて新たなメディア独立ハンドオーバキー管理アーチテクチャを説明し、また、アーチテクチャがどのように複数のＡＡＡドメインにわたり働くかを説明し、かつケルベロスがＥＡＰメソッドを用いてどのように初期アクセス認証からブートし得るのかを説明している。ＫＨＫ手順を実施するときに、ケルベロスプロトコル、ケルベロスブートストラッピング及びケルベロスのリンク層搬送に対する変更を含めて、ＫＨＫに必要な一連のプロトコルを定義することが、例えば、Ｉ．Ｅ．Ｔ．Ｆ．及びＩ．Ｅ．Ｅ．Ｅ．８０２のような標準体には望ましくなる。更に、セクション４で説明したような初期ネットワークアクセス認証からのブートストラッピングはＫＨＫをブートするだけでなくＳＳＯ（Single-Sign On）のような多くの他のアプリケーション対するセキュリティをもブートすることを可能にする。
【０２２５】
文献
下記の背景文献の全開示は参照としてここに援用される。
【０２２６】
［１］ “Draft IEEE Standard for Local and Metropolitan Area Networks: Media Independent Handover Services,” IEEE LAN/MAN Draft IEEE P802.21/D05.00, April 2007.
［２］ B. Aboba, L. Blunk, J. Vollbrecht, J. Carlson and H. Levkowetz, “Extensible Authentication Protocol (EAP),” RFC 3748, June 2004 （上述した文献［ＲＦＣ３７４８］も参照）．
［３］ “IEEE Standard for Local and Metropolitan Area Networks Port-Based Network Access Control,” IEEE Std. 802.1X-2004.
［４］ “IEEE Standard for Local and metropolitan area networks - Specific requirements Part 11: Wireless LAN MAC and PHY specifications Amendment 6: Medium Access control (MAC) Security Enhancements,” IEEE 802.11i-2004.
［５］ “IEEE Standard for Local and metropolitan area network Part 16: Air Interface for Fixed and Mobile Broadband Wireless Access Systems Amendment 2,” IEEE 802.162005 and IEEE Std 802.16-2004/Cor1-2005.
［６］ C. Kaufman, “Internet Key Exchange (IKEv2) Protocol”, December 2005 （上述した文献［ＲＦＣ４３０６］も参照）．
［７］ D. Forsberg, Y. Ohba, B. Patil, H. Tschofenig, and A. Yegin, “Protocol for Carrying Authentication for Network Access (PANA),” Internet-Draft, work in progress, May 2007.
［８］ B. Aboba, D. Simon, “PPP EAP TLS Authentication Protocol”, RFC 2716, October 1999.
［９］ IETF HOKEY WG charter, http://www.ietf.org/html.charters/hokey-charter.html.
［１０］ A. Dutta, T. Zhang, Y. Ohba, K. Taniuchi, and J. Schulzrinne, “MPA assisted Optimized Proactive Handover Scheme,” Mobiquitous 2005.
［１１］ C. Neuman, T. Yu, S. Hartman and K. Raeburn, “The Kerberos Network Authentication Service (V5)”, RFC 4120, July 2005 （上述した文献［ＲＦＣ４１２０］も参照）．
［１２］ B. Aboba, “EAP GSS Authentication Protocol”, http://tools.ietf.org/html/draft-aboba-pppext-eapgss-12, August 2002.
［１３］ R. Lopez, A. Dutta, Y. Ohba, H. Schulzrinne and A. Skarmeta, “Network-Layer Assisted Mechanism for reducing authentication delay during handoff in 802.11 Networks”, to appear in Mobiquitous 2007.
［１４］ “Draft IEEE Standard for Local and metropolitan area networks - Specific requirements Part 11: Wireless LAN MAC and PHY specifications Amendment 2: Fast BSS Transition”, IEEE P802.11r/D6.0, May 2007.
［１５］ K. Raeburn and L. Zhu, “Generating KDC Referrals to Locate Kerberos Realms”, Internet-Draft, work in progress, March 2007.
［１６］ S. Zrelli, Y. Shinoda, S. Sakane, K. Kamada and M. Ishiyama, “XTGSP, the Inter-TGS protocol for cross-realm operations in Kerberos”, Internet-Draft, work in progress, March 2007.
［１７］ Y. Ohba, S. Das and R. Lopez, “An EAP Method for EAP Extension (EAP-EXT)”, Internet-Draft, work in progress, March 2007.
［１８］ J. Salowey, L. Dondeti, V. Narayanan and M. Nakhjiri, “Specification for the Derivation of Usage Specific Root Keys (USRK) from an Extended Master Session Key (EMSK)”, Internet-Draft, work in progress, January 2007.
具体的コンピュータアーチテクチャ
図１９は、幾つかの実施形態において、例えば、ピア、クライアント、サーバ、オーセンティケータ、モバイル装置、アクセスポイントなどのような装置又はエンティティによって行われるプロセスステップ及び通信を実行するために使用できる具体的コンピュータ又は同様な構成を示す。幾つかの実施形態では、そのような装置又はエンティティはバス３２６を介して一組の入出力（Ｉ／Ｏ）装置３２４と通信できる中央処理装置（ＣＰＵ）３２２を含む。Ｉ／Ｏ装置３２４は、例えば、キーパッド及び／又は他の装置を含むことができる。また、装置は（例えば、アンテナなどを使用する）通信用の送信機、受信機及び／又は送受信機を含むことができる。この通信は、この開示に基づく当業者には言うまでもないような妥当な装置機能性を達成するために必要に応じて無線通信、有線通信などを含むことができる。ＣＰＵ３２２はバス３２６を介してコンピュータ読み取り可能媒体（例えば、一般的な揮発性又は不揮発性データ記憶装置）３２８（以後、「メモリ３２８」）と通信できる。ＣＰＵ３２２、Ｉ／Ｏ装置３２４、バス３２６及びメモリ３２８の相互関係は従来知られているものと同様にできる。メモリ３２８は例えば、データ３３０を含むことができる。メモリ３２８はソフトウェア３３８も記憶できる。ソフトウェア３３８はプロセスのステップを実行するための複数のモジュール３４０を含むことができる。一般的プログラミング技術がこれらのモジュールを実施するために使用できる。メモリ３２８は上記及び／又は他のデータファイルも記憶できる。幾つかの実施形態では、ここに記載されている種々の方法はコンピュータシステムを用いてコンピュータプログラム製品を介して実施され得る。この実施は、コンピュータ読み取り可能媒体（例えば、ディスケット、ＣＤ−ＲＯＭ， ＲＯＭ又は同種のもの）に固定され、モデム又は同様なもののようなインターフェース装置を介してコンピュータシステムに送信できる一連のコンピュータ命令を含むことができる。通信媒体は実質的に有形（例えば、通信ライン）及び／又は実質的に無形（例えば、マイクロ波、光、赤外線などを用いた無線媒体）であってもよい。コンピュータ命令は種々のプログラム言語で書くことができ及び／又は半導体装置（例えば、チップ又は回路）、磁気装置、光学装置及び／又は他の記憶装置のような記憶装置に記憶できる。種々の実施形態では、送信は任意の適当な通信技術を使用できる。
【０２２７】
本発明の広い範囲
本明細書では、本発明の具体的実施形態を説明しているが、本発明は、本明細書で説明した様々な好ましい実施形態だけに限定されず、本開示に基づけば当分野の技術者によって理解されるはずの、等価の要素、改変、省略、（様々な実施形態にまたがる態様などの）組合せ、適合及び／又は変更を有するありとあらゆる実施形態を含むものである。特許請求の範囲における限定は、特許請求の範囲で用いられる言葉に基づいて幅広く解釈されるべきであり、本明細書において、又は本出願の出願中において記述される例だけに限定されず、これらの例は、非排他的であると解釈されるべきである。例えば、本開示において、「好ましくは」という用語は、非排他的であり、「それだけに限らないが、好ましくは」を意味する。本開示において、かつ本出願の出願中において、手段プラス機能又はステッププラス機能限定は、特定のクレーム限定について、この限定において、ａ）「〜の手段」又は「〜のステップ」が明記されている、ｂ）対応する機能が明記されている、及びｃ）構造、材料又はこの構造をサポートする動作が記載されていないという条件すべてが存在する場合に限り用いられる。本開示において、かつ本出願の出願中において、「本発明」又は「発明」という用語は、本開示内の１つ又は複数の態様を指すものとして使用され得る。本発明又は発明という言葉は、誤って重要度の識別と解釈されるべきではなく、誤ってすべての態様又は実施形態にわたって適用されるものと解釈されるべきではなく（すなわち、本発明はいくつかの態様及び実施形態を有すると理解されるべきであり）、また、誤って本出願又は特許請求の範囲を限定するものと解釈されるべきではない。本開示において、かつ本出願の出願中において、「実施形態」という用語は、任意の態様、特徴、プロセス又はステップ、これらの任意の組合せ、及び／又はこれらの任意の部分などを記述するのに使用され得る。いくつかの例では、様々な実施形態が重なり合う特徴を含み得る。本開示では、「例えば」を意味する「ｅ．ｇ．」という省略用語が用いられ得る。
【０２２８】
ＥＰＯはＥＰＯ以外の他の官庁から由来するデータ及び情報の正確性に対するどんな義務も受入れない。特に、ＥＰＯはそれらが特定の目的に対して完了し、最新であり、又は適合していることを保証しない。ＷＯ ２００８１０９０３９ （Ａ１）のこの明細書を翻訳する。
【技術分野】
【０００１】
本発明はメディア独立ハンドオーバキー管理アーチテクチャに関する。
【背景技術】
【０００２】
本出願は２００７年３月１日付で提出した、ケルベロス化ハンドオーバキーイングの改良として名称付けた、仮出願番号：６０／８９２，５３２の非仮出願であるとして米国特許法１１９に基づいて請求している。
【０００３】
一般的背景検討
背景出願
背景文献として、次の特許出願の各々の全開示は参照することにより本明細書に援用される。１）２００７年１月１９日付で提出され、ケルベロス化ハンドオーバキーイングと名称付けられた、仮出願：Ｎｏ．６０／８８５，７９５、２）全ての追加を含む、２００７年３月１日付で提出された、ケルベロス化ハンドオーバキーイングの改良と名称付けられた、仮出願：Ｎｏ．６０／８９２，５３２、３）２００７年１０月４日付で提出された、ＥＡＰ拡張（ＥＡＰ−ＥＸＴ）のためのＥＡＰ方法と名称付けられた、非仮出願：Ｎｏ．１１／８６７，６５９、及び４）２００７年１１月２４日付で提出された、ＥＡＰからケルベロスのブートストラップと名称付けられた、非仮出願：Ｎｏ． １１／９４４，６０５。
【０００４】
ネットワーク及びインターネット（登録商標）プロトコル
多様なコンピュータネットワークがあり、インターネットは最も有名である。インターネットは、コンピュータネットワークの世界規模のネットワークである。今日、インターネットは、何百万人ものユーザが利用可能な、公衆の自律的ネットワークである。インターネットは、ＴＣＰ／ＩＰ（すなわち、伝送制御プロトコル／インターネットプロトコル）と呼ばれる１組の通信プロトコルを使って各ホストを接続する。インターネットは、インターネットバックボーンとして呼ばれる通信インフラストラクチャを有する。インターネットバックボーンへのアクセスは大部分企業及び個人へのアクセスを再販するインターネットサービスプロバイダ（ＩＳＰ）によって制御される。
【０００５】
ＩＰ（インターネットプロトコル）に関して、これは、ネットワーク上である装置（電話機、ＰＤＡ［携帯情報端末］、コンピュータなど）から別の装置にデータを送るためのプロトコルである。今日、ＩＰｖ４、ＩＰｖ６などを含めて、様々なＩＰのバージョンがある。ネットワーク上の各ホスト装置は、独自の一意の識別子である少なくとも１つのＩＰアドレスを有する。
【０００６】
ＩＰはコネクションレス型プロトコルである。通信時の端点間接続は連続的ではない。ユーザがデータ又はメッセージを送信し、又は受信するとき、データ又はメッセージは、パケットと呼ばれる要素に分割される。各パケットは、独立のデータ単位として扱われる。
【０００７】
インターネット又は同様なネットワークを介した地点間の伝送を標準化するために、ＯＳＩ（開放型システム間相互接続）モデルが確立された。ＯＳＩモデルは、ネットワーク中の２地点間の通信プロセスを７つの階層に分け、各層は独自の機能セットを付加する。各装置は、送信側端点では各層を通る下り回線（downward flow）があり、受信側端点では各層を通る上り回線（upward flow）があるようにメッセージを取り扱う。７つの機能層を提供するプログラミング及び／又はハードウェアは、通常、デバイスオペレーティングシステム、アプリケーションソフトウェア、ＴＣＰ／ＩＰ及び／又は他のトランスポート及びネットワークプロトコル、並びに他のソフトウェア及びハードウェアの組み合わせである。
【０００８】
通常、上位４層は、メッセージがユーザから、又はユーザへ渡されるときに使用され、下位３層は、メッセージが装置（ＩＰホスト装置など）を通過するときに使用される。ＩＰホストは、サーバ、ルータ、ワークステーションなど、ＩＰパケットを送受信することのできるネットワーク上の任意の装置である。他の何らかのホストに向けられているメッセージは、各上位層には通過させないが、他のホストに送られる。ＯＳＩモデル及び他の同様なモデルでは、ＩＰが層３、ネットワーク層にある。
【０００９】
無線ネットワーク：
無線ネットワークは、例えば、セルラ及び無線電話機、ＰＣ（パーソナルコンピュータ）、ラップトップコンピュータ、装着型コンピュータ、コードレス電話機、ポケットベル、ヘッドセット、プリンタ、ＰＤＡなど、多種多様なモバイル機器を組み込むことができる。例えば、モバイル機器は、音声及び／又はデータの高速無線伝送を確保するデジタルシステムを含むことができる。一般的なモバイル機器は、次の構成要素の一部又は全部、即ち送受信機（すなわち、例えば、送信機、受信機及び、必要に応じて、他の機能が統合されたシングルチップ送受信機などを含む、送信機及び受信機）、アンテナ、プロセッサ、１つ又は複数の音声変換器（例えば、音声通信用機器でのスピーカやマイクロホンなど）、電磁データ記憶（データ処理が提供される機器の場合などでの、ＲＯＭ、ＲＡＭ、デジタルデータ記憶など）、メモリ、フラッシュメモリ、フルチップセット又は集積回路、インターフェース（ＵＳＢ、ＣＯＤＥＣ、ＵＡＲＴ、ＰＣＭなど）及び／又は同種のものを含む。
【００１０】
モバイルユーザが無線接続を介してローカルエリアネットワーク（ＬＡＮ）に接続することのできる無線ＬＡＮ（ＷＬＡＮ）が、無線通信に用いることができる。無線通信には、例えば、光、赤外線、電波、マイクロ波などの電磁波を介して伝搬する通信などが含めることができる。現在、ブルートゥース（登録商標）、ＩＥＥＥ８０２．１１、ＨｏｍｅＲＦなど、様々なＷＬＡＮ標準が存在する。
【００１１】
一例として、ブルートゥース製品は、モバイルコンピュータ、モバイル電話機、携帯式ハンドヘルド機器、携帯情報端末（ＰＤＡ）、及び他のモバイル機器の間のリンク、並びにインターネットへの接続を提供するのに使用できる。ブルートゥースは、モバイル機器が、短距離無線接続を使って、相互に、また非モバイル機器と、どのようにして容易に相互接続し合うことができるかを詳述するコンピュータ及び電気通信業界仕様である。ブルートゥースは、ある機器と別の機器との間でデータを同期させ、整合させ続けることを必要とする、様々なモバイル機器の普及から生じるエンドユーザ問題に対処して、異なるベンダからの装置を相互にシームレスに動作させるデジタル無線プロトコルを作成する。ブルートゥース機器は、共通の名称概念に従って名称付けできる。例えば、ブルートゥース機器は、ブルートゥース機器名（ＢＤＮ）又は一意のブルートゥース機器アドレス（ＢＤＡ）に関連付けられた名称を持ち得る。また、ブルートゥース機器は、インターネットプロトコル（ＩＰ）ネットワークに参加することもできる。ブルートゥース機器がＩＰネットワーク上で機能する場合、この機器は、ＩＰアドレス及びＩＰ（ネットワーク）名を備えることができる。よって、ＩＰネットワークに参加するように構成されたブルートゥース機器は、ＢＤＮ、ＢＤＡ、ＩＰアドレス及びＩＰ名などを含むことができる。「ＩＰ名」という用語は、インターフェースのＩＰアドレスに対応する名称を指す。
【００１２】
ＩＥＥＥ標準であるＩＥＥＥ８０２．１１は、無線ＬＡＮ及び機器の技術の仕様を定める。８０２．１１を使えば、各単一基地局がいくつかの機器をサポートする無線ネットワークが実現できる。いくつかの例では、機器に無線ハードウェアが事前装備されていることもあり、ユーザが、アンテナを含めることができ、カードなどの別個のハードウェアをインストールすることもできる。例えば、８０２．１１で使用される機器は、通常、機器がアクセスポイント（ＡＰ）であるか、移動局（ＳＴＡ）であるか、ブリッジであるか、ＰＣＭＣＩＡカードであるか、それとも別の機器であるか否かを問わず、無線送受信機、アンテナ、及びネットワークにおける各点間のパケットの流れを制御するＭＡＣ（媒体アクセス制御）層という３つの注目すべき要素を含む。
【００１３】
更に、いくつかの無線ネットワークでは、複数インターフェース機器（ＭＩＤ）が利用できる。ＭＩＤは、ブルートゥースインターフェースと８０２．１１インターフェースなど、２つの独立のネットワークインターフェースを含むことができ、よって、ＭＩＤが２つの別個のネットワーク上に参加すると同時に、ブルートゥース機器ともインターフェースすることが可能になる。ＭＩＤは、ＩＰアドレス、及びＩＰアドレスに関連付けられた共通ＩＰ（ネットワーク）名を持つことができる。
【００１４】
無線ネットワーク機器には、それだけに限らないが、ブルートゥース機器、複数インターフェース機器（ＭＩＤ）、８０２．１１ｘ機器（８０２．１１ａ、８０２．１１ｂ、８０２．１１ｇ機器などを含む、ＩＥＥＥ８０２．１１機器）、ＨｏｍｅＲＦ（家庭内無線周波数）機器、Ｗｉ−Ｆｉ（Wireless Fidelity）機器、ＧＰＲＳ（汎用パケット無線システム）機器、３Ｇセルラ機器、２．５Ｇセルラ機器、ＧＳＭ（移動通信用グローバルシステム）機器、ＥＤＧＥ（Enhanced Data for GSM Evolution）機器、ＴＤＭＡ型（時分割多重接続）機器、又はＣＤＭＡ２０００を含むＣＤＭＡ型（符号分割多重接続）機器が含めることができる。各ネットワーク機器は、それだけに限らないが、ＩＰアドレス、ブルートゥース機器アドレス、ブルートゥース共通名、ブルートゥースＩＰアドレス、ブルートゥースＩＰ共通名、８０２．１１ＩＰアドレス、８０２．１１ＩＰ共通名、又はＩＥＥＥ ＭＡＣアドレスを含む、様々な種類のアドレスを含むことができる。
【００１５】
また、無線ネットワークは、例えば、モバイルＩＰ（インターネットプロトコル）システム、ＰＣＳシステム、及び他のモバイルネットワークシステムにおいて見られるメソッド及びプロトコルも関与できる。モバイルＩＰでは、これに、インターネット技術標準化委員会（ＩＥＴＦ）によって作成された標準通信プロトコルが関与する。モバイルＩＰでは、モバイル機器ユーザは、これらの一旦割り当てられたＩＰアドレスを維持しつつ、各ネットワークにまたがって移動することができる。コメントリクエスト（ＲＦＣ）３３４４を参照されたい。注：ＲＦＣはインターネット技術標準化委員会（ＩＥＴＦ）の公式文書である。モバイルＩＰは、インターネットプロトコル（ＩＰ）を拡張し、モバイル機器のホームネットワーク外部に接続するときに、モバイル機器にインターネットトラフィックを転送する手段を付加する。モバイルＩＰは、各モバイルノードに、これのホームネットワーク上のホームアドレスと、ネットワーク及びこれのサブネット内の機器の現在位置を識別する気付アドレス（ＣｏＡ）を割り当てる。機器が異なるネットワークに移動すると、機器は、新しい気付アドレスを受け取る。ホームネットワーク上のモビリティエージェントは、各ホームアドレスを、これの気付アドレスと関連付けることができる。モバイルノードは、インターネット制御メッセージプロトコル（ＩＣＭＰ）などを使って、これの気付アドレスを変更する都度ホームエージェントにバインディング更新を送ることができる。
【００１６】
（例えば、モバイルＩＰ外部などの）基本的なＩＰ経路指定において、経路指定機構は、各ネットワークノードが、常に、インターネットなどへの一定の接続点を有し、かつ各ノードのＩＰアドレスが、これが接続されているネットワークリンクを識別するという仮定を利用する。本明細書において、「ノード」という用語は、例えば、データ伝送のための再配信点や端点などを含むことができ、他のノードへの通信を認識し、処理し、及び／又は転送することのできる接続点を含む。例えば、インターネットルータは、機器のネットワークを識別するＩＰアドレスなどを調べることができる。次いで、ネットワークレベルにおいて、ルータは、特定のサブネットを識別するビットセットを調べることができる。次いで、サブネットレベルにおいて、ルータは、特定の機器を識別するビットセットを調べることができる。一般的なモバイルＩＰ通信の場合、ユーザが、例えば、インターネットなどからモバイル機器を切断し、これを新しいサブネットで再接続しようとする場合、機器は、新しいＩＰアドレス、適正なネットマスク及びデフォルトのルータを用いて再構成する必要がある。そうでなければ、経路指定プロトコルは、パケットを適正に配信することができないはずである。
【００１７】
ケルベロス（Kerberos）に関する背景
ケルベロスはネットワーク認証プロトコルである。http://web.mit.edu/Kerberos/を参照。それは秘密キー暗号文を用いてクライアント／サーバアプリケーションの認証を行う。このプロトコルの自由な実施はマサチューセッツ工科大学から利用可能である。ケルベロスは更に多くの商品に利用できる。
【００１８】
ケルベロスはコンピュータネットワークにおけるサービスの要求を認証するための確実な方法である。ケルベロスはユーザに認証プロセスから暗号化チケットを要求させる。このとき、認証プロセスはサーバから特定のサービスを要求するために使用できる。ユーザのパスワードはネットワークを通過する必要がない。
【００１９】
ケルベロス［ＲＦＣ１５１０］は認証、許可及びキー配信を与える周知のセキュリティプロトコルである。それは複数のプロトコルを確保するために使用される。
【００２０】
ケルベロスはユーザがパスワードを再入力する必要がなくクライアントＡがチケット付与サービス（Ticket Granting Service (TGS)）をアクセスする初期チケットを取得することを可能にする。その初期チケットはクライアントＡがサービスＢをアクセスするための他のチケットを得るためＴＧＳとのケルベロル取り決めを開始することを可能にする。この方法を用いることによって、ケルベロスもＡが（ビジテッドドメイン（visited domain）において）ローカルＴＧＳをアクセスするため（Ａのホームドメインにおける）リモートＴＧＳからチケットを回復できる場合にクロスレルムオペレーション（cross-realm operation）を可能にする。しかしながら、ケルベロスは３人のメンバ間で時間同期を必要とする。
【００２１】
幾つかの例では、ＥＡＰフレームワークの柔軟性と大学でのケルベロスの幅広い展開とを組合すことによってケルベロスチケット付与チケットをブートすることが可能になる。このときこのケルベロスチケット付与チケットは各種プロトコルと共に使用するためサービスチケットを探索するために使用できる。ＥＡＰプロトコル相互作用を利用してケルベロスチケットをブートするこの方法は［I-D.tschofenig-pana-bootstrap-kerberos］に開示されている。その全ての開示は参照することにより本願に援用される。
【００２２】
ＥＡＰとケルベロスとを組み合わせる他の方法はＥＡＰ利用事前認証機構（EAP-based pre-authentication mechanism）をケルベロスに統合することである。しかしながら、証明をブートする一般的なプロトコルを使用することは（ＭＩＰｖ６ブートストラッピングワーク［I-D.ietf-mip6-bootstrap-ps］の一部として検討されているような）使用モバイルＩＰのための対象キーをブートするためにも又は公開／個人キーをブートするためにも利用できる。故に、一時公開及び個人キー対をエンドホストに送ることを機密保護する必要がある。このキー対は取り消し機構を多分必要としないで、短寿命であり、（ＩＫＥｖ２又はＴＬＳを含む）公開キー利用機構を利用する全てのセキュリティプロトコルにおいて使用できる。対称暗号化に基づく認証プロトコルはなおＥＡＰ内で使用できるので、回避された公開キー基盤が大きな利点となる。以下のセクションで検討するように、拡張可能認証プロトコル（Extensible Authentication Protocol (EAP)）［全体的に本願に引用して援用されるＲＦＣ３７４８を参照］が認証メソッドを提供する。幾つかの例では、ＰＡＮＡプロトコル［I-D.ietf-pana-pana］はアクセスネットワークにおいてＰａＣ（ＰＡＮＡクライアント）とＰＡＡ（ＰＡＮＡ認証エージェント）と間でＥＡＰメッセージを伝える。
【００２３】
ＥＡＰに関する背景
（以下に引用する）Ａｂｏｂａ，ＲＦＣ ３７４８を参照すると、拡張可能認証プロトコル（ＥＡＰ）の具体的態様が説明されている。ＥＡＰは複数の認証メソッドをサポートする認証フレームワークである。ＥＡＰは一般的にはＩＰを必要としない、ポイントツーポイントプロトコル（ＰＰＰ）又はＩＥＥＥ８０２のような複数のデータリンク層上で直接に実行する。ＥＡＰは二重削除及び再送信のため独自のサポートを備えているが、下位層順の保証に依存する。断片化はＥＡＰ自体内でサポートされないが、個々のＥＡＰメソッドがこれをサポートできる。
【００２４】
ＥＡＰは切換回路だけでなく、専用リンクに使用でき、無線リンクだけでなく有線であってもよい。今まで、ＥＡＰはＰＰＰ ［ＲＦＣ１６６１］を用いて切換回路又はダイアルアップネットワークを介して接続するホスト及びルータによって実現されていた。それはまたＩＥＥＥ ８０２［ＩＥＥＥ−８０２］を用いてスイッチ及びアクセスポイントによっても実現されていた。ＩＥＥＥ ８０２有線媒体に関するＥＡＰカプセル化が［ＩＥＥＥ−８０２．１Ｘ］に説明されており、ＩＥＥＥ無線ＬＡＮｓに関するカプセル化は［ＩＥＥＥ−８０２．１１ｉ］に開示されている。
【００２５】
ＥＡＰアーチテクチャの利点の１つはその柔軟性にある。ＥＡＰは、特定の認証機構を選択するため、一般的にはオーセンティケータ（authenticator）が使用すべき特定の認証メソッドを決定するためにより多くの情報を要求した後に選択するために使用される。各新しい認証メソッドをサポートするために更新されることをオーセンティケータが必要とする以外に、ＥＡＰは幾つか又は全てのメソッドに対するパススルーとして行動するオーセンティケータ及びピアによって、幾つか又は全ての認証メソッドを実施できるバックエンド認証サーバの使用を可能にする。
【００２６】
この後者の引用文献の中で、オーセンティケータがパススルーとして行動するか否かに関係なくオーセンティケータの要求が適用される。要求がオーセンティケータ又はバックエンド認証サーバのいずれかに適用されることを意味している場合、ＥＡＰ認証が終了される場所に依存して、用語「ＥＡＰサーバ」が使用されている。
【００２７】
ＥＡＰは再送信のサポートを行っている間、それは下位層によって提供される順序付け保証を仮定し、故に異常のある受信はサポートされない。
【００２８】
ＥＡＰは断片化及び再構築をサポートしないので、最小ＥＡＰ ＭＴＵより大きなペイロードを生成するＥＡＰ認証メソッドは断片化サポートを提供する必要がある。
【００２９】
ＥＡＰ−ＴＬＳのような認証メソッドは断片化及び再構築を提供するが、この後者の引用文献で定義されたＥＰＡメソッドは行わない。その結果、ＥＡＰパケットサイズがリンクのＥＡＰ ＭＴＵを越えれば、これらのメソッドは困難に合うことになる。
【００３０】
ＥＡＰ認証はサーバ（オーセンティケータ）によって初期化されるが、多くの認証プロトコルはクライアント（ピア）によって初期化される。その結果、ＥＡＰを通過するために１つ又は２つの追加メッセージ（多くとも１往復）を追加することが認証アルゴリズムに必要となるかもしれない。
【００３１】
証明利用認証がサポートされる場合、追加往復の数は証明書チェーン（certificate chains）の断片化によりかなり多くなるかもしれない。一般的に、断片化ＥＰＡパケットは断片があるだけ多くの往復で送る必要がある。例えば、サイズが１４９６０オクテットの証明書チェーンは１４９６オクテットＥＡＰ ＭＴＵで１０往復する必要がある。ＥＡＰが重大なパケットロスを起こす下位層を繰り返す場合、又はオーセンティケータと認証サーバとの接続が重要なパケットロスを起こす場合、多くの往復を必要とするＥＡＰメソッドは困難に直面することもある。これらの状況において、少ない往復を用いたＥＡＰメソッドの使用が望まれる。
【００３２】
ＥＡＰ認証交換は次のように処理される。
【００３３】
［１］オーセンティケータはピアを認証するためリクエスト（Request）を送る。リクエストは要求されているものを示すタイプフィールドを有する。リクエストタイプの例は識別（Identity）、ＭＤ５−チャレンジなどを含む。ＭＤ５−チャレンジタイプはＣＨＡＰ認証プロトコルに密接に対応する［ＲＦＣ１９９４参照］。一般的には、オーセンティケータは初期認証リクエストを送ることになるが、初期認証リクエストは必要とされなく、バイパスされないこともある。例えば、識別はピアが接続されているポート（専用回線、専用スイッチ又はダイアルアップポート）によって決定される場合、又は識別が（ＭＤ５−チャレンジレスポンスなどのネームフィールドにおいて、呼出局識別又はＭＡＣアドレスを介して）他のメソッドで得られる場合には要求されないこともある。
【００３４】
［２］ピアは有効リクエストに答えてレスポンスパケット（Response packet）を送る。リクエストパケットと同様に、レスポンスパケットはリクエストのタイプフィールドに対応するタイプフィールドを含む。
【００３５】
［３］オーセンティケータは追加リクエストパケットを送り、ピアはレスポンスで答える。リクエスト及びレスポンスのシーケンスは必要なだけ継続する。ＥＡＰは‘横並び（lock step）’プロトコルであり、故に、初期リクエスト以外は、新たなリクエストは有効なレスポンを受理する前に送ることができない。オーセンティケータはリクエストを再送信する責任がある。適正数の再送信の後には、オーセンティケータはＥＡＰ対話を終了すべきである。オーセンティケータは再送信するとき、又はピアからのレスポンスが得られないときには成功又は失敗パケットを送る必要がない。
【００３６】
［４］対話はオーセンティケータがピア（１以上のリクエストに対して受入れがたいレスポンス）を認証できなくなるまで続けられる。この場合、オーセンティケータの実行にはＥＡＰ失敗（コード４）を送信する必要がある。あるいは、認証対話は認証が成功したことをオーセンティケータが決定するまで継続する。この場合、オーセンティケータはＥＡＰ成功（コード３）を送信する必要がある。
【００３７】
他の利点では、ＥＡＰプロトコルは特定のものを事前に取り決めする必要が無く多くの認証機構をサポートできる。更に、ネットワークアクセスサーバ（ＮＡＳ）装置（例えば、スイッチ又はアクセスポイント）は各認証メソッドを理解する必要が無く、バックエンド認証サーバに対するパススルーエージェントとして動作できる。パススルーのためのサポートは随意的である。オーセンティケータはローカルピアを認証でき、更に、同時に非ローカルピア及びローカル的には実行しない認証メソッドに対するパススルーとして作用する。更に、バックエンド認証サーバからオーセンティケータを分離することによって証明管理及びポリシー決定を簡単にする。
【００３８】
概念的に、ＥＡＰ実施は次の要素からなる。
【００３９】
［ａ］下位層。下位層はピアとオーセンティケータとの間でＥＡＰを送受信する義務がある。ＥＡＰはＰＰＰ，有線ＩＥＥＥ８０２ラン［ＩＥＥＥ−８０２．１Ｘ］， IEEE 802.11 wireless LANs ［ＩＥＥＥ−８０２．１１］，ＵＤＰ（Ｌ２ＴＰ ［ＲＦＣ２６６１］及びＩＫＥｖ２参照）及びＴＣＰを含む各種下位層上で実行していた。
【００４０】
［ｂ］ＥＡＰ層。ＥＡＰ層は下位層を介してＥＡＰパケットを送受信し、二重検出及び再送信を実行し、ＥＡＰメッセージをＥＡＰピア及びオーセンティケータ層に送信し、オーセンティケータ層から受信する。
【００４１】
［ｃ］ＥＡＰピア及びオーセンティケータ層。コードフィールドに基づいて、ＥＡＰ層は入力ＥＡＰパケットをＥＡＰピア及びオーセンティケータ層に分離する。一般的には、所定ホストでのＥＡＰ実行はピア又はオーセンティケータ機能のいずれかをサポートすることになるが、ホストがＥＡＰピア及びオーセンティケータの両方として作用することを可能にする。そのような実行においては、ＥＡＰ及びオーセンティケータ層の両方が存在することになる。
【００４２】
［ｄ］ＥＡＰメソッド層。ＥＡＰメソッドはオーセンティケータアルゴリズムを実行し、ＥＡＰピア及びオーセンティケータ層を介してＥＡＰメッセージを送受信する。断片化のサポートはＥＡＰ自体によっては得られないが、これはＥＡＰメソッドの責任である。ｉｄ．
以後の参考文献はここに参照として引用される次の定義を説明している。
【００４３】
オーセンティケータ：
ＥＡＰ認証を初期化するリンクの終端。期間オーセンティケータは［ＩＥＥＥ−８０２．１Ｘ］に使用され、この文献では同様の意味を有する。
【００４４】
ピア：
オーセンティケータに応答するリンクの終端。［ＩＥＥＥ−８０２．１Ｘ］では、この終端はサプリカント（Supplicant）として知られている。
【００４５】
バックエンド認証サーバ：
バックエンド認証サーバは認証サービスをオーセンティケータに提供するエンティティ（entity）である。使用時には、このサーバは一般的にはオーセンティケータのためにＥＡＰメソッドを実行する。この専門用語は［ＩＥＥＥ−８０２．１Ｘ］に使用されている。
【００４６】
ＡＡＡ：
ＥＡＰサポートを持つ認証、許可、及び課金（Authentication, Authorization, and Accounting(ＡＡＡ)）プロトコルはＲＡＤＩＵＳ及びダイアミタ（Diameter）を含む。この文献では、用語“ＡＡＡサーバ”及び“バックエンド認証サーバ”は交換可能に使用される。
【００４７】
ＥＡＰサーバ又はサーバ：
ピアによってＥＡＰ認証メソッドを終了するエンティティ。バックエンド認証サーバが使用されない場合には、ＥＡＰサーバはオーセンティケータの一部である。オーセンティケータがパススルーモードで動作する場合、ＥＡＰサーバはバックエンド認証サーバに設けられる。
【００４８】
成功した認証：
この文献の内容では、「成功した認証」はＥＡＰメッセージの交換であり、その結果オーセンティケータはピアによってアクセスできることを決定し、ピアがこのアクセスを使用することを決定する。オーセンティケータの決定は一般的には認証及び許可面の両方を含み、ピアはオーセンティケータに首尾良く証明できるが、アクセスは政策的理由によりオーセンティケータによって拒絶されるかもしれない。
【００４９】
マスタセッションキー（ＭＳＫ）：
ＥＡＰピアとサーバ間で得られ、ＥＡＰメソッドによって転送されるキーイングマテリアル。ＭＳＫは長さが少なくとも６４オクテットである。既存の実施では、ＥＡＰサーバとして作用するＡＡＡサーバはＭＳＫをオーセンティケータに送る。
【００５０】
拡張マスタセッションキー（ＥＭＳＫ）：
ＥＡＰクライアントとサーバとの間で得られ、ＥＡＰ法によって転送される追加キーイングマテリアル。ＥＭＳＫは長さが少なくとも６４オクテットである。ＥＭＳＫはオーセンティケータ又は任意の他の第三者によっては共有されない。ＥＭＳＫはまだ定義されていない将来の使用のために予約される。
【００５１】
ＥＡＰ拡張：
参考のため、出願人は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.を参照する。この参考文献は次のようにＥＡＰ再認証プロトコルのためのＥＡＰ拡張を説明している。拡張可能認証プロトコルは２つのグループを認証するメソッドの搬送のための総括フレームワークであり、認証は一方向又は相互のいずれかである。主要目的はネットワークアクセス制御であり、キー生成メソッドはアクセス制御を実施するために推奨される。ＥＡＰキーイング階層は２つのキーを定義する。これらのキーはトップレベルで、即ちマスタキーセッション（ＭＳＫ）及び拡張ＭＳＫ（ＥＭＳＫ）で得られる。最も一般的な展開シナリオにおいては、ピア及びサーバはオーセンティケータとして知られている第三者を介して互いに認証する。オーセンティケータ又はオーセンティケータによって管理されるエンティティはアクセス制御を実施する。認証の成功後には、サーバはＭＳＫをオーセンティケータに搬送し、オーセンティケータ及びピアはＭＳＫを認証キー又はキー誘導キーとして用いて一時セッションキー（ＴＳＫ）を取得し、単位パケットアクセス実施のためにＴＳＫを使用する。Ｉｄ。ピアがあるオーセンティケータから他のオーセンティケータに移動するときは、完全ＥＡＰ認証を避けることが望ましい。ＥＡＰメソッドの他の実行との完全ＥＡＰ交換は完了するために数回の往復及びかなりの時間を取り、ハンドオフ時間に遅延が生じる。幾つかのＥＡＰメソッドは計算オーバヘッドを減じることによって再認証を最適化するために初期認証からの状態の使用を特定するが、メソッド特定再認証は殆どのケースでは少なくとも２往復する。殆どのメソッドは再認証に対するサポートを提供しないことに留意することも重要でもある。故に、個々のメソッドにおけるよりもＥＡＰにおいて効果的な再認証サポートを受けるのがよい。
【００５２】
オーセンティケータにわたって共有するキーはハンドオフタイムを低減するため現実的な解決法として時々使用される。その場合、オーセンティケータの譲歩が他のオーセンティケータを介して確立されるＥＡＰセッションの譲歩となる。ｌｄ。要するに、再びＥＡＰメソッドを実行することを必要としないでピアとオーセンティケータ間にフレッシュキーを確立することを可能にする有効ＥＡＰ再認証機構を設計する必要がある。ｌｄ。この文献はＥＡＰを用いて有効再認証のためにＥＡＰ再認証拡張（ＥＲＸ）を特定している。ＥＲＸに基づくＥＡＰ再認証プロトコル（ＥＲＰ）はピアに対するＥＡＰメソッド非依存再認証をサポートする。このピアは以前に実行されたＥＡＰ認証からの有効な残りキーマテリアルを有する。プロトコル及びＥＡＰ再認証に必要なキー階層がこの文献に記載されている。ｌｄ。
【００５３】
ＥＡＰの拡張（ＥＡＰ−ＥＸＴ）：
本願はいずれも「ＥＡＰ拡張（ＥＡＰ−ＥＸＴ）のためのＥＡＰ方法」と名称付けられ、Y. Oba, et al.による２００７年１０月４日付提出の本譲渡人の先願米国非仮出願番号１１／８６７，６５９及びY. Oba, et al.による２００６年１２月８日付提出の米国仮出願番号６０／８６９，１１３に記載されているような発明を越える更なる進展を提供している。両出願の全開示は全てここに記載されているようにここに引用して援用される。背景参照として、本譲渡人の前記背景出願の技術に関する情報は次のパラグラフに含まれる。
【００５４】
１．ＥＡＰ−ＥＸＴの序論
上記検討に加えて、ＥＡＰ（拡張可能認証プロトコル）は“ＥＡＰメソッド”［ＲＦＣ３７４８］として知られている多くの認証アルゴリズムを支援する認証プロトコルである。ＥＡＰでは、ＥＡＰピア及びＥＡＰサーバはＥＡＰキーイングマテリアル、即ち、ＭＳＫ（マスタセッションキー）及びＥＭＳＫ（拡張マスタセッションキー）を生成する。ＭＳＫの生成、搬送及び使用の詳しいフレームワークは［I-D.ietf-eap-keying］に記載されている。
【００５５】
ＥＭＳＫ用法の１つが再認証である場合にＥＭＳＫ（拡張マスタセッションキー）の幾つかの用法を定義することによってＥＡＰ ［ＲＦＣ３７４８］の拡張機能がある。ＥＡＰの他の拡張機能は［I-D.ohba-eap-channel-binding］に定義されているチャネル結合方式（channel binding scheme）である。チャネル結合に関する追加の背景文献として、２００６年４月２０日にＹ．Ｏｈｂａによって出願された、CHANNEL BINDING MECHANISM BASED PARAMETER BINDING IN KEY DERIVATIONと名称付けられた同時継続出願番号１１／３７９，５６８の全開示が全体として参照することによって本明細書に援用される。ＥＡＰの拡張機能をサポートする実施は拡張機能をサポートしない実施と相互運用する必要があり、故に、前者の実施は後者の実施と通信するとき拡張機能を無効にするので、ＥＡＰピアに対する機構が必要となり、ＥＡＰの拡張機能に関してケイパビリティを取り決めるＥＡＰサーバが必要となる。
【００５６】
ＥＡＰ機能を拡張するために２つの基本的な方法がある。１つの方法は既存の方法、即ち、リクエスト、レスポンス、成功及び失敗に加えて拡張ＥＡＰ機能を実現するために新たなＥＡＰコードを定義することである。しかしながら、この方法はＲＦＣ３７４８への変更を必要とし、下位層プロトコルへの変更も必要とするかもしれない。他の方法は拡張機能を実現するために新たなＥＡＰメソッドを定義することである。この文献は既存のＥＡＰ展開への攻撃を最小にする後者の方法と取る。
【００５７】
ＥＡＰ−ＥＸＴはＥＡＰ機能を拡張するＥＡＰメソッドを説明している。幾つかの好適実施形態では、拡張ＥＡＰ機能はチャネル結合及び再認証を含む。また、ＥＡＰ−ＥＸＴメソッドはその内部の多くのＥＡＰメソッドの順序づけを可能にする。
【００５８】
２．ＥＡＰ−ＥＸＴ概要
好適実施形態では、ＥＡＰ−ＥＸＴはケイパビリティ交換を提供する。これに関して、メッセージ内のビットはケイパビリティの表示に使用できる。幾つかの実施形態では、１ビット（Ｒ−ビット）は再認証ケイパビリティに使用される。幾つかの実施形態では、１ビット（Ｃ−ビット）はチャネル結合ケイパビリティを示すために使用される。
【００５９】
ＥＡＰ−ＥＸＴが使用されると、サーバは第１のＥＡＰリクエストを送る前にサーバにピアの識別が知られれば先のＥＡＰ−識別交換が省略できる。この点について、ピアの識別をサーバに提供する、例えば、オーセンティケータとサーバとの間でピアの識別を転送する幾つかのアウトバンド（outband）機構がある。
【００６０】
ＥＡＰ−ＥＸＴにおいて、チャネル結合及び再認証のような拡張ＥＡＰケイパビリティはピア及びサーバ間で交換される。同時に、少なくとも１つのＥＡＰメソッド（例えば、ＥＡＰ−ＴＬＳ）はピアを認証するためのＥＡＰ−ＥＸＴ内で実行される。内部メソッドがＥＡＰキーイングマテリアルを生成するまで、ＡＵＴＨ ＴＬＶ（Type-Length-Value）は含まれず、ケイパビリティは保護されない。故に、１つの内部ＥＡＰメソッドだけがあれば、ＡＵＴＨ ＴＬＶを有するがメソッドＴＬＶを有さない追加のＥＡＰ−ＥＸＴがＥＡＰ成功又はＥＡＰ失敗メッセージを送る前に実行される。ＴＬＶｓ（Type-Length-Value）に関する背景参照として、データ通信プロトコルにおいて情報はType-Length-Value又はプロトコルの内部のＴＬＶ要素として符号化できることを留意する。一例として、タイプ及び長さフィールドはサイズが（例えば、数バイトに）固定され、値フィールドは一般的には可変サイズである。これらのフィールドは一般的には次のように使用される、即ち、タイプはメッセージのこの部分が表すフィールドの種類を示す数値コード、長さ、即ち値フィールドのサイズ（一般的にはバイトで）、及び値、即ちメッセージのこの部分に対するデータを含む可変サイズのバイトセットを用いた。ＴＬＶ表現を用いる利点の幾つかはＴＬＶシーケンスが発生した構文解析関数を用いて容易に探索されること、古いノードで受信される新しいメッセージ要素が支障なく省略でき、メッセージの残りが構文解析できること、そしてＴＬＶ要素が一般的に早く構文解析を行い、データを小さくする二進形式で使用されることを含む。
【００６１】
内部ＥＡＰメソッドはＥＡＰキーイングマテリアルを生成した後、ＥＡＰ−ＥＸＴメッセージはＡＵＴＨ ＴＬＶによってサポートする必要がある。ＥＡＰ−ＥＸＴメッセージの中のＡＵＴＨ ＴＬＶｓは最後に成功した内部メソッドのＥＡＰキーイングマテリアルから生成されるＥＡＰ−ＥＸＴ−ＫＥＹを用いて計算する必要がある。これはＥＡＰ−ＥＸＴ内部で順次実行される複数の内部ＥＡＰメソッドがあれば、新たなＥＡＰ−ＥＸＴ−ＫＥＹがシーケンスの内部ＥＡＰメソッドがＥＡＰキーイングマテリアルを生成する毎に生成されることを意味する。任意の内部ＥＡＰメソッドはＥＡＰキーイングマテリアルを生成できる用になる必要がある。
【００６２】
成功したＥＡＰ−ＥＸＴ実行の最後に、最後に成功した内部ＥＡＰメソッドによって生成されるＥＡＰキーイングマテリアルはＥＡＰ層に転送される。Ｆ−ビットはＥＸＰ−ＥＸＴ交換の終了を示すために使用される。
【００６３】
図１は単一の内部ＥＡＰメソッドを持つＥＡＰ−ＥＸＴメッセージシーケンスの例を示す。図２は複数の内部ＥＡＰメソッドを有するＥＡＰ−ＥＸＴメッセージシーケンスの例を示す。
【００６４】
３．エラー処理
エラーは複数の理由、例えば、内部ＥＡＰメソッド認証の失敗又は異常、未知、紛失ＥＡＰ−ＥＸＴ ＴＬＶにより生じるかもしれない。エラーはピア又はサーバのいずれかによって検出できる。エラーを起こしたＥＡＰ−ＥＸＴメッセージは誤りメッセージと見なされる。Ｅ−ビットセットを持つＥＡＰ−ＥＸＴメッセージはエラー表示のために使用される。これらのメッセージはエラー表示と見なされる。エラー表示はＡＵＴＨ ＴＬＶを含める必要があり、他のＴＬＶｓを含めるべきでない。
【００６５】
有効ＡＵＴＨ ＴＬＶを持たない（間違ったエラー表示を含む）どんな間違いメッセージも無許可で破棄する必要がある。
【００６６】
有効ＡＵＴＨ ＴＬＶを持つ間違いリクエストに対して、ピアはエラー表示レスポンスを送る。有効ＡＵＴＨ ＴＬＶを伴わない間違いレスポンスに対して、サーバはエラー表示リクエストを送り、このリクエストはエラー表示レスポンスでピアによって応答される。サーバは有効ＡＵＴＨ ＴＬＶを伴うエラー表示レスポンスに応答してＥＡＰ失敗メッセージを送り返す。
【００６７】
４．完全性保護キー
ＥＡＰ−ＥＸＴは２種類のキー、即ち、１）ＥＡＰ−ＥＸＴ−ＫＥＹ及び２）ＥＡＰ−ＲＥＡＵＴＨ−ＫＥＹを定義する。
【００６８】
４．１．ＥＡＰ−ＥＸＴ−ＫＥＹは完全性保護ＥＡＰ−ＥＸＴメッセージのためにＡＵＴＨ ＴＬＶｓの計算に使用される。ＨＭＡＣ−ＳＨＡ−２５６（上記文献に含まれる参考［ｓｈａ２５６］を参照）は完全性アルゴリズムに使用されると、ＥＡＰ−ＥＸＴ−ＫＥＹのレングスは３２オクテットである。ＥＡＰ−ＥＸＴ−ＫＥＹは次のように定義されるＵＳＲＫ（Usage Specific Root Key）誘導アルゴリズムを用いて内部ＥＡＰメソッドによって生成されるＥＭＳＫから得られる（例えば、上記に参照することによって援用される参考［I-D.salowey-eap-emsk-deriv］を参照）。
【００６９】
ＥＡＰ−ＥＸＴ−ＫＥＹ＝ＫＤＦ（EMSK, [Epsilon]AP-EXT-Integrity-Key”, length）．
ＫＤＦでは、ＥＡＰ−ＥＸＴ−ＫＥＹは上記に参照することによって援用される参考文献［I-D.salowey-eap-emsk-deriv］に特定されているデフォルトＰＲＦを用いる。
【００７０】
背景参考として、ＵＳＲＫキー誘導関数（ＫＤＦ）は拡張マスタセッションキー（ＥＭＳＫ）、キーラベル、オプションデータ及び出力レングスからＵＳＲＫを求める。ＫＤＦは同じ入力に対して同じ出力を与えるはずである。基本キー誘導関数はＵＳＲＫ ＝ ＫＤＦ（ＥＭＳＫ、キーラベル、オプションデータ、レングス）である。Ｉｄを参照。一般的には、キーラベルは各使用定義に独特のプリント可能なＡＳＣＩＩストリングであり、最大２５５バイトである。Ｉｄを参照。一般的には、それらはドメインがＵＳＲＫの使用定義の仕様を管理する組織（organization）であるところのフォームlabel-string@domainである。キーラベルは広域的特異性を持つ。これらラベルの割り当てのルールは［I-D.salowey-eap-emsk-deriv］のセクション７に示されている。
【００７１】
前記文献に説明されているように、ＥＭＳＫキー誘導関数は次の関数プロトタイプを持つ仮想ランダム関数に基づいている。
【００７２】
ＫＤＦ＝ＰＲＦ（key,data）。Ｉｄを参照。ＵＳＲＫｓをＥＭＳＫから得るために使用されるデフォルトＰＲＦはＨＭＡＣ−ＳＨＡ−２５６に基づいて［ＲＦＣ４３０６］に由来するＰＲＦ＋キー拡張ＰＲＦから引き出される。ｐｒｆ＋構成が［ＲＦＣ２２４６］に使用されるもののような他のＰＲＦｓを超えるその簡単さ及び効率のために選択された。［ＲＦＣ４３０６］によるＰＲＦ＋の定義は以下に示される。
【００７３】
ｐｒｆ＋（Ｋ，Ｓ）＝Ｔ１｜Ｔ２｜Ｔ３｜Ｔ４｜．．．
但し
Ｔ１＝ｐｒｆ（Ｋ，Ｓ｜０ｘ０１）
Ｔ２＝ｐｒｆ（Ｋ，Ｔ１｜Ｓ｜０ｘ０２）
Ｔ３＝ｐｒｆ（Ｋ，Ｔ２｜Ｓ｜０ｘ０３）
Ｔ４＝ｐｒｆ（Ｋ，Ｔ３｜Ｓ｜０ｘ０４）
キーマテリアルの必要レングスを計算するために必要に応じて継続する。
【００７４】
キーＫはＥＭＳＫであり、Ｓは［I-D.salowey-eap-emsk-deriv］のセクション１に定義されたデータである。Ｉｄを参照。図のように、ＰＲＦはＨＭＡＣ−ＳＨＡ−２５６と考えられる。Ｉｄを参照。
【００７５】
４．２．ＥＡＰ−ＲＥＡＵＴＨ−ＫＥＹ
ＥＡＰ−ＲＥＡＵＴＨ−ＫＥＹは再認証機構に使用されるＥＡＰメソッドによって要求される事前共有キーとして使用される。ＥＡＰ−ＲＥＡＵＴＨ−ＫＥＹのレングスは再認証機構に依存する。ＥＡＰ−ＲＥＡＵＴＨ−ＫＥＹは上記で援用される参考文献［I-D.salowey-eap-emsk-deriv］に次のように定義されるＵＳＲＫ誘導アルゴリズムを用いてＥＡＰ−ＥＸＴから転送されるＥＭＳＫから得られる。
【００７６】
ＥＡＰ−ＲＥＡＵＴＨ−ＫＥＹ＝ＫＤＦ（EMSK,“EAP-EXT-Reauthentication-Key”, length）
５．メッセージフォーマット
ＥＡＰ−ＥＸＴは（ＩＡＮＡによって割り当てられるべき）ＥＡＰ Ｔｙｐｅ Ｘを用いる。［ＲＦＣ３７４８］に定義された共通ＥＡＰフィールド（例えば、コード、識別子、長さ及び種類）を含むメッセージフォーマットは図３（Ａ）に示される。
【００７７】
Ｆ：
このビットはこれが送信者からの最後のＥＡＰ−ＥＸＴメッセージであることを示すように設定する必要がある。そうでなければ、このビットは設定する必要がない。
【００７８】
このビットはメッセージがエラー表示であるときに設定される。このビットが設定されると、Ｆビットも設定する必要がある。エラー表示に関する詳細な説明のセクション３を参照。
【００７９】
バージョン：
この８ビットフィールドはＥＡＰ−ＥＸＴメソッドのバージョンを示す。この文献はバージョン１を定義している。
【００８０】
予約（Reserved）：
この６ビットフィールドは将来の拡張のために予約される。このフィールドは送信者によってゼロに設定する必要があり、受信者はこのフィールドを無視する必要がある。
【００８１】
ケイパビリティ
ケイパビリティが扱うこのフィールドは拡張ＥＡＰケイパビリティを含む。ケイパビリティは図３（Ｂ）に示されるフォーマットを扱う。
【００８２】
各ビットは特定ケイパビリティに対応する。各ビットの意味は次の通りである。
【００８３】
Ｃ：
このビットは送信者がＭＳＫのための［I-D.ohba-eap-channel-binding］に定義されるチャネル結合機構をサポートすることを示すために設定される。このビットはリクエスト及びレスポンスの両方に対して設定され、ＥＡＰ−ＥＸＴメソッドが首尾よく完了すると、ピア及びサーバはチャネル結合機構を可能にする必要がある。ｐｒｆ＋用デフォルトハッシュアルゴリズム（default hash algorithm）はＡＵＴＨ＿ＨＭＡＣ＿ＳＨＡ１＿１６０である。
【００８４】
Ｒ：
このビットは送信者が再認証ＥＡＰメソッドをサポートすることを示すために設定される。このビットは最後のリクエスト／ＥＸＴメッセージに設定されると（即ち、Ｆビットを有するリクエスト／ＥＸＴが設定されると）、メッセージはサーバＩＤ ＴＬＶ及びピアＩＤ ＴＬＶを含める必要があり、Reauth-Key-Lifetime ＡＶＰを含めることができる。このビットが最後のリクエスト／ＥＸＴ及びレスポンス／ＥＸＴメッセージ交換に設定されると、ピア及びサーバはＥＡＰ−ＲＥＡＵＴＨ−ＫＥＹを発生する必要がある。サーバＩＤ及びピアＩＤはサーバＩＤ及びピアＩＤ ＴＬＶｓに含められ、ＥＡＰ−ＲＥＡＵＴＨ−ＫＥＹは再認証ＥＡＰメソッドに使用される。デフォルト再認証機構はこの開示に基づく従来技術のそれらによって選択できる。
【００８５】
他のビットは将来の使用のために予約され、送信者によってゼロに設定する必要があり、受信者によって無視される必要がある。
【００８６】
ＴＬＶ（Type-Length-Value's）：
ゼロ，１以上のＴＬＶｓ。ＴＬＶフォーマットは図３（Ｃ）に示される。
【００８７】
タイプ：
このフィールドはこのＴＬＶのタイプを示す。
【００８８】
レングス：
このフィールドは種類及びＴＬＶのレングスフィールドを含めて、オクテットでこのＴＬＶのレングスを示す。
【００８９】
バリュー：
このフィールドはＴＬＶタイプに特定されるデータを含む。
【００９０】
６．ＥＡＰ−ＥＸＴ ＴＬＶｓ
次のＴＬＶｓが定義される。
【００９１】
６．１．メソッドＴＬＶ
メソッドＴＬＶ（タイプ１）はタイプフィールドから開始するＥＡＰメソッドペイロードを含む。
【００９２】
６．２．ＡＵＴＨ ＴＬＶ
ＡＵＴＨ ＴＬＶ（タイプ２）はＥＡＰ−ＥＸＴメッセージを保護するために使用される完全性データを含む。ＥＡＰ−ＥＸＴ−ＫＥＹはＡＵＴＨ ＴＬＶｓを計算するために使用される。
【００９３】
ＴＬＶバリューフィールドはこのフィールドを含む全体のＥＡＰメッセージわたって計算される。完全性データを計算する前に、このフィールドは全てゼロに初期化する必要がある。このフィールドのレングスは使用時に完全性アルゴリズムに依存する。完全性チェックが失敗すると、メッセージは無許可で破棄する必要がある。デフォルト完全性アルゴリズムはＨＭＡＣ−ＳＨＡ−２５６である（例えば、以下で援用されている文献［ｓｈａ２５６］を参照）。
【００９４】
６．３．ピアＩＤ ＴＬＶ
ピアＩＤ ＴＬＶ（タイプ３）は再認証に使用されるピアの識別を含む。
【００９５】
６．４．サーバＩＤ ＴＬＶ
サーバＩＤ ＴＬＶ（タイプ４）は再認証に使用されるサーバの識別を含む。
【００９６】
６．５．Ｒｅａｕｔｈ−Ｋｅｙ−Ｌｉｆｅｔｉｍｅ ＴＬＶ
Ｒｅａｕｔｈ−Ｋｅｙ−Ｌｉｆｅｔｉｍｅ ＴＬＶ（タイプ５）はＥＡＰ−ＲＥＡＵＴＨ−ＫＥＹの寿命を秒単位で含む。
【００９７】
７．安全性考察
内部ＥＡＰメソッドがＥＡＰキーイングマテリアルを送る前にケイパビリティ交換は保護されない。故に、ＥＡＰキーイングマテリアルの作成後の追加サポートメッセージ交換は能力情報がピア及びサーバによって検出されないで攻撃者によって変更されるのを避けるために義務付けられる。
【００９８】
ＥＡＰ−ＥＸＴはその中の多くのＥＡＰメソッドの順序付けを可能にする。複数の入れ子又は順序認証メソッド（multiple nested or sequential authentication methods）を暗号的に結合しないでそれらで構成される複合認証メソッドが介入者攻撃（man-in-the-middle attack）に対して無防備である。ＥＡＰ−ＥＸＴはシーケンスにおいて前に成功した内部メソッドによって生成されるキーを用いて外部ＥＡＰメソッド（即ち、ＥＡＰ−ＥＸＴ）と共に各内部ＥＡＰメソッドを保護し、最後に成功した内部ＥＡＰメソッドによって生成されるＥＡＰキーイングマテリアルを最終的に転送することによって必要な暗号化的結合を作ることができる。暗号化結合を達成するために、ＥＡＰ−ＥＸＴはＥＡＰキーイングマテリアルを生成できる内部ＥＡＰメソッドを必要とする。
【００９９】
ブートストラッピングケルベロス
１．序論
ケルベロス［ＲＦＣ４１２０］は共有秘密キー暗号化を用いてオープン（非保護）ネットワーク上の各種ネットワークアプリケーションの端点（end-points）の同一性を証明する手段を提供する第三者認証プロトコルである。ケルベロスに対する拡張は認証プロトコル［ＲＦＣ４５５６］のある段階中の公開キー暗号化の使用のために提供できる。
【０１００】
ＥＡＰ（拡張可能認証プロトコル）は“ＥＡＰメソッド”［ＲＦＣ３７４８］として知られている複数の認証アルゴリズムをサポートする認証プロトコルである。しかしながら、ＥＡＰの適用はネットワークアクセス認証のためである。ＥＡＰは各種ネットワークアプリケーションに対して認証を提供するためには予定されていない。
【０１０１】
参考として、以下の表はケルベロスとＥＡＰとの差の幾つかを強調している表である。
【表１】
【０１０２】
新たなシングルサインオン（single sign-on）の必要性があり、シングルサインオンでは、ビジテッド又はホームドメインにおけるネットワークアクセスのための初期認証がリンク層からアプリケーション層に及んで、ドメイン内で使用される複数の異なるプロトコルにセッションキーを与えることができる。
【０１０３】
特に、セッションキーをリンク層プロトコルに与えることによって、リンク層ハンドオーバ性能がオーセンティケータ内及びオーセンティケータ間ハンドオーバを含めてドメイン内でハンドオーバ毎にＥＡＰ信号経路を除去することによって最適化できる。このセクションはＥＡＰからケルベロスをブートする機構を説明しており、このセクションでは、ＥＡＰが初期ネットワークアクセス認証のために使用され、ケルベロスは複数の異なるプロトコルにセッションキーを付与するために使用される。このセクションでは、機構を実現するためにＥＡＰ−ＥＸＴ暗号化が使用される。
【０１０４】
２．ＥＡＰ−ＥＸＴの再検討
幾つかの好適実施形態によると、新たなキャパビリティはケルベロスの新たなキャパビリティを含めて、（上述した）ＥＡＰ−ＥＸＴ暗号化内で定義される。
【０１０５】
これらの実施形態はキャパビリティフィールドに新たなキャパビリティビット（Ｋ）を定義し、ＥＡＰ−ＥＸＴの新たなＴＬＶｓ（例えば、ＫＲＢ−ＢＯＯＴ ＴＬＶ及びＫＲＢ−ＭＳＧ ＴＬＶ）も定義する。好適実施形態では、新たなキャパビリティビット（Ｋ）及びこれらの新たなＴＬＶｓは次のように使用される。
【０１０６】
ＥＡＰ−ＥＸＴ交換においては、ピア及びサーバが機能性（ＢＫＥとしてここに参照されているような機能性）を使用することを望めばピア及びサーバはキャパビリティフィールドにＫビットを設定する。ピア及びサーバの両者はＡＵＴＨ ＴＬＶセットによってＫビットを設定すれば、そのとき、好適実施形態では、システムは以下の方法で追加のＥＡＰ−ＥＸＴ交換を使用する。
【０１０７】
最初にサーバはケルベロスブートストラッピングパラメータをピアに送る。好ましくは、ケルベロスブートストラッピングパラメータはケルベロスブート（ＫＲＢ−ＢＯＯＴ）ＴＬＶに含まれる。このとき、ピアはケルベロスＡＳ−ＲＥＱメッセージをケルベロスＫＤＣ（Key Distribution Center）に送る。このとき、信号伝達のこの部分がＥＡＰ−ＥＸＴ外で行われる場合、ＫＤＣはＡＳ−ＲＥＰをサーバに戻す。ＡＳ−ＲＥＰがＫＲＢ−ＭＳＧ ＴＬＶに含まれる場合、サーバはＡＳ−ＲＥＰをピアに送る。
【０１０８】
最後に、ピアは確認をサーバに送り、サーバはＥＡＰ成功又はＥＡＰ失敗メッセージをピアに送る。好適実施形態では、これら交換の全てはＡＵＴＨ ＴＬＶによって保護される必要がある。
【０１０９】
ケルベロスがＥＡＰからブートされた後にケルベロスが使用される方法は環境に基づいて当業者によって決定でき、それに関する詳細はここでの目的のためには必要としない。
【０１１０】
図１はＢＫＥを持つＥＡＰ−ＥＸＴメッセージの例を示している。
【０１１１】
３．新たなメッセージフォーマット
好適実施形態によると、上記で示すように、ＥＡＰ−ＥＸＴのキャパビリティフラグの新たなビット、即ち新Ｋビットが定義される。
【０１１２】
図４を参照して、好適実施形態に従ったＥＡＰ−ＥＸＴメッセージフォーマットへの変更について説明する。
【０１１３】
ＫビットはＥＡＰ（ここではＢＫＥと称する）からケルベロスをブートするためのサポートを示す。好適実施形態では、ピア及びサーバの両者は一度ＡＵＴＨ ＴＬＶセットによってＫビットを設定すると、そのとき付加交換が上述したようにＥＡＰ−ＥＸＴ内で行われる。
【０１１４】
４．新キー
好適実施形態では、１つの新キーがここで説明された機能性を提供するために定義される。この新キーはＥＡＰ−ＫＲＢ−ＫＥＹと称される。ＥＡＰ−ＫＲＢ−ＫＥＹはケルベロスによって要求される事前共有キーとして使用される。好適実施形態では、ＥＲＰ−ＫＲＢ−ＫＥＹのレングス及び寿命はＥＡＰ−ＥＸＴ内でサーバからピアに伝えられる。例えば、ＥＲＰ−ＫＲＢ−ＫＥＹのレングスがＥＡＰ−ＥＸＴ内で取決められる。好適実施形態では、ＥＲＰ−ＫＲＢ−ＫＥＹキーは例えば、上記参照によって援用される文献［I-D.salowey-eap-emsk-deriv］に定義されたＵＳＲＫ誘導アルゴリズムを用いてＥＡＰ−ＥＸＴから転送されるＥＭＳＫから次のように得られる。
【０１１５】
ＥＡＰ−ＫＲＢ−ＫＥＹ＝ＫＤＦ（EMSK, “EAP-EXT-Kerberos-Bootstrapping-Key”, length）
ＫＤＦでは，ＥＡＰ−ＥＸＴ−ＫＲＢは［I-D.salowey-eap-emsk-deriv］に明記されたデフォルトＰＲＦを使用する。
【０１１６】
５．新ＥＡＰ−ＥＸＴ ＴＬＶｓ
好適実施形態によると、次の新ＴＬＶｓが定義される。
【０１１７】
５．１．ケルベロスブート（ＫＲＢ−ＢＯＯＴ）ＴＬＶ
好適実施形態では、ケルベロスブートストラッピングパラメータを含む新ケルベロスブートＴＬＶ（タイプ６）が確立される。好適実施形態では、次のケルベロスブートストラッピングパラメータが出現順に含まれる。
【０１１８】
ａ）ＥＡＰ−ＫＲＢ−ＫＥＹレングス（２オクテット）
好適実施形態では、このフィールドはＥＡＰ−ＫＲＢ−ＫＥＹのレングスをオクテットで示す。
【０１１９】
ｂ）ＥＡＰ−ＫＲＢ−ＫＥＹ寿命（２オクテット）
好適実施形態では、このフィールドはＥＡＰ−ＫＲＢ−ＫＥＹの寿命はＥＭＳＫの寿命を超える必要がある。
【０１２０】
ｃ）主要名（可変長）
好適実施形態では、このフィールドはＡＳＮ．１（Abstract Syntax Notation One）のＤＥＲ（Distinguished Encoding Rules）によって符号化される、ピアのケルベロス主要名を含む。ＡＳＮ．１の有名な符号化ルールがＸ．５０９によって基本符号化ルール（ＢＥＲ）符号化を行う制約から得られる国際基準である。抽象シンタックス概念１（Abstract Syntax Notation One ：ＡＳＮ．１）はコンピュータ間で送られているデータ構造がどのように符号化及び復号化されているかを制御する次のルールセット、即ち、基本符号化ルール（ＢＥＲ）；正規符号化ルール（ＣＥＲ）；有名符号化ルール（ＤＥＲ）；及びパック符号化ルール（ＰＥＲ）を定義する。オリジナルルールセットはＢＥＲ仕様によって定義された。ＣＥＲ及びＤＥＲはＢＥＲの特定サブセットとして最近開発された。ＰＥＲはＢＥＲ又はその改良型を用いてデータを送信するために必要な帯域幅量についての批判に応じて開発された。ＰＥＲは大きな省力をもたらす。ＤＥＲは安全なデータ転送のためＸ．５０９仕様の要求を満たすように作られた。例えば、証明登録（Certificate Enrollment）ＡＰＩはＤＥＲを単独に使用する。参考までに、INTERNATIONAL TELECOMMUNICATION UNION, Information Technology - ASN.1 Encoding Rules - Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER)及びDistinguished Encoding Rules (DER), ITU-T Recommendation X.690, July 2002を参照。これらの全開示は参照として援用される。
【０１２１】
ｄ）レルム（可変長）
好適実施形態では、このフィールドはＡＳＮ．１（Abstract Syntax Notation One)のDER (Distinguished Encoding Rules）によって符号化された、ピア及びＫＤＣのケルベロスレルムを含む。
【０１２２】
ｅ）ＩＰアドレスレングス（１オクテット）
好適実施形態では、このフィールドはＫＤＣのＩＰアドレスを含む。
【０１２３】
ｆ）ＫＤＣのＩＰアドレス（４又は１６オクテット）
好適実施形態では、このフィールドはＫＤＣの二進符号化ＩＰアドレスを含む。ＩＰアドレスレングスが４であれば、それは好ましくはＩＰｖ４アドレスを含む。ＩＰアドレスレングスが１６であれば、それは好ましくはＩＰｖ６アドレスを含む。
【０１２４】
５，２．ケルベロスメッセージ（ＫＲＢ−ＭＳＧ）ＴＬＶ
好適実施形態では、ケルベロスメッセージＴＬＶ（タイプ７）はＡＳ−ＲＥＱ及びＡＳ−ＲＥＰのようなケルベロスメッセージ（例えば、ＤＥＲ符号化メッセージ）を含む。
【０１２５】
６．０具体的メセージ交換シーケンス
図５乃至９はコンポーネント又はモジュール間の具体的通信を記載した、幾つかの具体的メッセージ交換シーケンスを示す。
【０１２６】
これに関して、図５乃至７はＢＫＥ機能を採用している幾つかの具体的実施形態に従ったメッセージシーケンスを示す。ここでは、図５はクライアント／ピア１０、サーバ３０及びキー配信センタ（ＫＤＣ）４０の間のメッセージシーケンスを示し、図６及び７はクライアント／ピア１０、サーバ３０、オーセンティケータ２０及びＫＤＣ（４０）の間のメッセージシーケンスを示す。
【０１２７】
これに関して、クライアント／ピア１０は、好適実施形態では、例えば、携帯電話、パーソナルコンピュータ、卓上コンピュータ、ウェラブルコンピュータ、ＰＤＡなどのようなモバイルノード又は装置に含めることができる。この際、クライアント／ピア１０は（図６及び７に緑で表された）ＥＡＰピアの機能性及び（図６及び７に赤で表された）ケルベロスクライアントを含むことができる。
【０１２８】
図５に示すように、クライアント／ピア１０、サーバ３０及びキー配信センタ（ＫＤＣ）４０の間のような通信がＢＫＥを採用する幾つかの実施例において次のようにできる。
【０１２９】
最初に、図５にａ）で示すように、サーバ３０はＥＡＰリクエスト／識別をピア１０に選択的に送信でき、ピアは、図５にｂ）で示すように、ＥＡＰリクエスト／識別をサーバ３０に選択的に送信できる。
【０１３０】
次に、図５のｃ）に示されるように、サーバ３０はＥＡＰリクエスト／ＥＸＴ｛Ｃａｐ．（Ｋ），メソッド｝メッセージをピア１０に送信する。ここで、Ｃａｐ．（Ｋ）はメッセージがキャパビリティフィールドセット有し、メソッドはメソッドＴＬＶに関することを示す。応答として、図５にｄ）で示されるように、ピア１０はＥＡＰレスポンス／ＥＸＴ｛Ｃａｐ．（Ｋ），メソッド｝メッセージをサーバ３０に送信できる。
【０１３１】
次に、図５にｅ）で示されるように、サーバ３０はＥＡＰ−リクエスト／ＥＸＴ｛Ｃａｐ．（Ｋ），ＡＵＴＨ｝メッセージをピア１０に送信する。ここで、Ｃａｐ．（Ｋ）はメッセージがキャパビリティフィールドセットのＫビットを有し、ＡＵＴＨがＡＵＴＨ ＴＬＶに関連することを示している。応答として、図５にｆ）で示すように、ピア１０はＥＡＰ−レスポンス／ＥＸＴ｛Ｃａｐ．（Ｋ），ＡＵＴＨ｝メッセージをサーバ３０に送信できる。
【０１３２】
次に、図５にｇ）で示すように、サーバ３０はＥＡＰ−リクエスト／ＥＸＴ｛Ｃａｐ．（Ｋ），ＫＲＢ−ＢＯＯＴ，ＡＵＴＨ｝メッセージをピア１０に送信する。ここで、Ｃａｐ．（Ｋ）はキャパビリティフィールドセットを有し、ＫＲＢ−ＢＯＯＴは（ケルベロスブートストラッピングパラメータを含む）ケルベロスブートＴＬＶに関連し、かつＡＵＴＨはＡＵＴＨ ＴＬＶに関連する。応答として、図５にｈ）で示されるように、ピア１０はＥＡＰ−レスポンス／ＥＸＴ｛Ｃａｐ．（Ｋ），ＫＲＢ−ＭＳＧ，ＡＵＴＨ｝メッセージをサーバ３０に送信できる。ここで、ＡＳ−ＲＥＱメッセージはケルベロスメッセージＴＬＶ（ＫＲＢ−ＭＳＧ）に含まれる。
【０１３３】
図５にｌ）で示されるように、サーバ３０もケルベロスブートストラッピングパラメータをＫＤＣに送信する。
【０１３４】
更に、図５にｍ）で示されるように、サーバ３０はこのときＡＳ−ＲＥＱメッセージをケルベロスＫＤＣ（キー配信センタ）に送る。それから、図５にｎ）で示されるように、信号伝達のこの部分がＥＡＰ−ＥＸＴ外で行われる場合、ＫＤＣはＡＳ−ＲＥＰメッセージをサーバに返す。
【０１３５】
次に、図５にｉ）で示されるように、ＡＳ−ＲＥＰがＫＲＢ−ＭＳＧ ＴＬＶに含まれる場合、サーバ３０はＡＳ−ＲＥＰをピア１０に送る。その際、サーバ３０は図示のようにｉ）でＥＡＰ−リクエスト／ＥＸＴ｛Ｃａｐ．（Ｋ），ＫＲＢ−ＭＳＧ，ＡＵＴＨ｝メッセージを送信する。
【０１３６】
最後に、ピアは確認をサーバに送り、サーバはＥＡＰサクセス（成功）又はＥＡＰフェイラ（失敗）メッセージをピアに送る。ここで、好ましくは、図５にｊ）で示されるように、ピア１０はＥＡＰ−レスポンス／ＥＸＴ｛Ｃａｐ．（Ｋ），ＡＵＴＨ｝メッセージをサーバ３０に送り、サーバ３０はＥＡＰサクセスメッセージをピア１０に送る。
【０１３７】
好適実施形態では、これら交換の全てはＡＵＴＨ ＴＬＶによって保護される必要がある。
【０１３８】
図６を参照して、この図は図５に示されるメッセージシーケンスと実質的に同じである。しかしながら、図６は更にオーセンティケータ２０に関してメッセージ交換を示している。これに関して、図６にｘ）で示されるように図５に示されるステップｊ）後に、サーバはＭＳＫをオーセンティケータ２０に送信し、それからｙ）にて、安全関連性（Secure Association）がピア／クライアントとオーセンティケータとの間に確立される。
【０１３９】
図７はＢＫＥ機能性を採用し、更にＴＧＳ−ＲＥＱ／ＲＥＰを含む幾つかの具体的実施形態に従った他のメッセージシーケンスである。背景参考のために、ケルベロスにおいて、クライアントはチケット付与サービス（ＴＧＳ）にアプリケーションサーバと通信するために必要なチケットを問い合わせる。ＴＧＳによって生成されたチケットは全てアプリケーションサーバキーによって暗号化された、クライアントの識別及びセッションキーを含む。ＴＧＳは全てクライアントキーで暗号化された、チケット及びセッションキーのコピーをクライアントに戻す。しかしながら、この交換はクライアントの識別のいかなる認証も単独で提供しない。クライアントの識別の認証はチケット検証に基づいてクライアントとアプリケーションサーバとの他の交換によって成される。ＴＧＳはチケットを発行することによってクライアントの識別に同意する。クライアント及びアプリケーションサーバはＴＧＳによって発行されたチケットを検証することによってクライアントの識別に同意する。クライアント識別に関する第三者の同意は、チケットがセッションキーとクライアントの識別との結合を持つ場合、クライアントとアプリケーションサーバとの間にセッションキーを保有する暗号証明に基づいて安全になされる。
【０１４０】
図７を参照して、ｘ１）で示されるように、ピア１０はフォーマットＥＡＰレスポンス／ＥＸＴ｛Ｆ，ＫＲＢ−ＭＳＧ（ＴＧＳ−ＲＥＱ），ＡＵＴＨ｝のサーバ３０にメッセージを送信し、ｘ２）で示すように、サーバ３０はＴＧＳ−ＲＥＱをＫＤＣに送信する。このとき、ＫＤＣは図７にｙ２）で示すようにＴＧＳ−ＲＥＰを返信する。次に、サーバ３０はメッセージをフォーマットＥＡＰリクエスト／ＥＸＴ｛Ｆ，ＫＲＢ−ＭＳＧ（ＴＧＳ−ＲＥＰ），ＡＵＴＨ｝のピア１０へ送信する。このとき、ピアは上記と同様にＥＡＰレスポンス／ＥＸＴ｛Ｆ，ＡＵＴＨ｝を送信する。
【０１４１】
参考のため、図８はアプリケーションクライアント（Ｃ），アプリケーションサーバ（Ｓ）、及びキー配信センタ（ＫＤＣ）を含む具体的なケルベロスメッセージシーケンスを示す。ＫＤＣはチケット発行サーバ（ＴＧＳ）及び認証サーバ（ＡＳ）を含む。この具体的実施例では、３つのメッセージ交換ステップが示される。即ち、ａ）シーケンスのステップＳ１はオーセンティケータを紹介し、ＴＧＴを取得する（この際、１００で示すように、ＡＳ＿ＲＥＱメッセージは認証サーバ（ＡＳ）に送信され、１１０で示すように、ＡＳ＿ＲＥＰメッセージが認証サーバから送信される）。ｂ）シーケンスのステップＳ２はＴＧＴを紹介し、チケットを取得する（この際、１２０で示されるように、ＴＧＳ＿ＲＥＱメッセージがチケット発行サーバ（ＴＧＳ）に送信され、１３０で示されるように、ＴＧＳ＿ＲＥＰメッセージがＴＧＳサーバから送信される）。
【０１４２】
参考のために、図９はピア、オーセンティケータ及びサーバを含む具体的ＥＡＰメッセージシーケンスを示す。図では、メッセージ２００はサーバからのＥＡＰリクエストを示し、メッセージ２０１はピアからのＥＡＰレスポンスを示し、メッセージ２０２はサーバからのＥＡＰサクセスメッセージを示し、メッセージ２０３はサーバからのＭＳＫメッセージを示し、２０４は確立された安全関連性（下位層）を示す。ここでは、オーセンティケータはピアへネットワークアクセスサービスを提供する。幾つかの実施形態では、オーセンティケータ及びサーバは同じ装置で実行できるが、幾つかの実施形態では、オーセンティケータ及びサーバは分離された装置で実行できる。分離された装置で実行されるとき、オーセンティケータはピアとサーバとのＥＡＰメッセージの「パススルー」転送者として機能する。
【先行技術文献】
【非特許文献】
【０１４３】
【非特許文献１】Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, March 1997 (Referred to herein as [RFC2119]).
【非特許文献２】Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, “Extensible Authentication Protocol (EAP),” RFC 3748, June 2004 (Referred to herein as [RFC3748]).
【非特許文献３】Aboba, B., “Extensible Authentication Protocol (EAP) Key Management Framework”, draft-ietf-eap-keying-16 (work in progress), January 2007 (Referred to herein as [I-D.ietf-eap-keying]); and [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 （ここでは［ｓｈａ２５６］と称する）．
【非特許文献８】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 （ここでは［ＲＦＣ４３０６］と称する）．
【非特許文献１０】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 （ここでは［ＲＦＣ４１２０］と称する）．
【非特許文献１３】Zhu, L. and B. Tung, “Public Key Cryptography for Initial Authentication in Kerberos (PKINIT)”, RFC 4556, June 2006 （ここでは［ＲＦＣ４５５６］と称する）． 各種方式及び方法は知られているが、改良された方式及び方法の必要性がある。
【発明の開示】
【０１４４】
本発明は、上述したシステム及び方法を含む、既存のシステム及び方法を改良する。
【０１４５】
幾つかの好適実施形態によると、サーバ、オーセンティケータ及びモバイルノードの間の安全なキー配信のためにケルベロスを使用するメディア独立ハンドオーバキー管理アーチテクチャが記載されている。このアーチテクチャを用いて、好適実施形態では、キー配信のための信号伝達は再キーイングに基づいており、初期ネットワークアクセス認証と同様なＥＡＰ（Extensible Authentication Protocol（拡張認証プロトコル））及びＡＡＡ（Authentication（認証），Authorization（許可）及びAccounting（課金））信号伝達を要求する再認証から切り離される。このフレームワークにおいて、モバイルノードはハンドオーバ前に一組のオーセンティケータと通信しないでそれらとのセキュリティ関連付けを動的に確立することを要求するマスタセッションキーを取得することを可能にする。再キー動作を再認証から分離することによって、提案アーチテクチャは事前動作モードに対してより最適化される。それはモバイルノードとターゲットアクセスノードとの間でキー配信を逆にすることによってリアクティブオペレーションモードに対して最適化もし得る。
【０１４６】
幾つかの好適実施形態によると、ハンドオーバ後にチケット配送を採用するリアクティブモードにおいてケルベロス化ハンドオーバキーイングを用いてサーバ、オーセンティケータ及びモバイルノード間の安全キー配信のためのメディア独立ハンドオーバキー管理のためのシステム及び／又は方法はａ）モバイルノードにＡＳ−ＲＥＱをキー配信センタに送信させ、モバイルノードにチケット付与チケット（ＴＧＴ）によってキー配信センタからＡＳ−ＲＥＰを受け取らせること、ｂ）ターゲットオーセンティケータに対するモバイルノードのハンドオーバ後に、ターゲットオーセンティケータにＴＧＳ−ＲＥＱをキー配信センタに送信させ、モバイルノードのためのチケット（Ｔ）を取得するためターゲットオーセンティケータにキー配信センタからＴＧＳ−ＲＥＰを受信させること、及び（ｃ）オーセンティケータにＡＰ−ＲＥＱをモバイルノードに送信させ、モバイルノードを認証するためにモバイルノードにＡＰ−ＲＥＰメッセージをオーセンティケータに送信させることを含む。幾つかの例では、本方法はチケット（Ｔ）を用いてモバイルノードとターゲットオーセンティケータとの間に安全関連性を確立することを含む。幾つかの例では、本方法はステップｂ）の前に、ターゲットオーセンティケータに対するモバイルノードのハンドオーバ後に、モバイルノードにトリガメッセージをターゲットオーセンティケータに送信させることを更に含む。幾つかの例では、本方法はターゲットオーセンティケータが許可のためのハンドオーバ後にＡＡＡ信号伝達無しにアクセス制御を行うようにチケット承諾データに承諾情報を埋め込ませることを更に含む。
【０１４７】
幾つかの他の実施形態によると、サーバ、オーセンティケータ及びモバイルノードの間の安全キー配信のためのメディア独立ハンドオーバキー管理アーチテクチャが設けられる。これはＥＡＰサーバと通信するように構成されるＥＡＰピアを持つモバイルノードを含む。モバイルノードは個別のケルベロスクライアントを有する少なくとも１つのターゲットネットワークに対する少なくとも１つのオーセンティケータと通信するように構成されるケルベロスサーバを更に有する。モバイルノードは少なくとも１つのオーセンティケータを介して少なくとも１つのターゲットネットワークにハンドオーバに関してセキュリティ信号伝達を行うように構成され、ＥＡＰ及びＡＡＡ信号伝達を用いて再認証しないで少なくとも１つのオーセンティケータを介してセキュリティ関連性を動的に確立するためケルベロスを用いてマスタセッションキーを取得するネットワークアクセス認証及びキー管理信号伝達を含む。
【０１４８】
幾つかの他の実施形態によると、サーバ、オーセンティケータ及びモバイルノードの間の安全キー配信のためのメディア独立ハンドオーバキー管理のためのシステム及び／又は方法はａ）ＥＡＰ方法を用いてネットワークアクセス認証証明からブートストラップを介して初期ネットワークアクセス認証中にモバイルノードにキー配信センタの識別及びアプリケーションサーバと共有するシークレットキーを取得させること、及びｂ）ハンドオーバ後にセキュリティを用いて１セットのオーセンティケータによってモバイルノードにセキュリティに関連性を持たせることを含む。幾つかの例では、本方法はモバイルノードにオーセンティケータの個別のケルベロスクライアントと通信するケルベロスサーバを含ませる。
【０１４９】
上記及び／又は発明、態様、種々の実施形態の特徴及び／又は利点は添付図面と関連して次の説明を鑑みて更に理解される。種々実施形態は適用可能である場合異なる態様、特徴及び／利点を含める及び／又は除外できる。更に、種々実施形態は適用可能な場合他の実施形態の１以上の態様又は特徴を組合すことができる。特定の実施形態の態様、特徴及び／又は利点の説明は他の実施形態又は請求の範囲を限定するように解釈されるべきでない。
【図面の簡単な説明】
【０１５０】
【図１】幾つかの実施形態に従った単一の内部方法によってＥＡＰサーバとＥＡＰピアとの間の具体的ＥＡＰ−ＥＸＴメッセージシーケンスを示す図である。
【図２】幾つかの実施形態に従った複数の内部方法によってＥＡＰサーバとＥＡＰピアとの間の具体的ＥＡＰ−ＥＸＴメッセージシーケンスを示す図である。
【図３】（Ａ）は、ＥＡＰ−ＥＸＰに関する幾つかの例示的実施例に従った具体的メッセージフォーマットを示す図である。（Ｂ）は、ＥＡＰ−ＥＸＰに関する幾つかの例示的実施例に従った具体的キャパビリティフィールドを示す図である。（Ｃ）は、ＥＡＰ−ＥＸＰに関する幾つかの例示的実施例に従った具体的ＴＬＶフォーマットを示す図である。
【図４】本発明の幾つかの例示的実施形態に従った具体的メッセージフォーマットを示す図である。
【図５】ＢＫＥ機能の幾つかの具体的実施形態に従ったメッセージシーケンスを示し、クライアント／ピア、サーバ及びＫＤＣ１の間のメッセージシーケンスを示す。
【図６】ＢＫＥ機能の幾つかの具体的実施形態に従ったメッセージシーケンスを示し、クライアント／ピア、サーバ、オーセンティケータ及びＫＤＣ１の間のメッセージシーケンスを示す。
【図７】ＢＫＥ機能を採用し、更にＴＧＳ−ＲＥＱ／ＲＥＰを含む幾つかの具体的実施形態に従った他のメッセージシーケンスである。
【図８】基準のためのケルベロスメッセージシーケンスを示す背景図である。
【図９】基準のためのＥＡＰメッセージシーケンスを示す背景図である。
【図１０Ａ】本発明の幾つかの実施形態に従ったケルベロス化ハンドオーバキーイングメッセージシーケンスを示す図である。
【図１０Ｂ】リアクティブオペレーションのために最適化されている、本発明の幾つかの実施形態に従ったケルベロス化ハンドオーバキーイングメッセージシーケンスを示す図である。
【図１１】ＥＡＰ機能及びパススルーオーセンティケーションを持つＥＡＰを示す図である。
【図１２】図８に示されるものと同様のケルベロスメッセージシーケンスを示す背景図である。
【図１３】リアクティブモードにおいて、図１０（Ａ）に示されるものと同様な、幾つかの実施形態に従ったケルベロスハンドオーバキーイングメッセージシーケンスを示す図である。
【図１４】リアクティブモードにおいて、図１０（Ｂ）に示されるものと同様な、幾つかの実施形態に従ったケルベロスハンドオーバキーイングメッセージシーケンスを示す図である。
【図１５】本発明の幾つかの事前モード及びリアクティブモード実施形態に従った承諾及び課金のためのＡＡＡ相互関係を示すアーチテクチャ図である。
【図１６】ＡＡＡドメインと複数のケルベロスレルムとの間の一例のそう関係を示す概略図である。
【図１７】幾つかの実施形態に従ったケルベロスブートストラップキャパビリティを持つＥＥＡＰ−ＥＸＴメッセージフォーマットを示す図である。
【図１８】幾つかの実施例に従ったケルベロスブートストラップシーケンスを示す図である。
【図１９】幾つかの実施形態に従った装置内で採用し得る幾つかの具体的アーチテクチャコンポーネントを示す図である。
【発明を実施するための形態】
【０１５１】
本発明は多くの異なる形態で実施してもよいが、本開示は本発明の原理の実施例を提供するとして考慮されるべきであり、そのような実施例は本発明をここに説明され及び／又はここに示された好適実施形態に限定されると意図していないとの理解の下に複数の具体的実施形態が説明されている。
【０１５２】
ケルベロス化ハンドオーバキーイング概要
ハンドオーバキーイングのためのケルベロス利用法
本発明の幾つかの好適実施形態によると、ハンドオーバキーイングのためにケルベロス使用法が採用される。その際、ケルベロスは、例えば、ケルベロスアップリケーションサーバを各ネットワーク接着点（point of attachment：ＰｏＡ）（例えば、アクセスポイント、基地局及び／又はアクセスルータ）に配置することによってハンドオーバキー管理に利用可能にすることができる。
【０１５３】
特に、この実施は次の及び／又は他の利点及び利益を達成できる。
【０１５４】
ａ）ＥＡＰ／ＡＡＡを用いた認証信号伝達はケルベロスレルム内でハンドオーバ毎に除外できる。
【０１５５】
ｂ）同じフレームワークは、例えばＦＭＩＰｖ６，ＨＭＩＰｖ６，ＨＭＩＰｖ［theta］，ＨＣＰ認証などに対して任意の層で使用される任意のプロトコルをブートするために適用できる。
【０１５６】
ケルベロス化ハンドオーバキーイングステップ
図１０を参照して、本発明の幾つかの具体的実施形態に従って、ケルベロスハンドオーバキーイングは次のステップを採用できる。
【０１５７】
図１０Ａに示される実施形態では、第１ステップ、ステップ１，は初期接着点（ＰｏＡ）を介して初期ネットワークアクセス認証の時にチケット付与チケット（ＴＧＴ）の取得を含む。この際、ＡＳ−ＲＥＱ／ＡＳ−ＲＥＰ交換はＲＦＣ ４１２０（i.e., Neuman, C., Yu, T., Hartman, S., and K. Raeburn, “The Kerberos Network Authentication Service (V5)”, RFC 4120, July 2005 ここに参照により援用される）に特定されているようにＴＣＰ又はＵＤＰを介して、若しくは（上述したようなＥＡＰからケルベロスをブートする）ＢＫＥを持つＥＡＰ−ＥＸＴを介して使用され及び搬送できる。図示のように、ＡＳ−ＲＥＱは（例えば、モバイル装置又はノード内の）アプリケーションクライアントＣからキー配信センタ（ＫＤＣ）に送信されることになる。
【０１５８】
図１０Ａに示される実施形態において、第２ステップ、ステップ２は候補ＰｏＡ毎にＰｏＡ当たりの事前チケット取得（proactive per-PoA ticket acquisition）を含む。この際、ＴＧＳ−ＲＥＱ／ＴＧＳ−ＲＥＰ交換がＲＦＣ ４１２０において特定されたようなＴＣＰ又はＵＤＰ若しくは上述したようなＥＡＰ−ＥＸＴにわたって使用され、転送される。そのような場合、クライアントＣはそれが引き継がれるかもしれないＰｏＡ毎にチケットを取得する。例えば、図９はクライアントＣが第１接着点ＰｏＡ１を発見し、それに関連するチケットＴ１を取得し、そしてクライアントＣが第２接着点ＰｏＡ２を発見し、それに関連するチケットＴ２を取得する具体的な事例を示している。図示のように、接着点毎に、ＴＧＳ−ＲＥＱはアプリケーションクライアントＣからキー配信センタ（ＫＤＣ）に送信されることになり、ＴＧＳ−ＲＥＰはキー配信センタ（ＫＤＣ）からアプリケーションクライアントＣに送信されることになる。
【０１５９】
図１０Ａに示される実施形態において、第３ステップ、ステップ３、は取得したチケットを用いて目標ＰｏＡ（ｓ）に対する安全関連性を確立することを含む。
【０１６０】
このステップ３では、ＫＲＢ−ＳＡＦＥ又はＫＲＢ−ＰＲＩＶ交換が選択的に後続するＡＰ−ＲＥＱ／ＡＰ−ＲＥＰ交換はＲＦＣ ４１２０において特定されているようにＴＣＰ又はＵＤＰにわたり、若しくはＩＰ接続性がなければリンク層にわたり使用及び配送できる。これらメッセージがリンク層にわたり配送される場合に、それらはａ）ケルベロス交換をサポートするための新たなＥＡＰ認証方法、又はｂ）ケルベロス交換をサポートするための新たなＥＡＰコードを規定することによってＥＡＰメッセージ内に取り込むことができる。そうでなければ、メディア特定情報がＫＲＢ−ＳＡＦＥ又はＫＲＢ−ＰＲＩＶ交換に取り込まれる。
【０１６１】
このステップ３において、安全関連性信号送信の幾らかの部分はハンドオーバ前に積極的に行うことができる。例えば、ＡＰ−ＲＥＱ／ＡＰ−ＲＥＰ交換は候補ＰｏＡｓにおいてセッションキーの記憶個所を作成するためにハンドオーバ前に行うことができる。
【０１６２】
ＰｏＡディスカバリ
上述のようにステップ２においてＰｏＡ当たりのチケットを取得するために、ＰｏＡｓはステップ２においてＰｏＡ当たりのチケットを得ることを見つける必要がある。その際、ＰｏＡディスカバリを実施するために、ＩＥＥＥ ８０２．２１情報サービスが採用できる。Draft Standard for Local and Metropolitan Area Networksと名称付けられた２００７年２月発行のＩ．Ｅ．Ｅ．Ｅ．Ｐ８０２．２１ＴＭ／Ｄ０４．００を参照する。この全体の開示は省略せずに個々に記載されているように参照によって援用される。
【０１６３】
キー寿命
チケットは寿命を有することは知られている。その際、この寿命は（サブ）セッションキー寿命を決定する。ここで、（サブ）セッションキーの寿命はチケット寿命より長くないことが必要である。
【０１６４】
許可
幾つかの実施形態によると、許可情報がチケットに含めることができる。その際、（ＴＧＴｓを含む）チケットの寿命はＡＡＡ許可寿命より長くない必要がある。ここで、オーセンティケータはチケットがそのような許可情報を含むならば許可信号送信のためにＡＡＡ信号伝達を必要としない。そうでなければ、許可のためのＡＡＡ信号伝達は行われるべきである。
【０１６５】
再キーイング
幾つかの好適実施形態によると、リンク層暗号キーの再キーイングはホームＡＡＡサーバに行き着くまでＥＡＰ再認証無しに行うことができる。例えば、これはステップ２において新たなチケットを再発行し、それから上述のようにステップ３を実行することによって達成できる。
【０１６６】
再認証
幾つかのケースでは、認証寿命を延ばす必要があればＥＡＰ再認証が必要となる。幾つかの好適実施形態では、これは新たなＴＧＴを再発行し、それからＰｏＡ当たりのチケットを再発行することによって達成できる。
【０１６７】
ＡＡＡドメイン間オペレーション（Inter-AAA Domain Operation）
ＡＡＡドメイン間オペレーションに関して、ケルベロスはクロスレルム動作を有利に可能にする。更に、１つはＡＡＡドメイン当たりのケルベロスレルム（又は複数のレルム）を形成できる。
【０１６８】
クロスレルム／ドメインオペレーションのために、クライアントはＴＧＴをビジテッドレルム／ドメイン（visited realm/domain）に使用されるそのローカルＡＳから得る必要がある。
【０１６９】
初期エントリ発行
幾つかの好適実施形態によると、初期ＰｏＡはＢＫＥのためのＥＡＰ オーセンティケータとして作用する。幾つかの実施形態では、初期ＰｏＡはＰＭＫを生成するためにＥＡＰ ＭＳＫを用いることができる。これは初期ＰｏＡがケルベロスをサポートしなければ使用されるべきである。幾つかの代替実施例では、初期ＰｏＡは成功したＥＡＰ認証後にステップ３を実行することによってＰＭＫを生成するためにケルベロスチケットを使用できる。この後者の例では、ステップ１だけでなくステップ２もＢＫＥ内で行われる必要がある。更に、成功したＥＡＰ認証自体はこの後者の例において安全関連性をトリガしない。これは初期ＰｏＡがケルベロスをサポートすれば使用されるべきである。
【０１７０】
リアクティブオペレーション（Reactive Operation）のために最適化されるケルベロス化ハンドオーバキーイング
幾つかの代替実施形態では、ケルベロス化ハンドオーバキーイングはリアクティブオペレーションのために最適化されるように変形できる。この際、幾つかの実施形態では、１０Ａを参照した上記のケルベロス化ハンドオーバキーイングステップが変形できる。例えば、幾つかの具体的実施形態では、図１０Ｂに示されるように、下記のステップが採用できる。
【０１７１】
第１ステップ１は初期接着点（ＰｏＡ）を介して初期ネットワークアクセス認証のときにチケット付与チケット（ＴＧＴ）取得を含めることができる。これは図１０Ａを参照した上記通常動作と同じ方法で行うことができる。
【０１７２】
第２ステップ２は目標ＰｏＡに対するＰｏＡ当たりのリアクティブチケット取得及びチケットを用いた目標ＰｏＡに対する安全関連性を含むことができる。この際、モバイルノード（ＭＮ）はトリガメッセージを目標ＰｏＡに送ることができ、又は目標ターゲットはリンク層指標を介してモバイルノードを見つけることができる。リアクティブオペレーション実施形態では、目標ＰｏＡはケルベロスクライアントとして作用し、モバイルノードのためにチケットを得るためＴＧＳ−ＲＥＱ／ＴＧＳ−ＲＥＰ交換を初期化する。目標ＰｏＡがモバイルノードのためのチケットを取得した後、それは（チケット導入のための）モバイルノードによってＡＰ−ＲＥＱ／ＡＰ−ＲＥＰ交換を初期化し、次いで（メデイア特定情報交換のための）ＫＲＢ−ＳＡＦＥ又はＫＲＢ−ＰＲＩＶ交換を初期化する、
幾つかの実施形態に関する追加の検討
このセクションはサーバ、オーセンティケータ及びモバイルノード間の安全キー配信のためケルベロスを使用するメディア独立ハンドオーバキー管理の具体的実施形態を更に説明する。このアーチテクチャに関して、キー配信のための信号伝達は再キーイングに基づいており、初期ネットワークアクセス認証と同様なＥＡＰ（拡張認証プロトコル）及びＡＡＡ（認証、許可及び課金）信号伝達を必要とする再認証から切り離される。このフレームワークでは、モバイルノードはハンドオーバ前に一組のオーセンティケータと通信しないでそれらとの安全関連性を動的に確立するために必要なマスタセッションキーを得ることができる。再認証から再キー動作を分離することによって、提案のアーチテクチャは事前動作モードに対してより最適化される。それはまたモバイルノードと目標アクセスノードとの間のキー配信役割を逆にすることによってリアクティブオペレーションモードのために最適化できる。このセクションはまたこの現アーチテクチャがどのように（例えば、ＩＥＥＥ ８０２．１１及び８０２．１６を含む）既存のリンク層技術に適用でき、複数のＡＡＡドメインにわたることを示している。このセクションはまたどのようにケルベロスがＥＡＰメソッドを用いて初期アクセス認証からブートできるかを説明している。
【０１７３】
１．序論
無線ネットワーク技術は多くの異なるリンク層技術にわたりシームレスオーバヘッドを可能にするために発展している。例えば、Ｉ．Ｅ．Ｅ．Ｅ．８０２．２１（下記文献１を参照）はリンク層と上位層プロトコルに対する統一的インターフェースによってメディア独立ハンドオーバ（ＭＩＨ）関数を定義している。この関数は幾つかのサービスをモビリティ管理エンティティに提供し、これらサービスを届けるためのプロトコルをリモートモードで他のＭＩＨ関数に提供することによってハンドオーバを容易にする。ハンドオーバ中の安全信号伝達最適化はシームレスハンドオーバを達成するための重要な要素の一つであるが、それは最近ではＩ．Ｅ．Ｅ．Ｅ．８０２．２１仕様の範囲外である。ハンドオーバ中の安全信号伝達はネットワークアクセス認証及びリンク層暗号化のための次のキー管理信号伝達を含む。ＩＥＴＦ（Internet Engineering Task Force）はＥＡＰ （Extensible Authentication Protocol）（下記文献［２］参照）を定義する。ＥＡＰはＵＤＰ／ＩＰ（例えば、下記文献［６］及び［７］参照）にわたってだけでなくイーサネット（登録商標）、Ｉ．Ｅ．Ｅ．Ｅ．８０２．１１及びＩ．Ｅ．Ｅ．Ｅ．８０２．１６（下記文献［３］［４］［５］参照）のような幾つかのリンク層技術にわたりさまざまな認証方法のサポートによってネットワークアクセス認証のための統一的機構を提供する。上述したように、ＥＡＰメソッドはピア（例えば、モバイルノード）とサーバ（例えば、バックエンド認証サーバ）との間で認証メソッドを実行する２グループ認証プロトコルであり、これに対して、ＥＡＰは図１１に示されるようにオーセンティケータ（例えば、Ｉ．Ｅ．Ｅ．Ｅ．８０２．１１の場合のアクセスポイント）を介してＥＡＰメソッドを搬送するためのコンテナ、即ちパススルーオーセンティケータを持つＥＡＰに過ぎない。
【０１７４】
ＥＡＰはネットワークアクセス認証のためのメディア独立機構を提供するが、その基本設計はピアが特定のＥＡＰメソッドを除いてハンドオーバにより１つのオーセンティケータから他のオーセンティケータに変更するときその信号伝達を最適化することを十分考慮していなかった。特定ＥＡＰメソッドはこの問題を扱うためにセッション回収を用いてエンハンスメントを与えることによってこの問題を扱う（例えば下記文献［８］参照）。しかしながら、そのようなエンハンスメントは他のＥＡＰメソッドが初期ネットワークアクセス認証に使用されるとき利用できない。
【０１７５】
最近、ハンドオーバ用ＥＡＰ最適化のための機構及びプロトコルを定義するためＩＥＴＦはＨＯＫＥＹ（ハンドオーバキーイング）ワーキンググループを着手した（例えば、下記文献［９］参照）。ＨＯＫＥＹワーキンググループは３つの要素、例えば低待ち時間再認証（又はＨＯＫＥＹ再認証）、ハンドオーバキー管理及び事前認証を定義している。ＨＯＫＥＹ再認証は前回のＥＡＰセッションによって生成されたキーイングマテリアルを利用してメッセージ往復を最小限にするためにＥＡＰに拡張を定義する。ハンドオーバキー管理はサーバからオーセンティケータへのキー配信機構だけでなく複数のオーセンティケータに及ぶ新たなキー階層を定義する。事前認証はピアがサービングアクセスネットワークから候補目標オーセンティケータに対するＥＡＰを実行する事前ハンドオーバ最適化技術である（例えば、下記文献［１０］参照）。
【０１７６】
しかしながら、ＨＯＫＥＹ要素に関する２つの問題がある。第１に、ＨＯＫＥＹ再認証はピアにサーバと通信することをなおも要求する。このサーバは家に在住する又はビジタオペレータネットワークに属し、ピアの場所から物理的に離れている可能性のあるＡＡＡサーバと通常同じ場所にいる。（注：ビジタオペレータネットワークのＡＡＡサーバはオペレータのサブスクライバのためのホームＡＡＡサーバとしても寄与する。）故に、ＨＯＫＥＹ再認証にがリアルタイムアプリケーションの性能に影響しない程度にハンドオーバ待ち時間を減少するのは困難である。第２に、ＨＯＫＥＹ事前認証はモバイルノードの動きの正確な予想を必要とする。しかしながら、隣接ネットワークに多くの候補オーセンティケータが存在するとき動き予測は困難である。
【０１７７】
上述したように、好適実施形態は、とりわけ、ＨＯＫＥＹに関する問題を扱うためにケルベロスを用いるハンドオーバキー管理のためのケルベロスハンドオーバキーイングと呼ばれる新たなアーチテクチャを確立する（例えば、下記文献［１１］参照）。
【０１７８】
好適実施形態では、ケルベロスハンドオーバキーイング（ＫＨＫ）は次の特徴を提供する。即ち、ａ）ＫＨＫはモバイルノードが積極的にｐｅｒ−オーセンティケータキーを取得している限り認証及び許可のためにポストハンドオーバＡＡＡ信号伝達を必要としなく、ｂ）ポストハンドオーバ信号伝達待ち時間は下位層安全関連プロトコルのケルベロスチケット導入及び実行のためピアとオーセンティケータとの若干のメッセージ交換に基づいてアクセスネットワーク内での伝搬遅延の程度まで減少されることが予想され、ｃ）ＫＨＫは各オーセンティケータがハンドオーバ前にモバイルノードのキーを記憶する必要がないので事前キーイングオペレーションのための必要なキーキャッシュのサイズを減少できる。
【０１７９】
ネットワークアクセス認証及びキー管理のためにケルベロスを使用する既存ワークＥＡＰ−ＧＳＳ（下記文献［１２］参照）がある。ワークは最初Ｉ．Ｅ．Ｅ．Ｅ．８０２．１１ｉの候補として考えられていた。しかしながら、ＫＨＫとは異なり、ワークはハンドオーバ最適化を考慮もしなく、任意のＥＡＰメソッドが初期ネットワークアクセス認証のために使用されるのを可能にしない。
【０１８０】
２．ケルベロスの追加的概略
上記の検討に加えて、ケルベロス（下記文献［１０］参照）は対称的キーに基づく３グループ認証及びキー管理プロトコルである。ケルベロスに３つの基本構成がある。即ち、クライアント、サーバ及びキー配信センタ（ＫＤＣ）がある。更に、ＫＤＣは２つの特別なサーバ、即ち、認証サーバ（ＡＳ）及びチケット許可サーバ（ＴＧＳ）を提供する。そのような事例では、各クライアント及びサーバは秘密キーに基づいてＫＤＣとの事前に確立された信頼関係を持つことが仮定とされる。ケルベロスにおいて、セッションを安全に確立するためクライアント及びサーバによって使用されるセッションキーはＫＤＣによって生成され、クライアントに配信される。それから、クライアントは「チケット」を用いてセッションをサーバに配信し、又はクライアントが自らの証明に役立てるためにＫＤＣによって生成される記録をサーバに配信する。チケットはクライアントの識別、セッションキー、タイムスタンプ及び他の情報を含み、（チケットバージョン番号、領域及びサーバ名を除く）全てのそのような情報がＫＤＣによってだけ共有されるサーバ秘密キーを用いて暗号化される。ケルベロスプロトコルは初期交換が一度だけ行われる場合に３つの交換を含む。ケルベロスシーケンスとして表記された図１２はケルベロスの代表的プロトコルシーケンスを示す。
【０１８１】
図１２に示すように、初期交換（ＡＳ−ＲＥＱ／ＡＳ−ＲＥＰ交換）において、クライアントはチケット付与チケット（ＴＧＴ）、又は他のチケットをＡＳから生成するために使用される特別のチケットを要求する。ＡＳはＴＳＧ用セッションキー（ＴＳＧセッションキー）を含むＴＧＴを生成し、クライアントとだけ共有される秘密キーによって暗号化されるＴＳＧセッションキーのコピーと共にＴＧＴをクライアントに送る。
【０１８２】
第２交換、ＴＧＳ−ＲＥＱ／ＴＧＳ−ＲＥＰ交換では、クライアントは同じＴＧＳセッションキーを保有することをＴＳＧが証明できるようにＴＧＳセッションキーを用いて作られる証明と共にクライアントはサーバ識別及びＴＧＴをＴＧＳに送る。証明の確認が成功した後、ＴＧＳはサーバ用セッションキーを含むチケットを生成し、そのチケット及びクライアントとだけ共有される秘密キーによって暗号化されるセッションキーのコピーをクライアントに送る。
【０１８３】
第３交換、ＡＰ−ＲＥＱ／ＡＰ−ＲＥＰ交換において、クライアントがセッションキーを保有することをサーバが証明できるようにクライアントはセッションキーを用いてクライアントによって計算されたメッセージ認証コードと共に、第２交換に含まれるチケットを送る。ＡＰ−ＲＥＰメッセージはクライアントがサーバを認証する必要がなければ省略できる。信用の確認が成功した後、クライアント及びサーバはこれらのアプリケーションプロトコルを保護するためにセッションキーを用いることができる。
【０１８４】
３．ケルベロス化ハンドオーバキーイング（ＫＨＫ）。
【０１８５】
好適実施形態によると、ケルベロスハンドオーバキーイング（ＫＨＫ）が採用される。ここでは、モバイルノード及びオーセンティケータ（例えば、アクセスポイント又は基地局）がクライアント又はケルベロスのサーバとして作用する。
【０１８６】
これに関して、クライアント及びサーバの役割はチケットがオーセンティケータに送付されるときのタイミングに応じて逆転される。幾つかの実施形態によると、オーセンティケータへのチケット送付がハンドオーバ前に発生する事前モードが採用される。他方、実施形態によると、オーセンティケータへのチケット送付がハンドオーバ後に起きるリアクティブモードが採用される。
【０１８７】
事前モードはモバイルノードがハンドオーバ後にＫＤＣと通信することを必要としないので事前モード実施形態はリアクティブモード実施形態よりも最適化される。そのような事例では、ハンドオーバ後の信号伝達待ち時間が、ある実施形態では、Ｉ．Ｅ．Ｅ．Ｅ．８０２．１１ｉ ４−方向ハンドシェイク（Ｉ．Ｅ．Ｅ．Ｅ．８０２．１１ｉ 4-way handshake）（下記文献［４］参照）のためのものに類似し、ある例では２０ｍｓｅｃ以下であるとして知られている（下記文献［１３］参照）。
【０１８８】
好適実施形態によって、ＫＨＫアーチテクチャは事前モードにおいてさえ、ハンドオーバ前にモバイルノードのために任意の状態を作ることをオーセンティケータに要求しない。好適実施形態では、最初に、モバイルノードはＫＤＣの識別及びセクション４において以下に記載されているようにブートストラッピング機構を用いて初期ネットワークアクセス認証中にＡＳと共有する秘密キーを取得する。初期化後に、上記のセクション２で説明されているケルベロスの３つのステップが実行される。３つのステップは事前及びリアクティブモードにおいて異なって実行される。これらの違いの詳細は３．１及び３．２に説明されている。
【０１８９】
３．１事前モード
このセクションでは、事前モードはＫＨＫ事前モードと表記された図１３を参照して説明する。最初に、モバイルノード（ＭＮ）はＴＧＴを取得するためにＫＤＣでＡＳ−ＲＥＱ／ＡＳ−ＲＥＰ交換を実行する。ＭＮがセクション３．４で説明されているようにオーセンティケータ発見機構を用いて１以上のオーセンティケータ（例えば、事象Ｄ１，Ｄ２）を見つけると、それは発見されたオーセンティケータ（例えば、Ａ１及びＡ２）ごとにチケットを得るためにＫＤＣによってＴＧＳ−ＲＥＱ／ＴＧＳ−ＲＥＰ交換を実行する。ＭＮが発見したオーセンティケータの１つ（例えば、事象Ｈ１）に対してハンドオーバを作成すると、それはオーセンティケータでＡＰ−ＲＥＱ／ＡＰ−ＲＥＰ交換を実行する（ＡＰ−ＲＥＰメッセージは選択的である）。ＭＮが異なるオーセンティケータ（例えば、事象Ｈ２）に対して他のハンドオーバを作成すると、それはオーセンティケータによってＡＰ−ＲＥＱ／ＡＰ−ＲＥＰ交換を実行する。この場合、モバイルノード及び目標オーセンティケータはクライアント及びケルベロスのサーバとしてそれぞれ作用する。
【０１９０】
ＡＰ−ＲＥＱ／ＡＰ−ＲＥＰ交換の後に、１以上の追加ＫＲＢ−ＳＡＦＥメッセージ又はリンク層特定ＳＡＰ（Secure Association Protocol（安全関連性プロトコル））メッセージがモバイルノードとオーセンティケータとのリンク層安全関連性を確立するためにモバイルノードと目標オーセンティケータとの間で交換される。これらメッセージはリンク層暗号組パラメータのようなリンク層特定パラメータを有する。ＫＲＢ−ＳＡＦＥメッセージの使用によってアーチテクチャはリンク層技術から独立できる。そして、各リンク層技術はＫＲＢ−ＳＡＦＥに保有されるべきリンク層特定パラメータのフォーマット及びセマンティックスだけでなくモバイルノードとオーセンティケータとの間にケルベロストランスポートを定義することを必要とするに過ぎない。ＩＥＥＥ ８０２．１１の事例では、リンク層認証フレームがモバイルノードとオーセンティケータとの間のケルベロストランスポートとして使用でき、８０２．１１ｉ ４−方向ハンドシェイクはＫＲＢ−ＳＡＦＥメッセージの代わりにＳＡＰとして使用できる。同様に、ＩＥＥＥ ８０２．１６の事例では、新たなＰＫＭ（Privacy Key Management）メッセージタイプが移動局と基地局との間にケルベロスメッセージを搬送するよう定義でき、ＰＫＭ ３−方向ハンドシェイクがＫＲＢ−ＳＡＦＥメッセージの代わりにＳＡＰとして使用できる。これらの両事例では、リンク層仕様に変更を加える必要がある。
【０１９１】
３．２リアクティブモード
このセクションでは、リアクティブモードがＫＨＫリアクティブモードとして表記された図１４を参照して説明する。
【０１９２】
まず、モバイルノード（ＭＮ）は事前モードと同じ方法で、ＴＧＴを得るためＫＤＣによってＡＳ−ＲＥＱ／ＡＳ−ＲＥＰ交換を実行する。
【０１９３】
しかしながら、リアクティブモードでは、モバイルノード及び目標オーセンティケータのケルベロスの役割が逆転する、即ち、モバイルノードと目標オーセンティケータはサーバとクライアントとしてそれぞれ作用する。好ましくは、目標オーセンティケータに対するハンドオーバの後に、モバイルノードは最初にトリガメッセージを目標オーセンティケータに送る。それから、目標オーセンティケータはモバイルノード用チケットを取得するためにＫＤＣによってＴＧＳ−ＲＥＱ／ＴＧＳ−ＲＥＰ交換を実行し、その後、モバイルノードによってＡＰ−ＲＥＱ／ＡＰ−ＲＥＰ交換を実行する（ＡＰ−ＲＥＰメッセージはＫＲＢ安全又はＳＡＰ交換前にモバイルノード（ＭＮ）を認証するために必須である）。
【０１９４】
ＡＰ−ＲＥＱ／ＡＰ−ＲＥＰ交換後に、１以上の追加ＫＲＢ−ＳＡＦＥメッセージ又はリンク層特定ＳＡＰ（Secure Association Protocol）メッセージがモバイルノードとオーセンティケータとの間にリンク層安全関連性を確立するためにモバイルノードと目標オーセンティケータとの間で交換される。この交換は事前モードと同様の方法で行うことができる。
【０１９５】
トリガメッセージが保護されていなければ、資源消費ＤｏＳ（Denial of Service）攻撃がリアクティブモードに対して可能性がある。従って、追加機構がそのようなＤｏＳ攻撃を緩和するために採用できる。
【０１９６】
リアクティブモードのためのハンドオーバ後の信号伝達待ち時間は実質的に事前モードの待ち時間＋オーセンティケータとＫＤＣ間の１往復になることが予想される。故に、リアクティブモードのためのリアルタイムアップリケーションに対するハンドオーバ性能はＫＤＣの位置に依存する。以下のセクション３．６に説明されるように、ＫＤＣはクロスレルムオペレーションを用いてオーセンティケータに近い位置に配置できる。しかしながら、ハンドオーバ性能はＫＤＣの位置に依存しないので事前モードを使用することがリアクティブモードにわたり多くの環境においてより望ましい。
【０１９７】
３．３キー寿命
ケルベロスチケットはキー寿命を含むので、異機種リンク層技術（heterogeneous link-layer technologies）に対するキー管理に柔軟性を得るために、（限定されないが）リンク層タイプに依存する異なるオーセンティケータに対して異なるキー寿命（又はキー寿命が認証時間と同じであれば異なる許可寿命（authorization lifetimes））を割り当てることが可能である。
【０１９８】
３．４ オーセンティケータディスカバリ
ＫＨＫの事前モードにおいて、モバイルノードは隣接ネットワークにおいてオーセンティケータを見つける必要がある。オーセンティケータディスカバリ機構は少なくとも次の情報を得るために必要である。
【０１９９】
・ＫＤＣからオーセンティケータのためのチケットを得るときにモバイルノードが認識できるようにオーセンティケータの識別の発見。単一のオーセンティケータ識別は複数のネットワーク接着点（例えば、アクセス点、基地局及び／又はアクセスルータ）に対して使用できることを留意する。
【０２００】
・モバイルノードがＡＰ−ＲＥＱ／ＡＰ−ＲＥＰ交換に対してオーセンティケータと通信できるようにオーセンティケータのアドレスの発見。アドレスはリンク層アドレス又はＩＰアドレスでできる。単一オーセンティケータ識別は複数のネットワーク接着点のために使用されるとき、オーセンティケータ識別は複数のアドレスと関連する。
【０２０１】
ＩＥＥＥ ８０２．１１ｒ（例えば、下記文献［１４］参照）において、ビーコンフレーム（Beacon frame）において通知されたＲ０ＫＨ−ＩＤ及びＢＳＳＩＤはオーセンティケータの識別及びアドレスにそれぞれ対応するが、それはＩＥＥＥ ８０２．１１リンク層だけに適用できる。他方、メディア独立オーセンティケータディスカバリ機構（media-independent authenticator discovery mechanism）は、例えば、上述した全ての情報を提供するために望ましい。例えば、ＩＥＥＥ ８０２．２１、情報サービス（例えば、下記文献［１］参照）を参照する。ＩＥＥＥ ８０２．２１情報サービスはハンドオーバ意思決定プロセス（handover decision-making process）を容易にするために隣接ネットワークに関する種々の情報を提供し、任意のメディアを徹底的に調査するために設計されるのでＩＥＥＥ ８０２．２１情報サービスはそのような機構を提供できる。
【０２０２】
３．５ 許可及び課金
ケルベロスは許可情報がＫＤＣ発行許可データ要素によってカプセル化されるときチケットの許可データに埋め込むことを可能にする。ＫＤＣによって発行される許可証明がアクセス制御を行うためオーセンティケータによって必要とされる全許可情報を含むならば、認証のためだけでなく許可のためにもハンドオーバ後にＡＡＡ信号伝達を廃止することを可能になる。
【０２０３】
ケルベロス化ハンドオーバキーイングに使用される好適な許可モデルは次のように説明される。
【０２０４】
・ＫＤＣを実施するノードは許可目的のためにＡＡＡサーバと通信するためＡＡＡクライアントも実施する。
【０２０５】
・ＫＤＣがケルベロスクライアント（即ち、事前モードのモバイルノード又はリアクティブモードのオーセンティケータ）からＴＧＳ−ＲＥＱメッセージを受信すると、それはケルベロスクライアントに対する許可情報をＡＡＡクライアントに要請する。ＡＡＡクライアントはＡＡＡプロトコルを用いてＡＡＡサーバから許可情報を取得し、取得した情報をＫＤＣに戻す。
【０２０６】
・ＫＤＣはＴＧＳ−ＲＥＰメッセージに含まれるべきチケットの許可データフィールドに許可情報を埋め込む。
【０２０７】
好適実施形態では、許可モデルは次の２つの要求を有する。第１に、許可証明のフォーマット及びセマンティクスは相互接続のために標準化される。第２に、リアクティブモードの事例では、許可情報はリアクティブモードでのケルベロスクライアント（例えば、オーセンティケータ）がモバイルノードに使用されるべき許可情報を取得できるようにＴＧＳ−ＲＥＰメッセージの暗号化データ部分に取り込まれる。
【０２０８】
課金は既存のリンク層技術において行われるようにオーセンティケータに行われ、例えば、オーセンティケータを実施し、課金のためのＡＡＡクライアントをも実施するノードで行われる。課金記録を妥当な許可セッションと関連するため、好ましくは許可セッション識別子は許可証明に含まれる。幾つかの実施形態に従った許可及び課金のためのＡＡＡ相互作用が図１５に示されている。許可及び課金に関して事前モードとリアクティブモード間の注目すべき差はＫＤＣが事前モードでモバイルノードを介してオーセンティケータに許可情報を好ましくは間接的に通過させ、これに対してＫＤＣがリアクティブモードにおいてオーセンティケータに許可情報を好ましくは直接的に通過させることである。
【０２０９】
オーセンティケータノードのＡＡＡクライアントも初期ネットワークアクセスのための認証機能性を持っている。
【０２１０】
３．６ ＡＡＡドメインへのケルベロスレルムのマッピング
上述のように、ケルベロスは組織的境界にわたり動作するように設計されている。例えば、１組織のクライアントは他の組織のサーバに認証され得る。この際、ケルベロスサーバを実施する各組織の願望は自らの「レルム」を確立する。クライアントは登録されているレルム名はローカルレルムと呼ばれる。
【０２１１】
「インタレルム」キーを確立することによって、２つのレルムのアドミニストレイタはローカルレルムで認証されたクライアントが他のレルムのサーバに対してその識別を立証することを可能にする。この際、レルム間キーの交換が各レルムのチケット許可サービスを他のレルムの主体として登録する。それから、クライアントはリモートレルムチケット許可サービスのためのＴＧＴをそのクライアントローカルレルムから取得できる。そのＴＧＴが使用されると、リモートチケット許可サービスはＴＧＴを解読するため（自己の標準ＴＧＳキーとは通常異なる）レルム間キーを使用する。好ましくは、リモートチケット許可サービスによって発行されるキーはクライアントが他の領域から認証されたことをエンドサービスに示すことになる。
【０２１２】
一般的に、ケルベロルレルム及びＡＡＡドメインは独立している。しかしながら、単純化した具体例の代わりに、我々は典型的な実施面で妥当なモデルを導入する。ここで、我々はケルベロス化ハンドオーバキーイングがＤＮＳドメイン名をケルベロスレルム名及びＡＡＡドメイン名として使用するものとする。
【０２１３】
Ｄ（ｎ）はＤＮＳメイン名がｎであるＡＡＡドメインを示すものとする。Ｒｎはレルム名がそれらの添え字ｎを含むケルベロスレルムのセットであるとする。ＫＨＫにおけるＡＡＡドメインとケルベロスレルムとの関係は次のように表される。
【０２１４】
Ｄ（ｎ）＝Ｒｎ
この式はＡＡＡドメインがケルベロスレルムのセットを有すること及び特定のケルベロスレルムがケルベロスレルム名及びＡＡＡドメイン名を用いて特定のＡＡＡドメインに属するか否かをモバイルノードが伝えることができることを表している。具体的ＡＡＡドメインと複数の具体的ケルベロスレルムとの間のマッピングを示す具体的実施例がＡＡＡドメインとケルベロスレルムとの例示的関係を表記した図１６に示されている。モバイルノードにできるだけ物理的に近づくような位置にＫＤＣを配置することによって信号伝達待ち時間を減じるだけでなくＫＨＫが拡張可能であるために単一ＡＡＡドメイン内に複数のレルムを定義することが望ましい。
【０２１５】
好適実施形態では、ＡＡＡドメインにわたってシームレスハンドオーバをサポートするために、互いにローミング関係にある２つのＡＡＡドメイン間にケルベロスレルム間キーが予め確立されることが望ましい。モバイルノードがＡＡＡドメインを横切ってサービングオーセンティケータから目標オーセンティケータに移動すると、それはホームＡＡＡドメインのローカルＫＤＣに接触することによってビジテッドＡＡＡドメインのリモートＫＤＣに有効なクロスレルムＴＧＴを取得する。好ましくは、ローカルとリモートレルム間に１以上の中間領域があれば、モバイルノードが認証路に沿ってＴＧＴ取得手順を繰り返す。ローカルＫＤＣによって生成される許可証明はリモートＫＤＣに使用されたクロスレルムＴＧＴに保存される必要がある。
【０２１６】
２つのＡＡＡドメインが一般的にはＤＮＳドメイン階層の異なる分岐に属するので、認証経路の決定プロセスが重要である。この場合、認証経路は下記文献［１５］に明記されているように、ＫＤＣｓの照会を用いて動的に決定し得る。更に、下記文献［１６］に記載されているように、ＴＧＴ取得手順の繰り返しを排除するより最適化された機構も存在する。
【０２１７】
ケルベロスのクロスレルムオペレーションも同じＡＡＡドメイン内のハンドオーバに対して可能である。モバイルノードが同じドメイン内のケルベロスレルムを横切ってサービングオーセンティケータから目標オーセンティケータに移動するとき、それはサービングＫＤＣ（即ち、サービングオーセンティケータのためのＫＤＣ）に接触することによって目標ＫＤＣ（即ち、目標オーセンティケータのためのＫＤＣ）に有効なcross-realm ＴＧＴを取得する。同じＡＡＡドメイン内の２つのＫＤＣ間に１以上の中間レルムが存在する場合、好ましくはモバイルノードは認証経路に沿ったＴＧＴ取得手順を繰り返す。サービングＫＤＣによって作成される認証証明は目標ＫＤＣに使用されるクロスレルムＴＧＴに保存される必要がある。認証経路はＤＮＳドメイン階層に基づいて構成できる。このＤＮＳドメイン階層はインタードメインの事例よりも容易な認証経路を横切る。
【０２１８】
リアクティブモードでは、クロスレルムオペレーションに必要なＴＧＴ取得手順の繰り返しがモバイルノードの代わりに目標オーセンティケータによって行われる。これはモバイルノードとオーセンティケータとの間のリンクにわたりケルベロスメッセージ交換を効果的に減少する。
【０２１９】
４．ＥＡＰからのケルベロスブートストラッピング
複数のＡＡＡドメイン間のローミングをサポートするために、機構はローカルＫＤＣの主要名及びそのためにできるだけ使用される秘密キーを動的に構成するために定義される。この目的のために、機構は、上述された及び以下の文献［１７］で検討された新たなＥＡＰメソッドであるＥＡＰ−ＥＸＴを用いてネットワークアクセス認証証明からケルベロスをブートストラップすることを提示している。上述したように、ＥＡＰ−ＥＸＴは任意のＥＡＰ認証メソッドをカプセル化するトンネルメソッドであり、新たに定義された機能性が可能とされるキャパビリティネゴシエーションを提供する。既存のＥＡＰメソッドにどのような変更もしないでそれらをなおも用いながら利用できる新たな機能性を作るのでＥＡＰ−ＥＸＴは既存のＥＡＰ認証メソッドに対して下位互換性を与える。ＥＡＰ−ＥＸＴは現在若干のキャパビリティ、例えば、チャネル結合及び再認証を定義する。しかしながら、これに関連して、新たなキャパビリティがケルベロスとしてＥＡＰ−ＥＸＴに加えられる。ケルベロスブートストラッピングのために付加的キャパビリティビット（例えば、‘Ｋ’ビット）を持つＥＡＰ−ＥＸＴメッセージフォーマットがケルベロスブートストラッピングキャパビリティを持つＥＡＰ−ＥＸＴメッセージフォーマットと表記された図１７に示されている。
【０２２０】
好ましくは、ピア及びサーバの両方が内部ＥＡＰ認証メソッドから転送されるキーを用いて保護された完全性である最終ＥＡＰ−ＥＸＴメッセージ交換に‘Ｋ’ビットを設定すると、ピア及びサーバはケルベロスをブートする。次の情報、即ちａ）モバイルノードとローカルＫＤＣとで共有される秘密キー（ＥＡＰ−ＫＲＢ−ＫＥＹ）の長さ及び寿命、ｂ）ローカルＫＤＣの主要名及びレルム並びにｃ）ローカルＫＤＣのＩＰアドレスがケルベロスをブートするために必要とされ、‘Ｋ’ビットが設定された最終ＥＡＰ−ＥＸＴ要求メッセージのケルベロスブート（ＫＲＢ−ＢＯＯＴ）ＴＬＶ（Type-Length-Value）で搬送される。
【０２２１】
ＥＡＰ−ＫＲＢ−ＫＥＹは次のようにＥＭＳＫ（EAP Master Session Key）からＵＳＲＫ（Usage Specific Root Key） （例えば、下記文献［１８］参照）として得られる。但し、ＫＤＦは文献［１８］に定義されたキー導出関数を示し、ｌｅｎｇｔｈは取得キーの長さを示す。
【０２２２】
ＥＡＰ−ＫＲＢ−ＫＥＹ＝ＫＤＦ（ＥＭＳＫ，“EAP-EXT-Kerberos-Boot-Key”, length）
ＥＡＰサーバもケルベロスブートストラッピングシーケンスとして表記された図８に示されるようにＫＲＢ−ＢＯＯＴ ＴＬＶに搬送された情報をローカルＫＤＣにインストールする。但し、「メソッド」はＥＡＰメソッドペイロードを保有するメソッドＴＬＶを示し、ＡＵＴＨは完全保護データを保有するＡＵＴＨ ＴＬＶを示す。
【０２２３】
ケルベロスブートストラッピング手順を簡単化するために、最も好ましくは、ＥＡＰサーバ及びローカルＫＤＣはＥＡＰサーバ及びローカルＫＤＣに対して同じ識別子を用いて同じノードにおいて実行される。そうでなければ、秘密キーを秘密に搬送するために３グループキー配信プロトコルがＥＡＰピア、ＥＡＰサーバ及びローカルＫＤＣの間でキー配信を必要とされることになる。
【０２２４】
５．結末注記
上記セクションは複数の問題を扱うためケルベロスを用いて新たなメディア独立ハンドオーバキー管理アーチテクチャを説明し、また、アーチテクチャがどのように複数のＡＡＡドメインにわたり働くかを説明し、かつケルベロスがＥＡＰメソッドを用いてどのように初期アクセス認証からブートし得るのかを説明している。ＫＨＫ手順を実施するときに、ケルベロスプロトコル、ケルベロスブートストラッピング及びケルベロスのリンク層搬送に対する変更を含めて、ＫＨＫに必要な一連のプロトコルを定義することが、例えば、Ｉ．Ｅ．Ｔ．Ｆ．及びＩ．Ｅ．Ｅ．Ｅ．８０２のような標準体には望ましくなる。更に、セクション４で説明したような初期ネットワークアクセス認証からのブートストラッピングはＫＨＫをブートするだけでなくＳＳＯ（Single-Sign On）のような多くの他のアプリケーション対するセキュリティをもブートすることを可能にする。
【０２２５】
文献
下記の背景文献の全開示は参照としてここに援用される。
【０２２６】
［１］ “Draft IEEE Standard for Local and Metropolitan Area Networks: Media Independent Handover Services,” IEEE LAN/MAN Draft IEEE P802.21/D05.00, April 2007.
［２］ B. Aboba, L. Blunk, J. Vollbrecht, J. Carlson and H. Levkowetz, “Extensible Authentication Protocol (EAP),” RFC 3748, June 2004 （上述した文献［ＲＦＣ３７４８］も参照）．
［３］ “IEEE Standard for Local and Metropolitan Area Networks Port-Based Network Access Control,” IEEE Std. 802.1X-2004.
［４］ “IEEE Standard for Local and metropolitan area networks - Specific requirements Part 11: Wireless LAN MAC and PHY specifications Amendment 6: Medium Access control (MAC) Security Enhancements,” IEEE 802.11i-2004.
［５］ “IEEE Standard for Local and metropolitan area network Part 16: Air Interface for Fixed and Mobile Broadband Wireless Access Systems Amendment 2,” IEEE 802.162005 and IEEE Std 802.16-2004/Cor1-2005.
［６］ C. Kaufman, “Internet Key Exchange (IKEv2) Protocol”, December 2005 （上述した文献［ＲＦＣ４３０６］も参照）．
［７］ D. Forsberg, Y. Ohba, B. Patil, H. Tschofenig, and A. Yegin, “Protocol for Carrying Authentication for Network Access (PANA),” Internet-Draft, work in progress, May 2007.
［８］ B. Aboba, D. Simon, “PPP EAP TLS Authentication Protocol”, RFC 2716, October 1999.
［９］ IETF HOKEY WG charter, http://www.ietf.org/html.charters/hokey-charter.html.
［１０］ A. Dutta, T. Zhang, Y. Ohba, K. Taniuchi, and J. Schulzrinne, “MPA assisted Optimized Proactive Handover Scheme,” Mobiquitous 2005.
［１１］ C. Neuman, T. Yu, S. Hartman and K. Raeburn, “The Kerberos Network Authentication Service (V5)”, RFC 4120, July 2005 （上述した文献［ＲＦＣ４１２０］も参照）．
［１２］ B. Aboba, “EAP GSS Authentication Protocol”, http://tools.ietf.org/html/draft-aboba-pppext-eapgss-12, August 2002.
［１３］ R. Lopez, A. Dutta, Y. Ohba, H. Schulzrinne and A. Skarmeta, “Network-Layer Assisted Mechanism for reducing authentication delay during handoff in 802.11 Networks”, to appear in Mobiquitous 2007.
［１４］ “Draft IEEE Standard for Local and metropolitan area networks - Specific requirements Part 11: Wireless LAN MAC and PHY specifications Amendment 2: Fast BSS Transition”, IEEE P802.11r/D6.0, May 2007.
［１５］ K. Raeburn and L. Zhu, “Generating KDC Referrals to Locate Kerberos Realms”, Internet-Draft, work in progress, March 2007.
［１６］ S. Zrelli, Y. Shinoda, S. Sakane, K. Kamada and M. Ishiyama, “XTGSP, the Inter-TGS protocol for cross-realm operations in Kerberos”, Internet-Draft, work in progress, March 2007.
［１７］ Y. Ohba, S. Das and R. Lopez, “An EAP Method for EAP Extension (EAP-EXT)”, Internet-Draft, work in progress, March 2007.
［１８］ J. Salowey, L. Dondeti, V. Narayanan and M. Nakhjiri, “Specification for the Derivation of Usage Specific Root Keys (USRK) from an Extended Master Session Key (EMSK)”, Internet-Draft, work in progress, January 2007.
具体的コンピュータアーチテクチャ
図１９は、幾つかの実施形態において、例えば、ピア、クライアント、サーバ、オーセンティケータ、モバイル装置、アクセスポイントなどのような装置又はエンティティによって行われるプロセスステップ及び通信を実行するために使用できる具体的コンピュータ又は同様な構成を示す。幾つかの実施形態では、そのような装置又はエンティティはバス３２６を介して一組の入出力（Ｉ／Ｏ）装置３２４と通信できる中央処理装置（ＣＰＵ）３２２を含む。Ｉ／Ｏ装置３２４は、例えば、キーパッド及び／又は他の装置を含むことができる。また、装置は（例えば、アンテナなどを使用する）通信用の送信機、受信機及び／又は送受信機を含むことができる。この通信は、この開示に基づく当業者には言うまでもないような妥当な装置機能性を達成するために必要に応じて無線通信、有線通信などを含むことができる。ＣＰＵ３２２はバス３２６を介してコンピュータ読み取り可能媒体（例えば、一般的な揮発性又は不揮発性データ記憶装置）３２８（以後、「メモリ３２８」）と通信できる。ＣＰＵ３２２、Ｉ／Ｏ装置３２４、バス３２６及びメモリ３２８の相互関係は従来知られているものと同様にできる。メモリ３２８は例えば、データ３３０を含むことができる。メモリ３２８はソフトウェア３３８も記憶できる。ソフトウェア３３８はプロセスのステップを実行するための複数のモジュール３４０を含むことができる。一般的プログラミング技術がこれらのモジュールを実施するために使用できる。メモリ３２８は上記及び／又は他のデータファイルも記憶できる。幾つかの実施形態では、ここに記載されている種々の方法はコンピュータシステムを用いてコンピュータプログラム製品を介して実施され得る。この実施は、コンピュータ読み取り可能媒体（例えば、ディスケット、ＣＤ−ＲＯＭ， ＲＯＭ又は同種のもの）に固定され、モデム又は同様なもののようなインターフェース装置を介してコンピュータシステムに送信できる一連のコンピュータ命令を含むことができる。通信媒体は実質的に有形（例えば、通信ライン）及び／又は実質的に無形（例えば、マイクロ波、光、赤外線などを用いた無線媒体）であってもよい。コンピュータ命令は種々のプログラム言語で書くことができ及び／又は半導体装置（例えば、チップ又は回路）、磁気装置、光学装置及び／又は他の記憶装置のような記憶装置に記憶できる。種々の実施形態では、送信は任意の適当な通信技術を使用できる。
【０２２７】
本発明の広い範囲
本明細書では、本発明の具体的実施形態を説明しているが、本発明は、本明細書で説明した様々な好ましい実施形態だけに限定されず、本開示に基づけば当分野の技術者によって理解されるはずの、等価の要素、改変、省略、（様々な実施形態にまたがる態様などの）組合せ、適合及び／又は変更を有するありとあらゆる実施形態を含むものである。特許請求の範囲における限定は、特許請求の範囲で用いられる言葉に基づいて幅広く解釈されるべきであり、本明細書において、又は本出願の出願中において記述される例だけに限定されず、これらの例は、非排他的であると解釈されるべきである。例えば、本開示において、「好ましくは」という用語は、非排他的であり、「それだけに限らないが、好ましくは」を意味する。本開示において、かつ本出願の出願中において、手段プラス機能又はステッププラス機能限定は、特定のクレーム限定について、この限定において、ａ）「〜の手段」又は「〜のステップ」が明記されている、ｂ）対応する機能が明記されている、及びｃ）構造、材料又はこの構造をサポートする動作が記載されていないという条件すべてが存在する場合に限り用いられる。本開示において、かつ本出願の出願中において、「本発明」又は「発明」という用語は、本開示内の１つ又は複数の態様を指すものとして使用され得る。本発明又は発明という言葉は、誤って重要度の識別と解釈されるべきではなく、誤ってすべての態様又は実施形態にわたって適用されるものと解釈されるべきではなく（すなわち、本発明はいくつかの態様及び実施形態を有すると理解されるべきであり）、また、誤って本出願又は特許請求の範囲を限定するものと解釈されるべきではない。本開示において、かつ本出願の出願中において、「実施形態」という用語は、任意の態様、特徴、プロセス又はステップ、これらの任意の組合せ、及び／又はこれらの任意の部分などを記述するのに使用され得る。いくつかの例では、様々な実施形態が重なり合う特徴を含み得る。本開示では、「例えば」を意味する「ｅ．ｇ．」という省略用語が用いられ得る。
【０２２８】
ＥＰＯはＥＰＯ以外の他の官庁から由来するデータ及び情報の正確性に対するどんな義務も受入れない。特に、ＥＰＯはそれらが特定の目的に対して完了し、最新であり、又は適合していることを保証しない。ＷＯ ２００８１０９０３９ （Ａ１）のこの明細書を翻訳する。
【特許請求の範囲】
【請求項１】
ハンドオーバ後にチケット配送を採用するリアクティブモードにおいてケルベロス化ハンドオーバキーイングを用いてサーバ、オーセンティケータ及びモバイルノード間の安全キー配信のためのメディア独立ハンドオーバキー管理方法であって、
ａ）モバイルノードにＡＳ−ＲＥＱをキー配信センタに送信させ、前記モバイルノードにチケット許可チケット（ＴＧＴ）によって前記キー配信センタからＡＳ−ＲＥＰを受信させること、
ｂ）ターゲットオーセンティケータに対する前記モバイルのハンドオーバ後に、モバイルノードに対するチケット（Ｔ）を取得するためターゲットオーセンティケータにＴＧＳ−ＲＥＰをキー配信センタに受信させること、
ｃ）前記オーセンティケータにＡＰ−ＲＥＱを前記モバイルノードに送信させ、前記モバイルノードを認証するため前記モバイルノードにＡＰ−ＲＥＰメッセージを前記オーセンティケータに送信させること、
を含むメディア独立ハンドオーバキー管理方法。
【請求項２】
前記チケット（Ｔ）を用いて前記モバイルノードと前記ターゲットオーセンティケータとの間に安全関連性を確立することを更に含む、請求項１の方法。
【請求項３】
前記ターゲットオーセンティケータに対する前記モバイルノードのハンドオーバ後に、前記モバイルノードにトリガメッセージを前記ターゲットオーセンティケータに送信させることをステップ（ｂ）の前に含む、請求項１の方法。
【請求項４】
前記オーセンティケータと前記キー配信センタとの間の往復信号伝達による前記反動モードでの信号的遅延を減少するためにクロスレルム動作を用いて前記ターゲットオーセンティケータに近い位置に前記キー配信センタを配置することを更に含む、請求項１の方法。
【請求項５】
前記ターゲットオーセンティケータが許可のためのハンドオーバ後にＡＡＡ信号伝達を行わないでアクセス制御を行うようにチケット許可データに許可情報を埋め込ませることを更に含む、請求項１の方法。
【請求項６】
ＴＧＳ−ＲＥＰメッセージの暗号化データ部分に前記許可情報を取り込むことを更に含む、請求項５の方法。
【請求項７】
次の許可方法、即ち、ａ）キー配信センタを使用するノードに許可目的のためにＡＡＡサーバと通信するＡＡＡクライアントをも使用させること、及び（ｂ）前記ＡＡＡクライアントに前記ＡＡＡサーバからＡＡＡプロトコルを用いて許可情報を取得させ、取得した情報を前記キー配信センタに戻させることを実行することを更に含む、請求項１の方法。
【請求項８】
前記キー配信センタにリアクティブモードで前記許可情報を前記オーセンティケータに直接通過させることを更に含む、請求項７の方法。
【請求項９】
前記ターゲットオーセンティケータノードがローカルケルベロスレルムからリモートケルベロルレルムチケット許可サービスのためのチケット許可チケット（ＴＧＴ）を取得できるように、異なるケルベロスレルムに対してインタレルムキーを確立することを更に含む、請求項１の方法。
【請求項１０】
前記ローカルレルムと前記リモートレルムとの間に１以上の中間レルムを持つことを更に含み、前記ターゲットオーセンティケータは前記レルム間の認証経路に沿って前記チケット許可チケット（ＴＧＴ）手順を繰り返す、請求項８の方法。
【請求項１１】
サーバ、オーセンティケータ及びモバイルノードの間の安全キー配信のためのメディア独立ハンドオーバキー管理アーチテクチャであって、
ａ）ＥＡＰサーバと通信するように構成されるＥＡＰピアを持つモバイルノードと、
ｂ）個別のケルベロスクライアントを有する少なくとも１つのターゲットネットワークに対して少なくとも１つのオーセンティケータと通信するように構成されるケルベロスサーバを更に含む前記モバイルノードと、
ｃ）前記少なくとも１つのオーセンティケータを介して前記少なくとも１つのターゲットネットワークに対するハンドオーバに関してセキュリティ信号伝達を行うように構成され、ＥＡＰ及びＡＡＡ信号伝達を用いて再認証をしないで前記少なくとも１つのオーセンティケータを介してセキュリティ関連性を動的に確立するためケルベロスを用いてマスタセッションキーを取得するネットワークアクセス認証及びキー管理信号伝達を含む前記モバイルノードと、により構成されるメディア独立ハンドオーバキー管理アーチテクチャ。
【請求項１２】
前記少なくとも１つのオーセンティケータはケルベロスクライアントを有する、請求項１１のメディア独立ハンドオーバキー管理アーチテクチャ。
【請求項１３】
前記少なくとも１つのオーセンティケータは前記複数のオーセンティケータを含み、前記複数のオーセンティケータに対する事前オーセンティケータキーをリアクティブ的に取得するように構成される、請求項１１のメディア独立ハンドオーバキー管理アーチテクチャ。
【請求項１４】
前記複数のオーセンティケータは少なくとも１つのアクセスポイント又は基地局を含む、請求項１１のメディア独立ハンドオーバキー管理アーチテクチャ。
【請求項１５】
サーバ、オーセンティケータ及びモバイルノードの間の安全キー配信のためのメディア独立ハンドオーバキー管理方法であって、
ａ）モバイルノードにキー配信センタ及びＥＡＰを用いてネットワークアクセス認証クレデンシャルから第一のオーセンティケータを介して初期ネットワークアクセス認証中にケルベロスをブートストラップするとともに前記オーセンティケータと共有するシークレットキーを取得させること、及び（ｂ）前記モバイルノードに第二のオーセンティケータへのハンドオーバ後にケルベロスを用いて前記第二のオーセンティケータとのセキュリティ関連性を確立させること、を含むメディア独立ハンドオーバキー管理方法。
【請求項１６】
前記モバイルノードに前記第二のオーセンティケータ上のケルベロスクライアントと通信するケルベロスサーバを含ませることをさらに含む、請求項１５の方法。
【請求項１７】
前記モバイルのハンドオーバ後に前記モバイルノードに対するチケット（Ｔ）を前記第二のオーセンティケータに配送することを更に含む、請求項１５の方法。
【請求項１８】
前記ブートストラップに関して、ＥＡＰサーバ及び前記キー配信センタは前記ＥＡＰサーバ及び前記キー配信センタに対して同じ識別子を用いて同じノードで実施される、請求項１５の方法。
【請求項１】
ハンドオーバ後にチケット配送を採用するリアクティブモードにおいてケルベロス化ハンドオーバキーイングを用いてサーバ、オーセンティケータ及びモバイルノード間の安全キー配信のためのメディア独立ハンドオーバキー管理方法であって、
ａ）モバイルノードにＡＳ−ＲＥＱをキー配信センタに送信させ、前記モバイルノードにチケット許可チケット（ＴＧＴ）によって前記キー配信センタからＡＳ−ＲＥＰを受信させること、
ｂ）ターゲットオーセンティケータに対する前記モバイルのハンドオーバ後に、モバイルノードに対するチケット（Ｔ）を取得するためターゲットオーセンティケータにＴＧＳ−ＲＥＰをキー配信センタに受信させること、
ｃ）前記オーセンティケータにＡＰ−ＲＥＱを前記モバイルノードに送信させ、前記モバイルノードを認証するため前記モバイルノードにＡＰ−ＲＥＰメッセージを前記オーセンティケータに送信させること、
を含むメディア独立ハンドオーバキー管理方法。
【請求項２】
前記チケット（Ｔ）を用いて前記モバイルノードと前記ターゲットオーセンティケータとの間に安全関連性を確立することを更に含む、請求項１の方法。
【請求項３】
前記ターゲットオーセンティケータに対する前記モバイルノードのハンドオーバ後に、前記モバイルノードにトリガメッセージを前記ターゲットオーセンティケータに送信させることをステップ（ｂ）の前に含む、請求項１の方法。
【請求項４】
前記オーセンティケータと前記キー配信センタとの間の往復信号伝達による前記反動モードでの信号的遅延を減少するためにクロスレルム動作を用いて前記ターゲットオーセンティケータに近い位置に前記キー配信センタを配置することを更に含む、請求項１の方法。
【請求項５】
前記ターゲットオーセンティケータが許可のためのハンドオーバ後にＡＡＡ信号伝達を行わないでアクセス制御を行うようにチケット許可データに許可情報を埋め込ませることを更に含む、請求項１の方法。
【請求項６】
ＴＧＳ−ＲＥＰメッセージの暗号化データ部分に前記許可情報を取り込むことを更に含む、請求項５の方法。
【請求項７】
次の許可方法、即ち、ａ）キー配信センタを使用するノードに許可目的のためにＡＡＡサーバと通信するＡＡＡクライアントをも使用させること、及び（ｂ）前記ＡＡＡクライアントに前記ＡＡＡサーバからＡＡＡプロトコルを用いて許可情報を取得させ、取得した情報を前記キー配信センタに戻させることを実行することを更に含む、請求項１の方法。
【請求項８】
前記キー配信センタにリアクティブモードで前記許可情報を前記オーセンティケータに直接通過させることを更に含む、請求項７の方法。
【請求項９】
前記ターゲットオーセンティケータノードがローカルケルベロスレルムからリモートケルベロルレルムチケット許可サービスのためのチケット許可チケット（ＴＧＴ）を取得できるように、異なるケルベロスレルムに対してインタレルムキーを確立することを更に含む、請求項１の方法。
【請求項１０】
前記ローカルレルムと前記リモートレルムとの間に１以上の中間レルムを持つことを更に含み、前記ターゲットオーセンティケータは前記レルム間の認証経路に沿って前記チケット許可チケット（ＴＧＴ）手順を繰り返す、請求項８の方法。
【請求項１１】
サーバ、オーセンティケータ及びモバイルノードの間の安全キー配信のためのメディア独立ハンドオーバキー管理アーチテクチャであって、
ａ）ＥＡＰサーバと通信するように構成されるＥＡＰピアを持つモバイルノードと、
ｂ）個別のケルベロスクライアントを有する少なくとも１つのターゲットネットワークに対して少なくとも１つのオーセンティケータと通信するように構成されるケルベロスサーバを更に含む前記モバイルノードと、
ｃ）前記少なくとも１つのオーセンティケータを介して前記少なくとも１つのターゲットネットワークに対するハンドオーバに関してセキュリティ信号伝達を行うように構成され、ＥＡＰ及びＡＡＡ信号伝達を用いて再認証をしないで前記少なくとも１つのオーセンティケータを介してセキュリティ関連性を動的に確立するためケルベロスを用いてマスタセッションキーを取得するネットワークアクセス認証及びキー管理信号伝達を含む前記モバイルノードと、により構成されるメディア独立ハンドオーバキー管理アーチテクチャ。
【請求項１２】
前記少なくとも１つのオーセンティケータはケルベロスクライアントを有する、請求項１１のメディア独立ハンドオーバキー管理アーチテクチャ。
【請求項１３】
前記少なくとも１つのオーセンティケータは前記複数のオーセンティケータを含み、前記複数のオーセンティケータに対する事前オーセンティケータキーをリアクティブ的に取得するように構成される、請求項１１のメディア独立ハンドオーバキー管理アーチテクチャ。
【請求項１４】
前記複数のオーセンティケータは少なくとも１つのアクセスポイント又は基地局を含む、請求項１１のメディア独立ハンドオーバキー管理アーチテクチャ。
【請求項１５】
サーバ、オーセンティケータ及びモバイルノードの間の安全キー配信のためのメディア独立ハンドオーバキー管理方法であって、
ａ）モバイルノードにキー配信センタ及びＥＡＰを用いてネットワークアクセス認証クレデンシャルから第一のオーセンティケータを介して初期ネットワークアクセス認証中にケルベロスをブートストラップするとともに前記オーセンティケータと共有するシークレットキーを取得させること、及び（ｂ）前記モバイルノードに第二のオーセンティケータへのハンドオーバ後にケルベロスを用いて前記第二のオーセンティケータとのセキュリティ関連性を確立させること、を含むメディア独立ハンドオーバキー管理方法。
【請求項１６】
前記モバイルノードに前記第二のオーセンティケータ上のケルベロスクライアントと通信するケルベロスサーバを含ませることをさらに含む、請求項１５の方法。
【請求項１７】
前記モバイルのハンドオーバ後に前記モバイルノードに対するチケット（Ｔ）を前記第二のオーセンティケータに配送することを更に含む、請求項１５の方法。
【請求項１８】
前記ブートストラップに関して、ＥＡＰサーバ及び前記キー配信センタは前記ＥＡＰサーバ及び前記キー配信センタに対して同じ識別子を用いて同じノードで実施される、請求項１５の方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０Ａ】
【図１０Ｂ】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０Ａ】
【図１０Ｂ】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【公表番号】特表２０１０−５２１０８６（Ｐ２０１０−５２１０８６Ａ）
【公表日】平成２２年６月１７日（２０１０．６．１７）
【国際特許分類】
【出願番号】特願２００９−５５１７５６（Ｐ２００９−５５１７５６）
【出願日】平成２０年３月３日（２００８．３．３）
【国際出願番号】ＰＣＴ／ＵＳ２００８／００２７９８
【国際公開番号】ＷＯ２００８／１０９０３９
【国際公開日】平成２０年９月１２日（２００８．９．１２）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＧＳＭ
【出願人】（０００００３０７８）株式会社東芝 (54,554)
【出願人】（５０４４７３６７０）テルコーディア・テクノロジーズ・インコーポレーテッド (72)
【Ｆターム（参考）】
【公表日】平成２２年６月１７日（２０１０．６．１７）
【国際特許分類】
【出願日】平成２０年３月３日（２００８．３．３）
【国際出願番号】ＰＣＴ／ＵＳ２００８／００２７９８
【国際公開番号】ＷＯ２００８／１０９０３９
【国際公開日】平成２０年９月１２日（２００８．９．１２）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＧＳＭ
【出願人】（０００００３０７８）株式会社東芝 (54,554)
【出願人】（５０４４７３６７０）テルコーディア・テクノロジーズ・インコーポレーテッド (72)
【Ｆターム（参考）】
[ Back to top ]