JP5043117B2 - ケルベロス化ハンドオーバキーイング - Google Patents

Description

本出願はケルベロス化ハンドオーバキーイングに関する。

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

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

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

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

通常、上位４層は、メッセージがユーザから、又はユーザへ渡されるときに使用され、下位３層は、メッセージが装置（ＩＰホスト装置など）を通過するときに使用される。ＩＰホストは、サーバ、ルータ、ワークステーションなど、ＩＰパケットを送受信することのできるネットワーク上の任意の装置である。他の何らかのホストに向けられているメッセージは、各上位層には渡されず、この他のホストに転送される。ＯＳＩモデルの各層を以下に列記する。第７層（すなわち、アプリケーション層）は、例えば、通信相手が識別され、サービス品質が識別され、ユーザ認証及びプライバシが考慮され、データ構文に対する制約条件が識別される層である。第６層（すなわち、プレゼンテーション層）は、例えば、着信及び発信データをあるプレゼンテーション形式から別の形式に変換する層である。第５層（すなわち、セッション層）は、例えば、アプリケーション間の会話、交換及びダイアログをセットアップし、調整し、終了させる層である。第４層（すなわち、トランスポート層）は、例えば、エンドツーエンド制御及び誤りチェックなどを管理する層である。第３層（すなわち、ネットワーク層）は、例えば、経路指定や転送などを処理する層である。第２層（すなわち、データリンク層）は、例えば、物理レベルでの同期を提供し、ビットスタッフィングを行い、伝送プロトコルの知識及び管理などを提供する層である。米国電気電子技術者協会（ＩＥＥＥ）では、データリンク層を、物理層との間のデータ転送を制御するＭＡＣ（媒体アクセス制御）層と、ネットワーク層とのインターフェースを取り、コマンドを解釈し、誤り回復を行うＬＬＣ（論理リンク制御）層という、２つのさらなる副層（サブレイヤ）に細分する。第１層（すなわち、物理層）は、例えば、物理レベルにおいてネットワークを介してビットストリームを伝達する層である。ＩＥＥＥでは、物理層を、ＰＬＣＰ（物理層収束手順）副層とＰＭＤ（物理媒体依存）副層とに細分する。

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

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

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

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

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

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

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

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

ケルベロス（Kerberos）に関する背景
ケルベロスはネットワーク認証プロトコルである。http://web.mit.edu/Kerberos/を参照。それは秘密キー暗号文を用いてクライアント／サーバアプリケーションの認証を行う。このプロトコルの自由な実施はマサチューセッツ工科大学から利用可能である。ケルベロスは更に多くの商品に利用できる。

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

ケルベロス[RFC1510]は認証、許可及びキー配信を与える周知のセキュリティプロトコルである。それは複数のプロトコルを確保するために使用される。

ケルベロスはユーザがパスワードを再入力する必要がなくクライアントＡがチケット付与サービス（Ticket Granting Service (TGS)）をアクセスする初期チケットを取得することを可能にする。その初期チケットはクライアントＡがサービスＢをアクセスするための他のチケットを得るためＴＧＳとのケルベロル取り決めを開始することを可能にする。この方法を用いることによって、ケルベロスもＡが（ビジテッドドメインにおいて）局所ＴＧＳをアクセスするため（Ａのホームドメインにおける）遠隔ＴＧＳからチケットを回復できる場合にクロスレルムオペレーション（cross-realm operation）を可能にする。しかしながら、ケルベロスは3人のメンバ間で時間同期を必要とする。

幾つかの実施例では、ＥＡＰフレームワークの柔軟性と大学でのケルベロスの幅広い展開とを組合すことによってケルベロスチケット付与チケットをブートすることが可能になる。このときこのケルベロスチケット付与チケットは各種プロトコルと共に使用するためサービスチケットを探索するために使用できる。ＥＡＰプロトコル相互作用を利用してケルベロスチケットをブートするこの方法は[I-D.tschofenig-pana-bootstrap-kerberos]に開示されている。その全ての開示は本願に引用して援用される。

ＥＡＰとケルベロスとを組み合わせる他の方法はＥＡＰに基づく事前認証機構（EAP-based pre-authentication mechanism）をケルベロスに統合することである。しかしながら、証明をブートする一般的なプロトコルを使用することは（MIPv6ブートストラッピングワーク[I-D.ietf-mip6-bootstrap-ps]の一部として検討されているような）使用モバイルＩＰのための対象キーをブートするためにも又は公開／個人キーをブートするためにも利用できる。故に、一時公開及び個人キー対をエンドホストに送ることを機密保護する必要がある。このキー対は取り消し機構を多分必要としないで、短寿命であり、（IKEv2又はTLSを含む）公開キー利用機構を利用する全てのセキュリティプロトコルにおいて使用できる。対称暗号化に基づく認証プロトコルはなおＥＡＰ内で使用できるので、回避された公開キー基盤が大きな利点となる。以下のセクションで検討するように、拡張可能認証プロトコル（Extensible Authentication Protocol (EAP)）［全体的に本願に引用して援用されるRFC3748を参照］が認証メソッドを提供する。幾つかの実施例では、PANAプロトコル[I-D.ietf-pana-pana]はアクセスネットワークにおいてPaC (PANAクライアント)とPAA (PANA認証エージェント)と間でＥＡＰメッセージを伝える。

ＥＡＰに関する背景
（以下に引用する）Ａｂｏｂａ， ＲＦＣ ３７４８を参照すると、拡張可能認証プロトコル（ＥＡＰ）の具体的態様が説明されている。ＥＡＰは複数の認証メソッドをサポートする認証フレームワークである。ＥＡＰは一般的にはＩＰを必要としない、ポイントツーポイントプロトコル（ＰＰＰ）又はＩＥＥＥ８０２のような複数のデータリンク層上で直接に実行する。ＥＡＰは二重削除及び再送信のため独自のサポートを備えているが、下位層順の保証に依存する。断片化はＥＡＰ自体内でサポートされないが、個々のＥＡＰメソッドがこれをサポートできる。

ＥＡＰは切換回路だけでなく、専用リンクに使用でき、無線リンクだけでなく有線であってもよい。今まで、ＥＡＰはＰＰＰ ［ＲＦＣ１６６１］を用いて切換回路又はダイアルアップネットワークを介して接続するホスト及びルータによって実現されていた。それはまたＩＥＥＥ ８０２ ［ＩＥＥＥ−８０２］を用いてスイッチ及びアクセスポイントによっても実現されていた。ＩＥＥＥ ８０２有線媒体に関するＥＡＰカプセル化が［ＩＥＥＥ−８０２．１Ｘ］に説明されており、ＩＥＥＥ無線ＬＡＮｓに関するカプセル化は［ＩＥＥＥ−８０２．１１ｉ］に開示されている。

ＥＡＰアーチテクチャの利点の１つはその柔軟性にある。ＥＡＰは、特定の認証機構を選択するため、一般的にはauthenticator(オーセンティケイタ)が使用すべき特定の認証メソッドを決定するためにより多くの情報を要求した後に選択するために使用される。各新しい認証メソッドをサポートするために更新されることをauthenticatorが必要とする以外に、ＥＡＰは幾つか又は全てのメソッドに対するパススルーとして行動するauthenticator及びピアによって、幾つか又は全ての認証メソッドを実施できるバックエンド認証サーバの使用を可能にする。

この後者の引用文献の中で、authenticatorがパススルーとして行動するか否かに関係なくauthenticatorの要求が適用される。要求がauthenticator又はバックエンド認証サーバのいずれかに適用されることを意味している場合、ＥＡＰ認証が終了される場所に依存して、用語「ＥＡＰサーバ」が使用されている。

ＥＡＰは再送信のサポートを行っている間、それは下位層によって提供される順序付け保証を仮定し、故に異常のある受信はサポートされない。

ＥＡＰは断片化及び再構築をサポートしないので、最小ＥＡＰ ＭＴＵより大きなペイロードを生成するＥＡＰ認証メソッドは断片化サポートを提供する必要がある。

ＥＡＰ−ＴＬＳのような認証メソッドは断片化及び再構築を提供するが、この後者の引用文献で定義されたＥＰＡメソッドは行わない。その結果、ＥＡＰパケットサイズがリンクのＥＡＰ ＭＴＵを越えれば、これらのメソッドは困難に合うことになる。

ＥＡＰ認証はサーバ（authenticator）によって初期化されるが、多くの認証プロトコルはクライアント（ピア）によって初期化される。その結果、ＥＡＰを通過するために１つ又は２つの追加メッセージ（多くとも１往復）を追加することが認証アルゴリズムに必要となるかもしれない。

証明利用認証がサポートされる場合、追加往復の数は証明書連鎖（certificate chains）の断片化によりかなり多くなるかもしれない。一般的に、断片化ＥＰＡパケットは断片があるだけ多くの往復で送る必要がある。例えば、サイズが１４９６０オクテットの証明連鎖は１４９６オクテットＥＡＰ ＭＴＵで１０往復する必要がある。ＥＡＰが重大なパケットロスを起こす下位層を繰り返す場合、又はauthenticatorと認証サーバとの接続が重要なパケットロスを起こす場合、多くの往復を必要とするＥＡＰメソッドは困難に直面することもある。これらの状況において、少ない往復を用いたＥＡＰメソッドの使用が望まれる。

ＥＡＰ認証交換は次のように処理される。即ち、
［１］authenticatorはピアを認証するためリクエスト（Request）を送る。リクエストは要求されているものを示すタイプフィールドを有する。リクエストタイプの例はアイデンティティ、ＭＤ５−チャレンジなどを含む。ＭＤ５−チャレンジタイプはＣＨＡＰ認証プロトコルに密接に対応する［ＲＦＣ１９９４参照］。一般的には、authenticatorは初期認証リクエストを送ることになるが、初期認証リクエストは必要とされなく、バイパスされないこともある。例えば、アイデンティティはピアが接続されているポート（専用回線、専用スイッチ又はダイアルアップポート）によって決定される場合、又はアイデンティティが（ＭＤ５−チャレンジレスポンスなどのネームフィールドにおいて、呼出局アイデンティティ又はＭＡＣアドレスを介して）他のメソッドで得られる場合には要求されないこともある。

［２］ピアは有効リクエストに答えてレスポンスパケット（Response packet）を送る。リクエストパケットと同様に、レスポンスパケットはリクエストのタイプフィールドに対応するタイプフィールドを含む。

［３］authenticatorは追加リクエストパケットを送り、ピアはレスポンスで答える。リクエスト及びレスポンスのシーケンスは必要なだけ継続する。ＥＡＰは‘横並び（lock step）’プロトコルであり、故に、初期リクエスト以外は、新たなリクエストは有効なレスポンを受理する前に送ることができない。authenticatorはリクエストを再送信する責任がある。適正数の再送信の後には、authenticatorはＥＡＰ対話を終了すべきである。authenticatorは再送信したとき、又はピアからのレスポンスが得られないときには成功又は失敗パケットを送る必要がない。

［４］対話はauthenticatorがピア（１以上のリクエストに対して受入れがたいレスポンス）を認証できなくなるまで続けられる。この場合、authenticatorの実行にはＥＡＰ失敗（コード４）を送信する必要がある。あるいは、認証対話は認証が成功したことをauthenticatorが決定するまで継続する。この場合、authenticatorはＥＡＰ成功（コード３）を送信する必要がある。

他の利点では、ＥＡＰプロトコルは特定のものを事前に取り決めする必要が無く多くの認証機構をサポートできる。更に、ネットワークアクセスサーバ（ＮＡＳ）装置（例えば、スイッチ又はアクセスポイント）は各認証メソッドを理解する必要が無く、バックエンド認証サーバに対するパススルーエージェントとして動作できる。パススルーのためのサポートは随意的である。authenticatorは局所ピアを認証でき、更に、同時に非局所ピア及び局所的には実行しない認証メソッドに対するパススルーとして作用する。更に、バックエンド認証サーバからauthenticatorを分離することによって証明管理及び政策決定を簡単にする。

概念的に、ＥＡＰ実施は次の要素からなる。

［ａ］下位層。下位層はピアとauthenticatorとの間でＥＡＰを送受信する義務がある。ＥＡＰはＰＰＰ，有線ＩＥＥＥ８０２ラン[IEEE-802.1X], IEEE 802.11 wireless LANs [IEEE-802.11], UDP (L2TP [RFC2661]及びＩＫＥｖ２参照）及びＴＣＰを含む各種下位層上で実行していた。

［ｂ］ＥＡＰ層。ＥＡＰ層は下位層を介してＥＡＰパケットを送受信し、二重検出及び再送信を実行し、ＥＡＰメッセージをＥＡＰピア及びauthenticator層に搬送し及びauthenticator層から受信する。

［ｃ］ＥＡＰピア及びauthenticator層。コードフィールドに基づいて、ＥＡＰ層は入力ＥＡＰパケットをＥＡＰピア及びauthenticator層に分離する。一般的には、所定ホストでのＥＡＰ実行はピア又はauthenticator機能のいずれかをサポートすることになるが、ホストがＥＡＰピア及びauthenticatorの両方として作用することを可能にする。そのような実行においては、ＥＡＰ及びauthenticator層の両方が存在することになる。

［ｄ］ＥＡＰメソッド層。ＥＡＰメソッドはauthenticatorアルゴリズムを実行し、ＥＡＰピア及びauthenticator層を介してＥＡＰメッセージを送受信する。断片化のサポートはＥＡＰ自体によっては得られないが、これはＥＡＰメソッドの責任である。Id
以後の参考文献はここに参照として引用される次の定義を説明している。

Authenticator
ＥＡＰ認証を初期化するリンクの終端。期間authenticatorは［ＩＥＥＥ−８０２．１Ｘ］に使用され、この明細書では同様の意味を有する。

ピア
authenticatorに応答するリンクの終端。［ＩＥＥＥ−８０２．１Ｘ］では、この終端はサプリカント（Supplicant）として知られている。

バックエンド認証サーバ
バックエンド認証サーバは認証サービスをauthenticatorに提供するエンティティ（entity）である。使用時には、このサーバは一般的にはauthenticatorのためにＥＡＰメソッドを実行する。この専門用語は［ＩＥＥＥ−８０２．１Ｘ］に使用されている。

ＡＡＡ
ＥＡＰサポートを持つ認証、許可、及び課金（Authentication, Authorization, and Accounting（AAA））プロトコルはＲＡＤＩＵＳ及びダイアミタ（Diameter）を含む。この明細書では、用語“ＡＡＡサーバ”及び“バックエンド認証サーバ”は交換可能に使用される。

ＥＡＰサーバ又はサーバ
ピアによってＥＡＰ認証メソッドを終了するエンティティ。バックエンド認証サーバが使用されない場合には、ＥＡＰサーバはauthenticatorの一部である。authenticatorがパススルーモードで動作する場合、ＥＡＰサーバはバックエンド認証サーバに設けられる。

成功した認証
この明細書の内容では、「成功した認証」はＥＡＰメッセージの交換であり、その結果authenticatorはピアによってアクセスできることを決定し、ピアがこのアクセスを使用することを決定する。authenticatorの決定は一般的には認証及び許可面の両方を含み、ピアはauthenticatorに首尾良く証明できるが、アクセスは政策的理由によりauthenticatorによって拒絶されるかもしれない。

マスタセッションキー（ＭＳＫ）
ＥＡＰピアとサーバ間で得られ、ＥＡＰメソッドによって転送されるキーイングマテリアル。ＭＳＫは長さが少なくとも６４オクテットである。既存の実施では、ＥＡＰサーバとして作用するＡＡＡサーバはＭＳＫをauthenticatorに搬送する。

拡張マスタセッションキー（ＥＭＳＫ）：
ＥＡＰクライアントとサーバ間で得られ、ＥＡＰ法によって転送される追加キーイングマテリアル。ＥＭＳＫは長さが少なくとも６４オクテットである。ＥＭＳＫはauthenticator又は任意の他の第三者によっては共有されない。ＥＭＳＫはまだ定義されていない将来の使用のために予約される。

ＥＡＰ拡張
参考のため、出願人はthttp://www.ietf.org/internet-drafts/draft-ietf-hokey-erx-04.txtのサイトに掲載されているEAP Extensions for EAP Reauthentication Protocol (ERP), IETF Internet Draft, August 24, 2007, of V. Narayanan, et al.を参照する。この参考文献は次のようにＥＡＰ再認証プロトコルのためのＥＡＰ拡張を説明している。拡張可能認証プロトコルは２つのグループを認証するメソッドのトランスポートのための総括フレームワークであり、認証は一方向又は相互のいずれかである。主要目的はネットワークアクセス制御であり、キー生成メソッドはアクセス制御を実施するために推奨される。ＥＡＰキーイング階層は２つのキーを定義する。これらのキーはトップレベルで、即ちマスタキーセッション（ＭＳＫ）及び拡張ＭＳＫ（ＥＭＳＫ）で得られる。最も一般的な展開シナリオにおいては、ピア及びサーバはauthenticatorとして知られている第三者を介して互いに認証する。authenticator又はauthenticatorによって管理されるエンティティはアクセス制御を実施する。認証の成功後には、サーバはＭＳＫをauthenticatorにトランスポートし、authenticator及びピアはＭＳＫを認証キー又はキー誘導キーとして用いて一時セッションキー（ＴＳＫ）を取得し、単位パケットアクセス実施のためにＴＳＫを使用する。Id。ピアがあるauthenticatorから他のauthenticatorに移動するときは、完全ＥＡＰ認証を避けることが望ましい。ＥＡＰメソッドの他の実行との完全ＥＡＰ交換は完了するために数回の往復及びかなりの時間を取り、ハンドオフ時間に遅延が生じる。幾つかのＥＡＰメソッドは計算オーバヘッドを減じることによって再認証を最適化するために初期認証から状態の使用を特定するが、メソッド特定再認証は殆どのケースでは少なくとも２往復する。殆どのメソッドは再認証を支援しないことに注意することも重要でもある。故に、個々のメソッドにおけるよりもＥＡＰにおいて効果的な再認証支援を受けるのがよい。

authenticator間で共有するキーはハンドオフタイムを低減するため現実的な解決法として時々使用される。その場合、authenticatorの譲歩が他のauthenticatorを介して確立されるＥＡＰセッションの譲歩となる。ld。要するに、再びＥＡＰメソッドを実行することを必要としないでピアとauthenticator間にフレッシュキーを確立することを可能にする有効ＥＡＰ再認証機構を設計する必要がある。ld。この明細書はＥＡＰを用いて有効再認証のためにＥＡＰ再認証拡張（ＥＲＸ）を特定している。ＥＲＸに基づくＥＡＰ再認証プロトコル（ＥＲＰ）はピアに対するＥＡＰメソッド非依存再認証を支援する。このピアは以前に実行されたＥＡＰ認証からの有効な残りキーマテリアルを有する。プロトコル及びＥＡＰ再認証に必要なキー階層がこの明細書に記載されている。ld。

EAPの拡張(EAP-EXT):
本願はいずれも「ＥＡＰ拡張（EAP-EXT）のためのＥＡＰ方法」と名称付けられ、Y. Oba, et al.による2007年10月4日付提出の本譲渡人の先願米国非仮出願番号11／867，659及びY. Oba, et al.による2006年12月8日付提出の米国仮出願番号60／869，113に記載されているような発明を越える更なる進展を提供している。両出願の全開示は全てここに記載されているようにここに引用して援用される。背景参照として、本譲渡人の前記背景出願の技術に関する情報は次のパラグラフに含まれる。

１．ＥＡＰ−ＥＸＴの序論
上記検討に加えて、ＥＡＰ（拡張可能認証プロトコル）は“ＥＡＰメソッド” [RFC3748]として知られている多くの認証アルゴリズムを支援する認証プロトコルである。ＥＡＰでは、ＥＡＰピア及びＥＡＰサーバはＥＡＰキーイングマテリアル、即ち、ＭＳＫ（マスタセッションキー）及びＥＭＳＫ（拡張マスタセッションキー）を生成する。ＭＳＫの生成、搬送及び使用の詳しいフレームワークは[I-D.ietf-eap-keying］に記載されている。

ＥＭＳＫ用法の１つが再認証である場合にＥＭＳＫ（拡張マスタセッションキー）の幾つかの用法を定義することによってEAP [RFC3748]の拡張機能がある。ＥＡＰの他の拡張機能は[I-D.ohba-eap-channel-binding]に定義されているチャネル結合方式（channel binding scheme）である。チャネル結合に関する追加の背景文献として、２００６年４月２０日にＹ．Ｏｈｂａによって出願された、CHANNEL BINDING MECHANISM BASED PARAMETER BINDING IN KEY DERIVATIONと名称付けられた同時継続の出願番号１１／３７９，５６８の全開示が全体として参照することによって本明細書に援用される。ＥＡＰの拡張機能をサポートする実施は拡張機能をサポートしない実施と相互運用する必要があり、故に、前者の実施は後者の実施と通信するとき拡張機能を無効にするので、ＥＡＰピアに対する機構が必要となり、ＥＡＰの拡張機能に関してケイパビリティを取り決めるＥＡＰサーバが必要となる。

ＥＡＰ機能を拡張するために２つの基本的な方法がある。１つの方法は既存の方法、即ち、リクエスト、レスポンス、成功及び失敗に加えて拡張ＥＡＰ機能を実現するために新たなＥＡＰコードを定義することである。しかしながら、この方法はＲＦＣ３７４８への変更を必要とし、下位層プロトコルへの変更も必要とするかもしれない。他の方法は拡張機能を実現するために新たなＥＡＰメソッドを定義することである。この明細書は後者の方法が既存のＥＡＰ展開への攻撃を最小にするために後者の方法と取る。

EAP-EXTはＥＡＰ機能を拡張するＥＡＰメソッドを説明している。幾つかの好適実施形態では、拡張ＥＡＰ機能はチャネル結合及び再認証を含む。また、ＥＡＰ−ＥＸＴメソッドはその内部の多くのＥＡＰメソッドの順序づけを可能にする。

２．ＥＡＰ−ＥＸＴ概要
好適実施形態では、ＥＡＰ−ＥＸＴはケイパビリティ交換を提供する。この際、メッセージ内のビットはケイパビリティの表示に使用できる。幾つかの実施形態では、１ビット（Ｒ−ビット）は再認証ケイパビリティに使用される。幾つかの実施形態では、１ビット（Ｃ−ビット）はチャネル結合ケイパビリティを示すために使用される。

ＥＡＰ−ＥＸＴが使用されると、サーバは第１のＥＡＰリクエストを送る前にサーバにピアのアイデンティティが知られれば先のＥＡＰ−アイデンティティ交換が省略できる。この点について、ピアのアイデンティティをサーバに提供する、例えば、authenticatorとサーバとの間でピアのアイデンティティを転送する幾つかのアウトバンド(outband)機構がある。

ＥＡＰ−ＥＸＴにおいて、チャネル結合及び再認証のような拡張ＥＡＰケイパビリティはピア及びサーバ間で交換される。同時に、少なくとも１つのＥＡＰメソッド（例えば、ＥＡＰ−ＴＬＳ）はピアを認証するためのＥＡＰ−ＥＸＴ内で実行される。内部メソッドがＥＡＰキーイングマテリアルを生成するまで、ＡＵＴＨ ＴＬＶは含まれず、ケイパビリティは保護されない。故に、１つの内部ＥＡＰメソッドだけがあれば、ＡＵＴＨ ＴＬＶを有するがメソッドＴＬＶを有さない追加のＥＡＰ−ＥＸＴがＥＡＰ成功又はＥＡＰ失敗メッセージを送る前に実行される。TLVs (Type-Length-Value)に関する背景参照として、データ通信プロトコルにおいて情報はType-Length-Value又はプロトコルの内部のTLV要素として符号化できることを留意する。一例として、タイプ及び長さフィールドはサイズが（例えば、数バイトに）一般的に固定され、値フィールドは一般的には可変サイズである。これらのフィールドは一般的には次のように使用される、即ち、タイプはメッセージのこの部分が表すフィールドの種類を示す数値コード、レングスは値フィールドのサイズ（一般的にはバイトで）、及びバリューはメッセージのこの部分に対するデータを含む可変サイズのバイトセットを用いた。TLV表現を用いる利点の幾つかはTLVシーケンスが発生した構文解析関数を用いて容易に探索されること、古いノードで受信される新しいメッセージ要素が支障なく省略でき、メッセージの残りが構文解析できること、そしてTLV要素が一般的に早く構文解析を行い、データを小さくする二進形式で使用されることを含む。

内部ＥＡＰメソッドはＥＡＰキーイングマテリアルを生成した後、ＥＡＰ−ＥＸＴメッセージはＡＵＴＨ ＴＬＶによってサポートする必要がある。ＥＡＰ−ＥＸＴメッセージの中のＡＵＴＨ ＴＬＶｓは最後に成功した内部メソッドのＥＡＰキーイングマテリアルから生成されるＥＡＰ−ＥＸＴ−ＫＥＹを用いて計算する必要がある。これはＥＡＰ−ＥＸＴ内部で順次実行される複数の内部ＥＡＰメソッドがあれば、新たなＥＡＰ−ＥＸＴ−ＫＥＹがシーケンスの内部ＥＡＰメソッドがＥＡＰキーイングマテリアルを生成する毎に生成されることを意味する。任意の内部ＥＡＰメソッドはＥＡＰキーイングマテリアルを生成できる用になる必要がある。

成功したＥＡＰ−ＥＸＴ実行の最後に、最後に成功した内部ＥＡＰメソッドによって生成されるＥＡＰキーイングマテリアルはＥＡＰ層に転送される。Ｆ−ビットはＥＸＰ−ＥＸＴ交換の終了を示すために使用される。

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

３．エラー処理
エラーは複数の理由、例えば、内部ＥＡＰメソッド認証の失敗又は異常、未知、紛失ＥＡＰ−ＥＸＴ ＴＬＶにより生じるかもしれない。エラーはピア又はサーバのいずれかによって検出できる。エラーを起こしたＥＡＰ−ＥＸＴメッセージは誤りメッセージと見なされる。Ｅ−ビットセットを持つＥＡＰ−ＥＸＴメッセージはエラー表示のために使用される。これらのメッセージはエラー表示と見なされる。エラー表示はＡＵＴＨ ＴＬＶを含める必要があり、他のＴＬＶｓを含めるべきでない。

有効ＡＵＴＨ ＴＬＶを持たない（間違ったエラー表示を含む）どんな間違いメッセージも無許可で破棄さする必要がある。

有効ＡＵＴＨ ＴＬＶを持つ間違いリクエストに対して、ピアはエラー表示レスポンスを送る。有効ＡＵＴＨ ＴＬＶを伴わない間違いレスポンスに対して、サーバはエラー表示リクエストを送り、このリクエストはエラー表示レスポンスでピアによって応答される。サーバは有効ＡＵＴＨ ＴＬＶを伴うエラー表示レスポンスに応答してＥＡＰ失敗メッセージを送り返す。

４．完全性保護キー
ＥＡＰ−ＥＸＴは２種類のキー、即ち、１）ＥＡＰ−ＥＸＴ−ＫＥＹ及び２）ＥＡＰ−ＲＥＡＵＴＨ−ＫＥＹを定義する。

４．１．ＥＡＰ−ＥＸＴ−ＫＥＹは完全性保護ＥＡＰ−ＥＸＴメッセージのためにＡＵＴＨ ＴＬＶｓの計算に使用される。ＨＭＡＣ−ＳＨＡ−２５６（上記文献に含まれる参考［ｓｈａ２５６］を参照）は完全性アルゴリズムに使用されると、ＥＡＰ−ＥＸＴ−ＫＥＹのレングスは３２オクテットである。ＥＡＰ−ＥＸＴ−ＫＥＹは次のように定義されるＵＳＲＫ（Usage Specific Root Key）誘導アルゴリズムを用いて内部ＥＡＰメソッドによって生成されるＥＭＳＫから得られる（例えば、上記に参照することによって援用される参考［I-D.salowey-eap-emsk-deriv］を参照）。

ＥＡＰ−ＥＸＴ−ＫＥＹ＝ＫＤＦ（EMSK, “EAP-EXT-Integrity-Key”, length）．
ＫＤＦでは、ＥＡＰ−ＥＸＴ−ＫＥＹは上記に参照することによって援用される参考［I-D.salowey-eap-emsk-deriv］に特定されているデフォルトＰＲＦを用いる。

背景参照として、USRKキー誘導関数(KDF)は拡張マスタセッションキー(EMSK)、キーラベル、オプションデータ及び出力レングスからUSRKを求める。KDFは同じ入力に対して同じ出力を与えるはずである。基本キー誘導関数はUSRK = KDF（EMSK、キーラベル、オプションデータ、レングス）である。Id参照。一般的には、キーラベルは各使用定義に独特のプリント可能なASCIIストリングであり、最大２５５バイトである。Id参照。一般的には、それらはドメインがUSRKの使用定義の仕様を管理する組織（organization）であるところのフォームlabel-string@domainである。キーラベルは広域的特異性を持つ。これらラベルの割り当てのルールは[I-D.salowey-eap-emsk-deriv]のセクション７に示されている。

前記文献に説明されているように、EMSKキー誘導関数は次の関数プロトタイプを持つ仮想ランダム関数に基づいている。

KDF = PRF(key, data)。Id参照。USRKsをEMSKから得るために使用されるデフォルトPRFはHMAC-SHA-256に基づいて[RFC4306]に由来するPRF+ キー拡張PRFから引き出される。prf+構成が[RFC2246]に使用されるもののような他のPRFsを超えるその簡単さ及び効率のために選択された。[RFC4306]によるPRF+の定義は以下に示される。

prf+ (K,S) = T1 | T2 | T3 | T4 | ...
但し
T1 = prf (K, S | 0x01)
T2 = prf (K, T1 | S | 0x02)
T3 = prf (K, T2 | S | 0x03)
T4 = prf (K, T3 | S | 0x04)
キーマテリアルの必要レングスを計算するために必要に応じて継続する。

キーKはEMSKであり、Sは[I-D.salowey-eap-emsk-deriv]のセクション１に定義されたデータである。Id参照。図のように、PRFはHMAC-SHA-256と考えられる。Id参照。

４．２． ＥＡＰ−ＲＥＡＵＴＨ−ＫＥＹ
ＥＡＰ−ＲＥＡＵＴＨ−ＫＥＹは再認証機構に使用されるＥＡＰメソッドによって要求される事前共有キーとして使用される。ＥＡＰ−ＲＥＡＵＴＨ−ＫＥＹのレングスは再認証機構に依存する。ＥＡＰ−ＲＥＡＵＴＨ−ＫＥＹは上記で援用される参考［I-D.salowey-eap-emsk-deriv］に次のように定義されるＵＳＲＫ誘導アルゴリズムを用いてＥＡＰ−ＥＸＴから転送されるＥＭＳＫから得られる。

ＥＡＰ−ＲＥＡＵＴＨ−ＫＥＹ ＝ ＫＤＦ（EMSK, “EAP-EXT-Reauthentication-Key”, length）
５． メッセージフォーマット
ＥＡＰ−ＥＸＴは（ＩＡＮＡによって割り当てられるべき）EAP Type Xを用いる。［ＲＦＣ３７４８］に定義された共通ＥＡＰフィールド（例えば、コード、識別子、長さ及び種類）を含むメッセージフォーマットは図３（Ａ）に示される。

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

このビットはメッセージがエラー表示であるときに設定される。このビットが設定されると、Ｆビットも設定する必要がある。エラー表示に関する詳細な説明のセクション３を参照。

バージョン：
この８ビットフィールドはＥＡＰ−ＥＸＴメソッドのバージョンを示す。この明細書はバージョン１を定義している。

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

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

各ビットは特定ケイパビリティに対応する。各ビットの意味は次の通りである。

Ｃ：
このビットは送信者がＭＳＫのための［I-D.ohba-eap-channel-binding］に定義されるチャネル結合機構をサポートすることを示すために設定される。このビットはリクエスト及びレスポンスの両方に対して設定され、ＥＡＰ−ＥＸＴメソッドが首尾よく完了すると、ピア及びサーバはチャネル結合機構を可能にする必要がある。ｐｒｆ＋用デフォルトハッシュアルゴリズム（default hash algorithm）はAUTH_HMAC_SHA1_160である。

Ｒ：
このビットは送信者が再認証ＥＡＰメソッドをサポートすることを示すために設定される。このビットは最後のリクエスト／ＥＸＴメッセージに設定されると（即ち、Ｆビットを有するリクエスト／ＥＸＴが設定されると）、メッセージはサーバＩＤ ＴＬＶ及びピアＩＤ ＴＬＶを含める必要があり、Reauth-Key-Lifetime AVPを含めることができる。このビットが最後のリクエスト／ＥＸＴ及びレスポンス／ＥＸＴメッセージ交換に設定されると、ピア及びサーバはＥＡＰ−ＲＥＡＵＴＨ−ＫＥＹを発生する必要がある。サーバＩＤ及びピアＩＤはサーバＩＤ及びピアＩＤ ＴＬＶｓに含められ、ＥＡＰ−ＲＥＡＵＴＨ−ＫＥＹは再認証ＥＡＰメソッドに使用される。デフォルト再認証機構はこの明細書に基づく従来技術のそれらによって選択できる。

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

ＴＬＶ (Type-Length-Value's)：
ゼロ, 1以上のTLVs。TLVフォーマットは図３（C）に示される。

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

レングス：
このフィールドは種類及びＴＬＶのレングスフィールドを含めて、オクテットでこのＴＬＶのレングスを示す。

バリュー
このフィールドはＴＬＶタイプに特定されるデータを含む。

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

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

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

ＴＬＶバリューフィールドはこのフィールドを含む全体のＥＡＰメッセージわたって計算される。完全性データを計算する前に、このフィールドは全てゼロに初期化する必要がある。このフィールドのレングスは使用時に完全性アルゴリズムに依存する。完全性チェックが失敗すると、メッセージは無許可で破棄する必要がある。デフォルト完全性アルゴリズムはＨＭＡＣ−ＳＨＡ−２５６である（例えば、以下で援用されている文献［sha256］を参照）。

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

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

６．５．Reauth-Key-Lifetime TLV
Reauth-Key-Lifetime TLV （タイプ５）はＥＡＰ−ＲＥＡＵＴＨ−ＫＥＹの寿命を秒単位で含む。

７．安全性考慮
内部ＥＡＰメソッドがＥＡＰキーイングマテリアルを送る前にケイパビリティ交換は保護されない。故に、ＥＡＰキーイングマテリアルの作成後の追加サポートメッセージ交換は能力情報がピア及びサーバによって検出されないで攻撃者によって変更されるのを避けるために義務付けられる。

ＥＡＰ−ＥＸＴはその中の多くのＥＡＰメソッドの順序付けを可能にする。複数の入れ子又は順序認証メソッド（multiple nested or sequential authentication methods）を暗号的に結合しないでそれらで構成される複合認証メソッドが介入者攻撃（man-in-the-middle attack）に対して無防備である。ＥＡＰ−ＥＸＴはシーケンスにおいて前に成功した内部メソッドによって生成されるキーを用いて外部ＥＡＰメソッド（即ち、ＥＡＰ−ＥＸＴ）と共に各内部ＥＡＰメソッドを保護し、最後に成功した内部ＥＡＰメソッドによって生成されるＥＡＰキーイングマテリアルを最終的に転送することによって必要な暗号化的結合を作ることができる。暗号化結合を達成するために、ＥＡＰ−ＥＸＴはＥＡＰキーイングマテリアルを生成できる内部ＥＡＰメソッドを必要とする。

ブートストラッピングケルベロス
１．序論
ケルベロス[RFC4120]は共有秘密キー暗号化を用いてオープン（非保護）ネットワーク上の各種ネットワークアプリケーションの端点（end-points）の同一性を証明する手段を提供する第三者認証プロトコルである。ケルベロスに対する拡張は認証プロトコル[RFC4556]のある段階中の公開キー暗号化の使用を準備できる。

EAP（拡張可能認証プロトコル）は“EAPメソッド”[RFC3748]として知られている複数の認証アルゴリズムをサポートする認証プロトコルである。しかしながら、EAPの適用はネットワークアクセス認証のためである。EAPは各種ネットワークアプリケーションに対して認証を提供するためには予定されていない。

参考として、以下の表はケルベロスとEAPとの差の幾つかを強調している表である。

新たなシングルサインオン（single sign-on）の必要性があり、シングルサインオンでは、ビジテッド又はホームドメインにおけるネットワークアクセスのための初期認証がリンク層からアプリケーション層に及んで、ドメイン内で使用される複数の異なるプロトコルにセッションキーを与えることができる。

特に、セッションキーをリンク層プロトコルに与えると、リンク層ハンドオーバ性能がauthenticator内及びauthenticator間ハンドオーバを含めてドメイン内でハンドオーバ毎にEAP信号経路を除去することによって最適化できる。

このセクションでは、EAPが初期ネットワークアクセス認証のために使用され、ケルベロスは複数の異なるプロトコルにセッションキーを付与するために使用されるEAPからケルベロスをブートする機構を説明する。このセクションでは、機構を実現するためにEAP-EXT暗号化が使用される。

２．EAP-EXTの再検討
幾つかの好適実施形態によると、新たなキャパビリティはケルベロスの新たなキャパビリティを含めて、（上述した）EAP-EXT暗号化内で定義される。

これらの実施形態はキャパビリティフィールドに新たなキャパビリティビット（Ｋ）を定義し、EAP-EXTの新たなＴＬＶｓ（例えば、KRB-BOOT TLV及びKRB-MSG TLV）も定義する。好適実施形態では、新たなキャパビリティビット（Ｋ）及びこれらの新たなＴＬＶｓは次のように使用される。

EAP-EXT交換においては、ピア及びサーバが機能性（BKEとしてここに参照されているような機能性）を使用することを望めばピア及びサーバはキャパビリティフィールドにKビットを設定する。ピア及びサーバの両者はAUTH TLVセットによってKビットを設定すれば、そのとき、好適実施形態では、システムは以下の方法で追加のEAP-EXT交換を使用する。

最初にサーバはケルベロスブートストラッピングパラメータをピアに送る。好ましくは、ケルベロスブートストラッピングパラメータはケルベロスブート(KRB-BOOT)TLVに含まれる。このとき、ピアはケルベロスAS-REQメッセージをケルベロスKDC(Key Distribution Center)に送る。このとき、信号伝達のこの部分がEAP-EXT外で行われる場合、KDCはAS-REPをサーバに戻す。AS-REPがKRB-MSG TLVに含まれる場合、サーバはAS-REPをピアに送る。

最後に、ピアは確認をサーバに送り、サーバはEAP成功又はEAP失敗メッセージをピアに送る。好適実施形態では、これら交換の全てはAUTH TLVによって保護される必要がある。

ケルベロスがEAPからブートされた後にケルベロスが使用される方法は環境に基づいて当業者によって決定でき、それに関する詳細はここでの目的のためには必要としない。

図１はBKEを持つEAP-EXTメッセージの例を示している。

３．新たなメッセージフォーマット
好適実施形態によると、上記で示すように、EAP-EXTのキャパビリティフラグの新たなビット、即ち新Kビットが定義される。

図４を参照して、好適実施形態に従ったEAP-EXTメッセージフォーマットへの変更について説明する。

KビットはEAP（ここではBKEと称する）からケルベロスをブートするためのサポートを示す。好適実施形態では、ピア及びサーバの両者は一度AUTH TLVセットによってKビットを設定し、それから付加交換が上述したようにEAP-EXT内で行われる。

４．新キー
好適実施形態では、１つの新キーがここで説明された機能性を提供するために定義される。この新キーはEAP-KRB-KEYと称される。EAP-KRB-KEYはケルベロスによって要求される事前共有キーとして使用される。好適実施形態では、ERP-KRB-KEYのレングス及び寿命はEAP-EXT内でサーバからピアに伝えられる。例えば、ERP-KRB-KEYのレングスがEAP-EXT内で取決められる。好適実施形態では、ERP-KRB-KEYキーは例えば、上記参照によって援用される文献[I-D.salowey-eap-emsk-deriv]に定義されたUSRK誘導アルゴリズムを用いてEAP-EXTから転送されるEMSKから次のように得られる。

EAP-KRB-KEY = KDF (EMSK, “EAP-EXT-Kerberos-Bootstrapping-Key”, length)
KDFでは, EAP-EXT-KRBは[I-D.salowey-eap-emsk-deriv]に明記されたデフォルトPRFを使用する。

５．新EAP-EXT TLVs
好適実施形態によると、次の新TLVsが定義される。

５．１．ケルベロスブート (KRB-BOOT) TLV
好適実施形態では、ケルベロスブートストラッピングパラメータを含む新ケルベロスブートTLV(タイプ６)が確立される。好適実施形態では、次のケルベロスブートストラッピングパラメータが出現順に含まれる。

ａ）EAP-KRB-KEYレングス (2オクテット)
好適実施形態では、このフィールドはEAP-KRB-KEYのレングスをオクテットで示す。

ｂ）EAP-KRB-KEY寿命（２オクテット）
好適実施形態では、このフィールドはEAP-KRB-KEYの寿命はＥＭＳＫの寿命を超える必要がある。

ｃ）主要名（可変長）
好適実施形態では、このフィールドはＡＳＮ．１（Abstract Syntax Notation One）のＤＥＲ（Distinguished Encoding Rules）によって符号化される、ピアのケルベロス主要名を含む。ＡＳＮ．１の有名な符号化ルールがＸ．５０９によって基本符号化ルール（ＢＥＲ）符号化を行う制約から得られる国際基準である。抽象シンタックス概念１（Abstract Syntax Notation One ：ASN.1)はコンピュータ間で送られているデータ構造がどのように符号化及び復号化されているかを制御する次のルールセット、即ち、基本符号化ルール（ＢＥＲ）；正規符号化ルール（ＣＥＲ）；有名符号化ルール（ＤＥＲ）；及びパック符号化ルール（ＰＥＲ）を定義する。オリジナルルールセットはＢＥＲ仕様によって定義された。ＣＥＲ及びＤＥＲはＢＥＲの特定サブセットとして最近開発された。ＰＥＲはＢＥＲ又はその改良型を用いてデータを送信するために必要な帯域幅量についての批判に応じて開発された。ＰＥＲは大きな省力をもたらす。ＤＥＲは安全なデータ転送のためＸ．５０９仕様の要求を満たすように作られた。例えば、証明登録（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を参照。これらの全開示は参照として援用される。

ｄ）レルム（可変長）
好適実施形態では、このフィールドはASN.1 (Abstract Syntax Notation One)のDER (Distinguished Encoding Rules)によって符号化された、ピア及びKDCのケルベロスレルムを含む。

ｅ）ＩＰアドレスレングス（１オクテット）
好適実施形態では、このフィールドはＫＤＣのＩＰアドレスを含む。

ｆ）ＫＤＣのＩＰアドレス（４又は１６オクテット）
好適実施形態では、このフィールドはＫＤＣの二進符号化ＩＰアドレスを含む。ＩＰアドレスレングスが４であれば、それは好ましくはＩＰｖ４アドレスを含む。ＩＰアドレスレングスが１６であれば、それは好ましくはＩＰｖ６アドレスを含む。

５，２．ケルベロスメッセージ(KRB-MSG) TLV
好適実施形態では、ケルベロスメッセージＴＬＶ（タイプ７）はAS-REQ及びAS-REPのようなケルベロスメッセージ（例えば、ＤＥＲ符号化メッセージ）を含む。

６．０具体的メセージ交換シーケンス
図５乃至９はコンポーネント又はモジュール間の具体的通信を記載した、幾つかの具体的メッセージ交換シーケンスを示す。

これに関して、図５乃至７はＢＫＥ機能を採用している幾つかの具体的実施形態に従ったメッセージシーケンスを示す。ここでは、図５はクライアント／ピア１０、サーバ３０及びキー配信センタ（ＫＤＣ）４０の間のメッセージシーケンスを示し、図６及び７はクライアント／ピア１０、サーバ３０、authenticator２０及びＫＤＣ（４０）の間のメッセージシーケンスを示す。

これに関して、クライアント／ピア１０は、好適実施形態では、例えば、携帯電話、パーソナルコンピュータ、卓上コンピュータ、ウェラブルコンピュータ、ＰＤＡなどのようなモバイルノード又は装置に含めることができる。この際、クライアント／ピア１０は（図６及び７に緑で表された）ＥＡＰピアの機能性及び（図６及び７に赤で表された）ケルベロスクライアントを含むことができる。

図５に示すように、クライアント／ピア１０、サーバ３０及びキー配信センタ（ＫＤＣ）４０の間のような通信がＢＫＥを採用する幾つかの実施例において次のようにできる。

最初に、図５にａ）で示すように、サーバ３０はＥＡＰリクエスト／アイデンティティをピア１０に選択的に送信でき、ピアは、図５にｂ）で示すように、ＥＡＰリクエスト／アイデンティティをサーバ３０に選択的に送信できる。

次に、図５のｃ）に示されるように、サーバ３０はＥＡＰリクエスト／ＥＸＴ｛Cap.(K),メソッド｝メッセージをピア１０に送信する。ここで、Cap.(K)はメッセージがキャパビリティフィールドセット有し、メソッドはメソッドＴＬＶに関することを示す。応答として、図５にｄ）で示されるように、ピア１０はＥＡＰレスポンス／ＥＸＴ｛Cap.(K),メソッド｝メッセージをサーバ３０に送信できる。

次に、図５にｅ）で示されるように、サーバ３０はEAP-リクエスト/EXT{Cap.(K), AUTH}メッセージをピア１０に送信する。ここで、Cap. (K)はメッセージがキャパビリティフィールドセットのＫビットを有し、AUTHがAUTH TLVに関連することを示している。応答として、図５にｆ）で示すように、ピア１０はEAP-レスポンス/EXT{Cap.(K), AUTH}メッセージをサーバ３０に送信できる。

次に、図５にｇ）で示すように、サーバ３０はEAP-リクエスト/EXT{Cap.(K), KRB-BOOT, AUTH}メッセージをピア１０に送信する。ここで、Cap. (K)はキャパビリティフィールドセットを有し、KRB-BOOTは（ケルベロスブートストラッピングパラメータを含む）ケルベロスブートＴＬＶに関連し、かつAUTHはAUTH TLVに関連する。応答として、図５にｈ）で示されるように、ピア１０はEAP-レスポンス/EXT{Cap.(K), KRB-MSG, AUTH}メッセージをサーバ３０に送信できる。ここで、AS-REQメッセージはケルベロスメッセージTLV (KRB-MSG)に含まれる。

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

更に、図５にｍ）で示されるように、サーバ３０はこのときAS-REQメッセージをケルベロスKDC（キー配信センタ）に送る。それから、図５にｎ）で示されるように、信号伝達のこの部分がEAP-EXT外で行われる場合、ＫＤＣはAS-REPメッセージをサーバに返す。

次に、図５にｉ）で示されるように、AS-REPがKRB-MSG TLVに含まれる場合、サーバ３０はAS-REPをピア１０に送る。その際、サーバ３０は図示のようにｉ）でEAP-リクエスト/EXT{Cap.(K), KRB-MSG, AUTH}メッセージを送信する。

最後に、ピアは確認をサーバに送り、サーバはEAPサクセス（成功）又はEAPフェイラ（失敗）メッセージをピアに送る。ここで、好ましくは、図５にｊ）で示されるように、ピア１０はEAP-レスポンス/EXT{Cap.(K),AUTH}メッセージをサーバ３０に送り、サーバ３０はEAPサクセスメッセージをピア１０に送る。

好適実施形態では、これら交換の全てはAUTH TLVによって保護される必要がある。

図６を参照して、この図は図５に示されるメッセージシーケンスと実質的に同じである。しかしながら、図６は更にauthenticator２０に関してメッセージ交換を示している。これに関して、図６にｘ）で示されるように図５に示されるステップｊ）後に、サーバはMSKをauthenticator２０に送信し、それからｙ）にて、安全関連性（Secure Association）がピア／クライアントとauthenticatorとの間に確立される。

図７はBKEを採用し、更にTGS-REQ/REPを含む幾つかの具体的実施形態に従った他のメッセージシーケンスである。背景参考のために、ケルベロスにおいて、クライアントはチケット付与サービス(TGS)にアプリケーションサーバと通信するために必要なチケットを問い合わせる。TGSによって生成されたチケットは全てアプリケーションサーバキーによって暗号化された、クライアントのアイデンティティ及びセッションキーを含む。TGSは全てクライアントキーで暗号化された、チケット及びセッションキーのコピーをクライアントに戻す。しかしながら、この交換はクライアントのアイデンティティのいかなる認証も単独で提供しない。クライアントのアイデンティティの認証はチケット検証に基づいてクライアントとアプリケーションサーバとの他の交換によって成される。TGSはチケットを発行することによってクライアントのアイデンティティに同意する。クライアント及びアプリケーションサーバはTGSによって発行されたチケットを検証することによってクライアントのアイデンティティに同意する。クライアントアイデンティティに関する第三者の同意は、チケットがセッションキーとクライアントのアイデンティティとの結合を持つ場合、クライアントとアプリケーションサーバとの間にセッションキーを保有する暗号証明に基づいて安全になされる。

図７を参照して、ｘ１）で示されるように、ピア１０はフォーマットEAPレスポンス/EXT {F, KRB-MSG (TGS-REQ), AUTH}のサーバ３０にメッセージを送信し、ｘ２）で示すように、サーバ３０はTGS-REQをKDCに送信する。このとき、KDCは図７にｙ２）で示すようにTGS-REPを返信する。次に、サーバ３０はメッセージをフォーマットEAPリクエスト/EXT {F, KRB-MSG (TGS-REP), AUTH}のピア１０へ送信する。このとき、ピアは上記と同様にEAPレスポンス/EXT {F, AUTH}を送信する。

参考のため、図８はアプリケーションクライアント（C）,アプリケーションサーバ（S）、及びキー配信センタ（KDC）を含む具体的なケルベロスメッセージシーケンスを示す。KDCはチケット信用サーバ（TGS）及び認証サーバ（AS）を含む。この具体的実施例では、３つのメッセージ交換ステップが示される。即ち、ａ）シーケンスのステップＳ１はauthenticatorを紹介し、ＴＧＴを取得する（この際、１００で示すように、AS_REQメッセージは認証サーバ（ＡＳ）に送信され、１１０で示すように、AS_REPメッセージが認証サーバから送信される）。ｂ）シーケンスのステップＳ２はＴＧＴを紹介し、チケットを取得する（この際、１２０で示されるように、TGS_REQメッセージがチケット信用サーバ（TSG）に送信され、１３０で示されるように、TGS_REPメッセージがTGSサーバから送信される）。

参考のために、図９はピア、authenticator及びサーバを含む具体的EAPメッセージシーケンスを示す。図では、メッセージ２００はサーバからのEAPリクエストを示し、メッセージ２０１はピアからのEAPレスポンスを示し、メッセージ２０２はサーバからのEAPサクセスメッセージを示し、メッセージ２０３はサーバからのMSKメッセージを示し、２０４は確立された安全関連性（下位層）を示す。ここでは、authenticatorはピアへネットワークアクセスサービスを提供する。幾つかの実施形態では、authenticator及びサーバは同じ装置で実行できるが、幾つかの実施形態では、authenticator及びサーバは分離された装置で実行できる。分離された装置で実行されるとき、authenticatorはピアとサーバとのEAPメッセージの「パススルー」転送者として機能する。

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 (ここでは[sha256]と称する). Arkko, J. and P. Eronen, "Authenticated Service Information for the Extensible Authentication Protocol (EAP) ", http://tools.ietf.org/html/draft-arkko-eap-service-identity-auth-04, October 2005 (ここでは[arkko-eap-service-identity-auth]と称する). Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005 (ここでは[RFC4306]と称する). Narayanan, V. and L. Dondeti, "EAP Re-authentication Extensions", draft-ietf-hokey-erx-02 (work in progress), July 2007 (ここでは[I-D.ietf-hokey-erx]と称する). Salowey, J., "Specification for the Derivation of Root Keys from an Extended Master Session Key (EMSK) ", draft-ietf-hokey-emsk-hierarchy-01 (work in progress), June 2007 (ここでは[I-D.ietf-hokey-emsk-hierarchy]と称する). Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos Network Authentication Service (V5)", RFC 4120, July 2005 (ここでは[RFC4120]と称する). Zhu, L. and B. Tung, "Public Key Cryptography for Initial Authentication in Kerberos (PKINIT)", RFC 4556, June 2006 (ここでは[RFC4556]と称する). 各種方式及び方法は知られているが、改良された方式及び方法の必要性がある。

本発明は、上述したシステム及び方法を含めて、既存のシステム及び方法を改良している。

幾つかの好適実施形態によると、メディア独立ハンドオーバキー管理アーチテクチャについて説明されている。これはサーバ、authenticator(オーセンティケイタ)及びモバイルノードの間で安全なキー配信のためケルベロスを使用している。このアーチテクチャによれば、好適実施形態では、キー配信のための信号伝達は再キーイングに基づいており、EAP（拡張可能認証プロトコル）及び初期ネットワークアクセス認証と同様なAAA（認証、許可及び課金）信号伝達を必要とする再認証から切り離される。このフレームワークでは、モバイルノードがハンドオーバ前にauthenticatorと通信しないでauthenticatorの組と安全関連性を動的に確立するために必要なマスタセッションキーを得ることができる。再キー動作を再認証から切り離すことによって、提案したアーチテクチャは事前動作モードに対してますます最適化される。それはモバイルノードと目標アクセスノードとの間でキー配信役目を逆転することによって動作反応モードをも最適化できる。

幾つかの好適実施形態によると、サーバ、authenticator及びケルベロス化ハンドオーバキーイングを採用しているモバイルノード間の確実なキー配信のためのメディア独立ハンドオーバキー管理システム及び／又は方法はａ）モバイルノードにAS-REQをキー配信センタに送信させ、モバイルノードにチケット付与チケット（Ticket Granting Ticket）でキー配信センタからAS-REPを受信させること、ｂ）モバイルノードに少なくとも１つのauthenticatorを見つけさせること、ｃ）モバイルノードにTGS-REQをキーは配信センタに送信させ、モバイルノードにTGS-REPをキー配信センタから受信させ少なくとも１つのauthenticatorのためのチケットを得ること、ｄ）少なくとも一つのauthenticatorの目標authenticatorに対するハンドオーバ中に、モバイルノードにAP-REQを目標authenticatorに送信させることを含む。幾つかの実施例では、本方法は更にモバイルノードにAP-REQを目標authenticatorに送信させること及び目標authenticatorにAP-REPメッセージをモバイルノードに送信させることを含む。幾つかの実施例では、本方法は更にモバイルノードに少なくとも１つのKRB-SAFEメッセージ又はリンク層特定SAPメッセージ（link-layer specific SAP messages）を目標authenticatorによって交換させモバイルノードとauthenticatorとの間にリンク層安全関連性（link-layer security association）を確立することを更に含む。幾つかの実施例では、本方法は目標authenticatorが認可のためのハンドオーバ後にAAA信号伝達しないでアクセス制御を行うようにチケット許可データに許可情報を埋め込ませることを含む。

幾つかの他の実施形態によると、サーバ、authenticator及びモバイルノードの間で確実なキー配信のためのメディア独立ハンドオーバキー管理アーチテクチャ（media-independent handover key management architecture）が提供される。この管理アーチテクチャはEAPサーバと通信するように構成されているEAPピアを持つモバイルノードを含む。このモバイルノードは個別のケルベロスクライアント又はサーバを持つ少なくとも１つのネットワークに対して少なくとも１つのauthenticatorと通信するように構成されるケルベロスクライアント又はサーバを更に有する。モバイルノードは少なくとも１つのauthenticatorを介して少なくとも１つの目標ネットワークに対してハンドオーバ中に安全信号伝達を行うように構成され、EAP及びAAAを用いて再認証することなく少なくとも１つのauthenticatorを介して安全関連性を動的に確立するためにケルベロスを用いてマスタセッションキーを得るためのネットワークアクセス認証及びキー管理信号伝達を含む。幾つかの実施例では、モバイルノードはケルベロスクライアントを有する。幾つかの実施例では、少なくとも１つのauthenticatorは複数のauthenticatorsを含み、モバイルノードは複数のauthenticatorsに対してauthenticator毎のキーを積極的に得るように構成される。幾つかの実施例では、複数のauthenticatorsは少なくとも１つのアクセスポイント又は基地局を含む。

幾つかの他の実施形態によると、サーバ、authenticator、モバイルノード間の安全キー配信のためのメディア独立ハンドオーバキー管理システム及び／又は方法は、ａ）EAPメソッドを用いてネットワークアクセス認証証明からブートストラッピングを介して初期ネットワークアクセス認証の間にモバイルノードにキー配信センタ及びアプリケーションサーバで共有される秘密キーを識別させること、及びｂ）モバイルノードにハンドオーバ前にケルベロスを用いて一組のauthenticatorsと安全関連性を確立させることである。幾つかの実施例では、本方法はモバイルノードにauthenticatorsの個々のケルベロスサーバと通信するケルベロスクライアントを含ませることを含む。幾つかの実施例では、本方法はモバイルノードにauthenticatorsの個々のケルベロスサーバと通信するケルベロスクライアント含ませることを含む。幾つかの実施形態では、本方法はauthenticatorへのモバイルノードのハンドオーバ前にチケット付与チケットをauthenticatorに配送することを含む。幾つかの実施例では、ブートストラッピングのために、EAPサーバ及びキー配信センタはEAPサーバアイデンティティ及びキー配信センタに対して同じ識別子を用いて同じノードで実行される。

上記及び／又は他の発明者、態様、特徴及び／又は各種実施形態の利点が添付図を参照して次の説明を鑑みて更に理解されるであろう。各種実施形態は適用可能な場合異なる態様、特徴及び／又は利点を含む及び／又は除外できる。更に、各種実施形態は適用可能な場合他の実施形態の１以上の態様又は特徴を組み合わせることができる。特定の実施形態の態様、特徴及び／又は利点の説明は他の実施形態又は請求項を限定するように解釈されるべきでない。

幾つかの実施形態に従った単一の内部方法を用いたEAPサーバとEAPピア間の具体的なEAP-EXTメッセージシーケンスを示す図である。 幾つかの実施形態に従った多数の内部方法を用いたEAPサーバとEAPピア間の具体的なEAP-EXTメッセージシーケンスを示す図である。 EAP-EXPに関する幾つかの典型的実施形態に従った具体的メッセージフォーマットを示す図である。 本発明の幾つかの典型的実施形態に従った具体的メッセージフォーマットを示す図である。 BKE機能性の幾つかの具体的実施形態に従ったメッセージシーケンスであり、クライアント／ピア、サーバ及びKDC間のメッセージシーケンスを示す。 BKE機能性の幾つかの具体的実施形態に従ったメッセージシーケンスであり、クライアント／ピア、サーバ、authenticator及びKDC間のメッセージシーケンスを示す。 BKEを採用し、更にTGS-REQ/REPを含む幾つかの具体的実施形態に従った他のメッセージシーケンスである。 参考のためのケルベロスメッセージシーケンスを示す背景図である。 参考のためのEAPメッセージシーケンスを示す背景図である。 発明の幾つかの実施形態に従ったケルベロス化ハンドオーバキーイングメッセージシーケンスを示す図である。 リアクティブオペレーションのために最適化される本発明の幾つかの実施形態に従ったケルベロス化ハンドオーバキーイングメッセージシーケンスを示す図である。 EAP機能性及びパススルーauthenticatorを備えたEAPを示す図である。 図８に示されるケルベロスメッセージシーケンスと同様なケルベロスメッセージシーケンスを示す背景図である。 事前モードにおいて、図１０Ａに示されたものと同様な、幾つかの実施形態に従ったケルベロスハンドオーバキーイングシーケンスを示す図である。 反応モードにおいて、図１０Ｂに示されるものと同様な、幾つかの実施形態に従ったケルベロスハンドオーバキーイングシーケンスを示す図である。 本発明の幾つかの事前モード及び反応モード実施形態に従った承認及び課金のためのAAA相互関係を示すアーチテクチャ図である。 AAAドメインと複数のケルベロスレルムとの実例関係を示す概略図である。 幾つかの実施形態に従ったケルベロスブートストラッピングキャパビリティを有するEAP-EXTメッセージフォーマットを示す図である。 幾つかの実施形態に従ったケルベロスブートストラッピングシーケンスを示す図である。 幾つかの実施形態に従った装置内に採用できる幾つかの具体的アーチテクチャ構成要素を示す図である。

本発明の好適実施形態は添付図において限定されないで一例によって示される。

本発明は多くの異なる形態で実施してもよいが、本開示は本発明の原理の実施例を提供するとして考慮されるべきであり、そのような実施例は本発明をここに説明され及び／又はここに示された好適実施形態に限定されると意図していないとの理解の下に複数の具体的実施形態が説明されている。

ケルベロス化ハンドオーバキーイング概要
ハンドオーバキーイングのためのケルベロス利用法
本発明の幾つかの好適実施形態によると、ハンドオーバキーイングのためにケルベロス使用法が採用される。その際、ケルベロスは、例えば、ケルベロスアップリケーションサーバを各ネットワーク接着点(point of attachment：PoA)（例えば、アクセスポイント、基地局及び／又はアクセスルータ）に配置することによってハンドオーバキー管理に利用可能にすることができる。

特に、この実施は次の及び／又は他の利点及び利益を達成できる。

ａ）EAP/AAAを用いた認証信号伝達はケルベロスレルム内でハンドオーバ毎に除外できる。

ｂ）同じフレームワークは、例えばFMIPv6, HMIPv6, DHCP認証などに対して任意の層で使用される任意のプロトコルをブートするために適用できる。

ケルベロス化ハンドオーバキーイングステップ
図１０を参照して、本発明の幾つかの具体的実施形態に従って、ケルベロスハンドオーバキーイングは次のステップを採用できる。

図１０Ａに示される実施形態では、第１ステップ、ステップ１，は初期接着点(PoA)を介して初期ネットワークアクセス認証の時にチケット付与チケットの取得を含む、この際、AS-REQ/AS-REP交換がRFC 4120 (i.e., Neuman, C., Yu, T., Hartman, S., and K. Raeburn, “The Kerberos Network Authentication Service (V5)”, RFC 4120, July 2005 ここに参照により援用される)に特定されているようにTCP又はUDPにわたって、若しくは（上述したようなEAPからケルベロスをブートする）BKEを持つEAP-EXTにわたって使用され及び搬送できる。図示のように、AS-REQは（例えば、モバイル装置又はノード内の）アプリケーションクライアントCからキー配信センタ(KDC)に送信されることになる。
図１０Ａに示される実施形態において、第２ステップ、ステップ２は候補PoA毎にPoA当たりの事前チケット取得（proactive per-PoA ticket acquisition）を含む。この際、TGS-REQ/TGS-REP交換がRFC 4120において特定されたようなTCP又はUDP若しくは上述したようなEAP-EXTにわたって使用され、転送される。そのような場合、クライアントＣはそれが引き継がれるかもしれないPoA毎にチケットを取得する。例えば、図９はクライアントＣが第１接着点PoA1を発見し、それに関連するチケットT1を取得し、そしてクライアントCが第2接着点PoA2を発見し、それに関連するチケットT2を取得する具体的な事例を示している。図示のように、接着点毎に、TGS-REQはアプリケーションクライアントCからキー配信センタ(KDC)に送信されることになり、TGS-REPはキー配信センタ(KDC)からアプリケーションクライアントCに送信されることになる。

図１０Ａに示される実施形態において、第３ステップ、ステップ３、は取得したチケットを用いて目標PoA(s)に対する安全関連性を確立することを含む。

このステップ３では、KRB-SAFE又はKRB-PRIV交換が選択的に後続するAP-REQ/AP-REP交換はRFC 4120において特定されているようにTCP又はUDPにわたり、若しくはIP接続性がなければリンク層にわたり使用及び配送できる。これらメッセージがリンク層にわたり配送される場合に、それらはａ）ケルベロス交換をサポートするための新たなEAP認証方法、又はｂ）ケルベロス交換をサポートするための新たなEAPコードを規定することによってEAPメッセージ内に取り込むことができる。そうでなければ、メディア特定情報がKRB-SAFE又はKRB-PRIV交換に取り込まれる。

このステップ３において、安全関連性信号送信の幾らかの部分はハンドオーバ前に積極的に行うことができる。例えば、AP-REQ/AP-REP交換は候補PoAsにおいてセッションキーの記憶個所を作成するためにハンドオーバ前に行うことができる。

PoAディスカバリ
上述のようにステップ２においてPoA当たりのチケットを取得するために、PoAsはステップ２においてPoA当たりのチケットを得ることを見つける必要がある。その際、PoAディスカバリを実施するために、IEEE 802.21情報サービスが採用できる。Draft Standard for Local and Metropolitan Area Networksと名称付けられた２００７年２月発行のI.E.E.E. P802.21^TM/D04.00を参照する。この全体の開示は省略せずに個々に記載されているように参照によって援用される。

キー寿命
チケットは寿命を有することは知られている。その際、この寿命は（サブ）セッションキー寿命を決定する。ここで、（サブ）セッションキーの寿命はチケット寿命より長くないことが必要である。

許可
幾つかの実施形態によると、許可情報がチケットに含めることができる。その際、（TGTsを含む）チケットの寿命はAAA許可寿命より長くない必要がある。ここで、Authenticatorはチケットがそのような許可情報を含むならば許可信号送信のためにAAA信号伝達を必要としない。そうでなければ、許可のためのAAA信号伝達は行われるべきである。

再キーイング
幾つかの好適実施形態によると、リンク層暗号キーの再キーイングはホームAAAサーバに行き着くまでEAP再認証無しに行うことができる。例えば、これはステップ２において新たなチケットを再発行し、それから上述のようにステップ３を実行することによって達成できる。

再認証
幾つかのケースでは、認証寿命を延ばす必要があればEAP再認証が必要となる。幾つかの好適実施形態では、これは新たなTGTを再発行し、それからPoA当たりのチケットを再発行することによって達成できる。

AAAドメイン間オペレーション（Inter-AAA Domain Operation）
AAAドメイン間オペレーションに関して、ケルベロスはクロスレルム動作を有利に可能にする。更に、１つはAAAドメイン当たりのケルベロスレルム（又は複数のレルム）を形成できる。

クロスレルム／ドメインオペレーションのために、クライアントはTGTをビジテッドレルム／ドメイン（visited realm/domain）に使用されるその局所ASから得る必要がある。

初期エントリ発行
幾つかの好適実施形態によると、初期PoAはBKEのためのEAP authenticatorとして作用する。幾つかの実施形態では、初期PoAはPMKを生成するためにEAP MSKを用いることができる。これは初期PoAがケルベロスをサポートしなければ使用されるべきである。幾つかの代替実施例では、初期PoAは成功したEAP認証後にステップ３を実行することによってPMKを生成するためにケルベロスチケットを使用できる。この後者の例では、ステップ1だけでなくステップ2もBKE内で行われる必要がある。更に、成功したEAP認証自体はこの後者の例において安全関連性をトリガしない。これは初期PoAがケルベロスをサポートすれば使用されるべきである。

リアクティブオペレーション（Reactive Operation）のために最適化されるケルベロス化ハンドオーバキーイング
幾つかの代替実施形態では、ケルベロス化ハンドオーバキーイングはリアクティブオペレーションのために最適化されるように変形できる。この際、幾つかの実施形態では、１０Aを参照した上記のケルベロス化ハンドオーバキーイングステップが変形できる。例えば、幾つかの具体的実施形態では、図１０Bに示されるように、下記のステップが採用できる。

第1ステップ１は初期接着点（PoA）を介して初期ネットワークアクセス認証のときにチケット付与チケット(TGT)取得を含めることができる。これは図１０Aを参照した上記通常動作と同じ方法で行うことができる。

第2ステップ2は目標PoAに対するPoA当たりのリアクティブチケット取得及びチケットを用いた目標PoAに対する安全関連性を含むことができる。この際、モバイルノード（MN）はトリガメッセージを目標PoAに送ることができ、又は目標ターゲットはリンク層指標を介してモバイルノードを見つけることができる。リアクティブオペレーション実施形態では、目標PoAはケルベロスクライアントとして作用し、モバイルノードのためにチケットを得るためTGS-REQ/TGS-REP交換を初期化する。目標PoAがモバイルノードのためのチケットを取得した後、それは（チケット導入のための）モバイルノードによってAP-REQ/AP-REP交換を初期化し、次いで（メデイア特定情報交換のための）KRB-SAFE or KRB-PRIV交換を初期化する、
幾つかの実施形態に関する追加の検討
このセクションはサーバ、authenticator及びモバイルノード間の安全キー配信のためケルベロスを使用するメディア独立ハンドオーバキー管理の具体的実施形態を更に説明する。このアーチテクチャに関して、キー配信のための信号伝達は再キーイングに基づいており、初期ネットワークアクセス認証と同様なEAP（拡張認証プロトコル）及びAAA(認証、許可及び課金)信号伝達を必要とする再認証から切り離される。このフレームワークでは、モバイルノードはハンドオーバ前に一組のauthenticatorsと通信しないでそれらとの安全関連性を動的に確立するために必要なマスタセッションキーを得ることができる。再認証から再キー動作を分離することによって、提案のアーチテクチャは事前動作モードに対してより最適化される。それはまたモバイルノードと目標アクセスノードとの間のキー配信役割を逆にすることによってリアクティブオペレーションモードのために最適化できる。このセクションはまたこの現アーチテクチャがどのように（例えば、IEEE 802.11及び802.16を含む）既存のリンク層技術に適用でき、複数のAAAドメインにわたることを示している。このセクションはまたどのようにケルベロスがEAPメソッドを用いて初期アクセス認証からブートできるかを説明している。

１．序論
無線ネットワーク技術は多くの異なるリンク層技術にわたりシームレスオーバヘッドを可能にするために発展している。例えば、I.E.E.E. 802.21（下記文献１を参照）はリンク層と上位層プロトコルに対する統一的インターフェースによってメディア独立ハンドオーバ(MIH)関数を定義している。この関数は幾つかのサービスをモビリティ管理エンティティに提供し、これらサービスを届けるためのプロトコルを遠隔モードで他のMIH関数に提供することによってハンドオーバを容易にする。ハンドオーバ中の安全信号伝達最適化はシームレスハンドオーバを達成するための重要な要素の一つであるが、それは最近ではI.E.E.E. 802.21仕様の範囲外である。ハンドオーバ中の安全信号伝達はネットワークアクセス認証及びリンク層暗号化のための次のキー管理信号伝達を含む。IETF（Internet Engineering Task Force）はEAP (Extensible Authentication Protocol)（下記文献［２］参照）を定義する。EAPはUDP/IP（例えば、下記文献［６］及び［７］参照）にわたってだけでなくイーサネット（登録商標）、I.E.E.E. 802.11及びI.E.E.E. 802.16（下記文献［３］［４］［５］参照）のような幾つかのリンク層技術にわたりさまざまな認証方法のサポートによってネットワークアクセス認証のための統一的機構を提供する。上述したように、EAPメソッドはピア（例えば、モバイルノード）とサーバ（例えば、バックエンド認証サーバ）との間で認証メソッドを実行する２グループ認証プロトコルであり、これに対して、EAPは図１１に示されるようにauthenticator（例えば、I.E.E.E. 802.11の場合のアクセスポイント）を介してEAPメソッドを搬送するためのコンテナ、即ちパススルーauthenticatorを持つEAPに過ぎない。

EAPはネットワークアクセス認証のためのメディア独立機構を提供するが、その基本設計はピアが特定のEAPメソッドを除いてハンドオーバにより１つのauthenticatorから他のauthenticatorに変更するときその信号伝達を最適化することを十分考慮していなかった。特定EAPメソッドはこの問題を扱うためにセッション回収を用いてエンハンスメントを与えることによってこの問題を扱う（例えば下記文献［８］参照）。しかしながら、そのようなエンハンスメントは他のEAPメソッドが初期ネットワークアクセス認証に使用されるとき利用できない。

最近、ハンドオーバ用EAP最適化のための機構及びプロトコルを定義するためIETFはHOKEY(ハンドオーバキーイング)ワーキンググループを着手した（例えば、下記文献［９］参照）。HOKEYワーキンググループは３つの要素、例えば低待ち時間再認証（又はHOKEY再認証）、ハンドオーバキー管理及び事前認証を定義している。HOKEY再認証は前回のEAPセッションによって生成されたキーイングマテリアルを利用してメッセージ往復を最小限にするためにEAPに拡張を定義する。ハンドオーバキー管理はサーバからauthenticatorsへのキー配信機構だけでなく複数のauthenticatorsに及ぶ新たなキー階層を定義する。事前認証はピアがサービングアクセスネットワークから候補目標authenticatorに対するEAPを実行する事前ハンドオーバ最適化技術である（例えば、下記文献［１０］参照）。

しかしながら、HOKEY要素に関する２つの問題がある。第１に、HOKEY再認証はピアにサーバと通信することをなおも要求する。このサーバは家に在住する又はビジタオペレータネットワークに属し、ピアの場所から物理的に離れている可能性のあるAAAサーバと通常同じ場所にいる。（注：ビジタオペレータネットワークのAAAサーバはオペレータのサブスクライバのためのホームAAAサーバとしても寄与する。）故に、HOKEY再認証がリアルタイムアプリケーションの性能に影響しない程度にハンドオーバ待ち時間を減少するのは困難である。第2に、HOKEY事前認証はモバイルノードの動きの正確な予想を必要とする。しかしながら、隣接ネットワークに多くの候補authenticatorsが存在するとき動き予測は困難である。

上述したように、好適実施形態は、とりわけ、HOKEYに関する問題を扱うためにケルベロスを用いるハンドオーバキー管理のためのケルベロスハンドオーバキーイングと呼ばれる新たなアーチテクチャを確立する（例えば、下記文献［１１］参照）。

好適実施形態では、ケルベロスハンドオーバキーイング（KHK）は次の特徴を提供する。即ち、ａ）KHKはモバイルノードが積極的にper-authenticatorキーを取得している限り認証及び許可のためにポストハンドオーバAAA信号伝達を必要としなく、ｂ）ポストハンドオーバ信号伝達待ち時間は下位層安全関連プロトコルのケルベロスチケット導入及び実行のためピアとauthenticatorとの若干のメッセージ交換に基づいてアクセスネットワーク内での伝搬遅延の程度まで減少されることが予想され、ｃ）KHKは各authenticatorがハンドオーバ前にモバイルノードのキーを記憶する必要がないので事前キーイングオペレーションのための必要なキーキャッシュのサイズを減少できる。

ネットワークアクセス認証及びキー管理のためにケルベロスを使用する既存ワークEAP-GSS（下記文献［１２］参照）がある。ワークは最初I.E.E.E. 802.11iの候補として考えられていた。しかしながら、KHKとは異なり、ワークはハンドオーバ最適化を考慮もしなく、任意のEAPメソッドが初期ネットワークアクセス認証のために使用されるのを可能にしない。

２．ケルベロスの追加的概略
上記の検討に加えて、ケルベロス（下記文献［１０］参照）は対称的キーに基づく３グループ認証及びキー管理プロトコルである。ケルベロスに３つの基本構成がある。即ち、クライアント、サーバ及びキー配信センタ(KDC)がある。更に、KDCは２つの特別なサーバ、即ち、認証サーバ（AS）及びチケット許可サーバ（TGS）を提供する。そのような事例では、各クライアント及びサーバは秘密キーに基づいてKDCとの事前に確立された信頼関係を持つことが仮定とされる。ケルベロスにおいて、セッションを安全に確立するためクライアント及びサーバによって使用されるセッションキーはKDCによって生成され、クライアントに配信される。それから、クライアントは「チケット」を用いてセッションをサーバに配信し、又はクライアントが自らの証明に役立てるためにKDCによって生成される記録をサーバに配信する。チケットはクライアントのアイデンティティ、セッションキー、タイムスタンプ及び他の情報を含み、（チケットバージョン番号、領域及びサーバ名を除く）全てのそのような情報がKDCによってだけ共有されるサーバ秘密キーを用いて暗号化される。ケルベロスプロトコルは初期交換が一度だけ行われる場合に３つの交換を含む。ケルベロスシーケンスとして表記された図１２はケルベロスの代表的プロトコルシーケンスを示す。

図１２に示すように、初期交換（AS-REQ/AS-REP交換）において、クライアントはチケット付与チケット（TGT）、又は他のチケットをASから生成するために使用される特別のチケットを要求する。ASはTSG用セッションキー（TSGセッションキー）を含むTGTを生成し、クライアントとだけ共有される秘密キーによって暗号化されるTSGセッションキーのコピーと共にTGTをクライアントに送る。

第2交換、TGS-REQ/TGS-REP交換では、クライアントは同じTGSセッションキーを保有することをTSGが証明できるようにTGSセッションキーを用いて作られる証明と共にクライアントはサーバアイデンティティ及びTGTをTGSに送る。証明の確認が成功した後、TGSはサーバ用セッションキーを含むチケットを生成し、そのチケット及びクライアントとだけ共有される秘密キーによって暗号化されるセッションキーのコピーをクライアントに送る。

第3交換、AP-REQ/AP-REP交換において、クライアントがセッションキーを保有することをサーバが証明できるようにクライアントはセッションキーを用いてクライアントによって計算されたメッセージ認証コードと共に、第2交換に含まれるチケットを送る。AP-REPメッセージはクライアントがサーバを認証する必要がなければ省略できる。信用の確認が成功した後、クライアント及びサーバはこれらのアプリケーションプロトコルを保護するためにセッションキーを用いることができる。

3．ケルベロス化ハンドオーバキーイング(KHK)。

好適実施形態によると、ケルベロスハンドオーバキーイング(KHK)が採用される。ここでは、モバイルノード及びauthenticator（例えば、アクセスポイント又は基地局）がクライアント又はケルベロスのサーバとして作用する。

この際、クライアント及びサーバの役割はチケットがauthenticatorに送付されるときのタイミングに応じて逆転される。幾つかの実施形態によると、authenticatorへのチケット送付がハンドオーバ前に発生する事前モードが採用される。他方、実施形態によると、authenticatorへのチケット送付がハンドオーバ後に起きる反応モードが採用される。

事前モードはモバイルノードがハンドオーバ後にKDCと通信することを必要としないので事前モード実施形態は反応モード実施形態よりも最適化される。そのような事例では、ハンドオーバ後の信号伝達待ち時間が、ある実施形態では、I.E.E.E. 802.11i 4-方向ハンドシェイク（I.E.E.E. 802.11i 4-way handshake）（下記文献［４］参照）のためのものに類似し、ある例では20msec以下であるとして知られている（下記文献［１３］参照）。

好適実施形態によって、KHKアーチテクチャは事前モードにおいてさえ、ハンドオーバ前にモバイルノードのために任意の状態を作ることをauthenticatorに要求しない。好適実施形態では、最初に、モバイルノードはKDCのアイデンティティ及びセクション４において以下に記載されているようにブートストラッピング機構を用いて初期ネットワークアクセス認証中にASと共有する秘密キーを取得する。初期化後に、上記のセクション2で説明されているケルベロスの３つのステップが実行される。３つのステップは事前及び反応モードにおいて異なって実行される。これらの違いの詳細は3.1及び3.2に説明されている。

3.1事前モード
このセクションでは、事前モードはKHK事前モードと表記された図13を参照して説明する。最初に、モバイルノード（MN）はTGTを取得するためにKDCでAS-REQ/AS-REP交換を実行する。MNがセクション3.4で説明されているようにauthenticator発見機構を用いて１以上のauthenticators（例えば、事象D1,D2）を見つけると、それは発見されたauthenticator（例えば、A1及びA2）ごとにチケットを得るためにKDCによってTGS-REQ/TGS-REP交換を実行する。MNが発見したauthenticatorsの１つ（例えば、事象H1）に対してハンドオーバを作成すると、それはauthenticatorでAP-REQ/AP-REP交換を実行する（AP-REPメッセージは選択的である）。MNが異なるauthenticator（例えば、事象H2）に対して他のハンドオーバを作成すると、それはauthenticatorによってAP-REQ/AP-REP交換を実行する。この場合、モバイルノード及び目標authenticatorはクライアント及びケルベロスのサーバとしてそれぞれ作用する。

AP-REQ/AP-REP交換の後に、1以上の追加KRB-SAFEメッセージ又はリンク層特定SAP（Secure Association Protocol（安全関連性プロトコル））メッセージがモバイルノードとauthenticatorとのリンク層安全関連性を確立するためにモバイルノードと目標authenticatorとの間で交換される。これらメッセージはリンク層暗号組パラメータのようなリンク層特定パラメータを有する。KRB-SAFEメッセージの使用によってアーチテクチャはリンク層技術から独立できる。そして、各リンク層技術はKRB-SAFEに保有されるべきリンク層特定パラメータのフォーマット及びセマンティックスだけでなくモバイルノードとauthenticatorとの間にケルベロストランスポートを定義することを必要とするに過ぎない。IEEE 802.11の事例では、リンク層認証フレームがモバイルノードとauthenticatorとの間のケルベロストランスポートとして使用でき、802.11i 4-方向ハンドシェイクはKRB-SAFEメッセージの代わりにSAPとして使用できる。同様に、IEEE 802.16の事例では、新たなPKM (Privacy Key Management)メッセージタイプが移動局と基地局との間にケルベロスメッセージを搬送するよう定義でき、PKM 3-方向ハンドシェイクがKRB-SAFEメッセージの代わりにSAPとして使用できる。これらの両事例では、リンク層仕様に変更を加える必要がある。

3.2反応モード
このセクションでは、反応モードがKHK反応モードとして表記された図１４を参照して説明する。

まず、モバイルノード（MN）は事前モードと同じ方法で、TGTを得るためKDCによってAS-REQ/AS-REP交換を実行する。

しかしながら、反応モードでは、モバイルノード及び目標authenticatorのケルベロスの役割が逆転する、即ち、モバイルノードと目標authenticatorはサーバとクライアントとしてそれぞれ作用する。好ましくは、目標authenticatorに対するハンドオーバの後に、モバイルノードは最初にトリガメッセージを目標authenticatorに送る。それから、目標authenticatorはモバイルノード用チケットを取得するためにKDCによってTGS-REQ/TGS-REP交換を実行し、その後、モバイルノードによってAP-REQ/AP-REP交換を実行する（AP-REPメッセージはKRB安全又はSAP交換前にモバイルノード（MN）を認証するために必須である）。

AP-REQ/AP-REP交換後に、１以上の追加KRB-SAFEメッセージ又はリンク層特定SAP(Secure Association Protocol)メッセージがモバイルノードとauthenticatorとの間にリンク層安全関連性を確立するためにモバイルノードと目標authenticatorとの間で交換される。この交換は事前モードと同様の方法で行うことができる。

トリガメッセージが保護されていなければ、資源消費DoS (Denial of Service)攻撃が反応モードに対して可能性がある。従って、追加機構がそのようなDoS攻撃を緩和するために採用できる。

反応モードのためのハンドオーバ後の信号伝達待ち時間は実質的に事前モードの待ち時間＋authenticatorとKDC間の１往復になることが予想される。故に、反応モードのためのリアルタイムアップリケーションに対するハンドオーバ性能はKDCの位置に依存する。以下のセクション3.6に説明されるように、KDCはクロスレルムオペレーションを用いてauthenticatorsに近い位置に配置できる。しかしながら、ハンドオーバ性能はKDCの位置に依存しないので事前モードを使用することが反応モードにわたり多くの環境においてより望ましい。

3.3キー寿命
ケルベロスチケットはキー寿命を含むので、異機種リンク層技術（heterogeneous link-layer technologies）に対するキー管理に柔軟性を得るために、（限定されないが）リンク層タイプに依存する異なるauthenticatorsに対して異なるキー寿命（又はキー寿命が認証時間と同じであれば異なる許可寿命（authorization lifetimes））を割り当てることが可能である。

3.4 Authenticatorディスカバリ
KHKの事前モードにおいて、モバイルノードは隣接ネットワークにおいてauthenticatorsを見つける必要がある。authenticatorディスカバリ機構は少なくとも次の情報を得るために必要である。

・KDCからauthenticatorのためのチケットを得るときにモバイルノードが認識できるようにauthenticatorsのアイデンティティの発見。単一authenticatorアイデンティティは複数のネットワーク接着点（例えば、アクセス点、基地局及び／又はアクセスルータ）に対して使用できることを留意する。

・モバイルノードがAP-REQ/AP-REP交換に対してauthenticatorと通信できるようにauthenticatorのアドレスの発見。アドレスはリンク層アドレス又はIPアドレスでできる。単一authenticatorアイデンティティは複数のネットワーク接着点のために使用されるとき、authenticatorアイデンティティは複数のアドレスと関連する。

IEEE 802.11r（例えば、下記文献［１４］参照）において、ビーコンフレーム（Beacon frame）において通知されたR0KH-ID及びBSSIDはauthenticatorのアイデンティティ及びアドレスにそれぞれ対応するが、それはIEEE 802.11リンク層だけに適用できる。他方、メディア独立authenticatorディスカバリ機構（media-independent authenticator discovery mechanism）は、例えば、上述した全ての情報を提供するために望ましい。例えば、IEEE 802.21、情報サービス（例えば、下記文献［１］参照）を参照する。IEEE 802.21情報サービスはハンドオーバ意思決定プロセス（handover decision-making process）を容易にするために隣接ネットワークに関する種々の情報を提供し、任意のメディアを徹底的に調査するために設計されるのでIEEE 802.21情報サービスはそのような機構を提供できる。

3.5 許可及び課金
ケルベロスは許可情報がKDC発行許可データ要素によってカプセル化されるときチケットの許可データに埋め込むことを可能にする。KDCによって発行される許可証明がアクセス制御を行うためauthenticatorによって必要とされる全許可情報を含むならば、認証のためだけでなく許可のためにもハンドオーバ後にAAA信号伝達を廃止することを可能になる。

ケルベロス化ハンドオーバキーイングに使用される好適な許可モデルは次のように説明される。

・KDCを実施するノードは許可目的のためにAAAサーバと通信するためAAAクライアントも実施する。

・KDCがケルベロスクライアント（即ち、事前モードのモバイルノード又は反応モードのauthenticator）からTGS-REQメッセージを受信すると、それはケルベロスクライアントに対する許可情報をAAAクライアントに要請する。AAAクライアントはAAAプロトコルを用いてAAAサーバから許可情報を取得し、取得した情報をKDCに戻す。

・KDCはTGS-REPメッセージに含まれるべきチケットの許可データフィールドに許可情報を埋め込む。

好適実施形態では、許可モデルは次の２つの要求を有する。第1に、許可証明のフォーマット及びセマンティクスは相互接続のために標準化される。第2に、反応モードの事例では、許可情報は反応モードでのケルベロスクライアント（例えば、authenticator）がモバイルノードに使用されるべき許可情報を取得できるようにTGS-REPメッセージの暗号化データ部分に取り込まれる。

課金は既存のリンク層技術において行われるようにauthenticatorに行われ、例えば、authenticatorを実施し、課金のためのAAAクライアントをも実施するノードで行われる。課金記録を妥当な許可セッションと関連するため、好ましくは許可セッション識別子は許可証明に含まれる。幾つかの実施形態に従った許可及び課金のためのAAA相互作用が図15に示されている。許可及び課金に関して事前モードと反応モード間の注目すべき差はKDCが事前モードでモバイルノードを介してauthenticatorに許可情報を好ましくは間接的に通過させ、これに対してKDCが反応モードにおいてauthenticatorに許可情報を好ましくは直接的に通過させることである。

authenticatorノードのAAAクライアントも初期ネットワークアクセスのための認証機能性を持っている。

3.6 AAAドメインへのケルベロスレルムのマッピング
上述のように、ケルベロスは組織的境界にわたり動作するように設計されている。例えば、１組織のクライアントは他の組織のサーバに認証され得る。この際、ケルベロスサーバを実施する各組織の願望は自らの「レルム」を確立する。クライアントは登録されているレルム名は局所レルムと呼ばれる。

「レルム間」キーを確立することによって、２つのレルムのアドミニストレイタは局所レルムで認証されたクライアントが他のレルムのサーバに対してそのアイデンティティを立証することを可能にする。この際、レルム間キーの交換が各レルムのチケット許可サービスを他のレルムの主体として登録する。それから、クライアントは遠隔レルムチケット許可サービスのためのTGTをそのクライアント局所レルムから取得できる。そのTGTが使用されると、遠隔チケット許可サービスはTGTを解読するため（自己の標準TGSキーとは通常異なる）レルム間キーを使用する。好ましくは、遠隔チケット許可サービスによって発行されるキーはクライアントが他の領域から認証されたことをエンドサービスに示すことになる。

一般的に、ケルベロルレルム及びAAAドメインは独立している。しかしながら、単純化した具体例の代わりに、我々は典型的な実施面で妥当なモデルを導入する。ここで、我々はケルベロス化ハンドオーバキーイングがDNSドメイン名をケルベロスレルム名及びAAAドメイン名として使用するものとする。

D(n)はDNSメイン名がｎであるAAAドメインを示すものとする。Rnはレルム名がそれらの添え字nを含むケルベロスレルムのセットであるとする。KHKにおけるAAAドメインとケルベロスレルムとの関係は次のように表される。

D(n) = Rn
この式はAAAドメインがケルベロスレルムのセットを有すること及び特定のケルベロスレルムがケルベロスレルム名及びAAAドメイン名を用いて特定のAAAドメインに属するか否かをモバイルノードが伝えることができることを表している。具体的AAAドメインと複数の具体的ケルベロスレルムとの間のマッピングを示す具体的実施例がAAAドメインとケルベロスレルムとの例示的関係を表記した図１６に示されている。モバイルノードにできるだけ物理的に近づくような位置にKDCを配置することによって信号伝達待ち時間を減じるだけでなくKHKが拡張可能であるために単一AAAドメイン内に複数のレルムを定義することが望ましい。

好適実施形態では、AAAドメインにわたってシームレスハンドオーバをサポートするために、互いにローミング関係にある２つのAAAドメイン間にケルベロスレルム間キーが予め確立されることが望ましい。モバイルノードがAAAドメインを横切ってサービングauthenticatorから目標authenticatorに移動すると、それはホームAAAドメインの局所KDCに接触することによってビジテッドAAAドメインの遠隔KDCに有効なクロスレルムTGTを取得する。好ましくは、局所と遠隔レルム間に1以上の中間領域があれば、モバイルノードが認証路に沿ってTGT取得手順を繰り返す。局所KDCによって生成される許可証明は遠隔KDCに使用されたクロスレルムTGTに保存される必要がある。

２つのAAAドメインが一般的にはDNSドメイン階層の異なる分岐に属するので、認証経路の決定プロセスが重要である。この場合、認証経路は下記文献［１５］に明記されているように、KDCsの照会を用いて動的に決定し得る。更に、下記文献［１６］に記載されているように、TGT取得手順の繰り返しを排除するより最適化された機構も存在する。

ケルベロスのクロスレルムオペレーションも同じAAAドメイン内のハンドオーバに対して可能である。モバイルノードが同じドメイン内のケルベロスレルムを横切ってサービングauthenticatorから目標authenticatorに移動するとき、それはサービングKDC(即ち、サービングauthenticatorのためのKDC)に接触することによって目標KDC（即ち、目標authenticatorのためのKDC）に有効なcross-realm TGTを取得する。同じAAAドメイン内の２つのKDC間に1以上の中間レルムが存在する場合、好ましくはモバイルノードは認証経路に沿ったTGT取得手順を繰り返す。サービングKDCによって作成される認証証明は目標KDCに使用されるクロスレルムTGTに保存される必要がある。認証経路はDNSドメイン階層に基づいて構成できる。このDNSドメイン階層はインタードメインの事例よりも容易な認証経路を横切らせる。

反応モードでは、クロスレルムオペレーションに必要なTGT取得手順の繰り返しがモバイルノードの代わりに目標authenticatorによって行われる。これはモバイルノードとauthenticatorとの間のリンクにわたりケルベロスメッセージ交換を効果的に減少する。

４．EAPからのケルベロスブートストラッピング
複数のAAAドメイン間のローミングをサポートするために、機構は局所KDCの主要名及びそのためにできるだけ使用される秘密キーを動的に構成するために定義される。この目的のために、機構は、上述された及び以下の文献［１７］で検討された新たなEAPメソッドであるEAP-EXTを用いてネットワークアクセス認証証明からケルベロスをブートストラップすることを提示している。上述したように、EAP-EXTは任意のEAP認証メソッドをカプセル化するトンネルメソッドであり、新たに定義された機能性が可能とされるキャパビリティネゴシエーションを提供する。既存のEAPメソッドにどのような変更もしないでそれらをなおも用いながら利用できる新たな機能性を作るのでEAP-EXTは既存のEAP認証メソッドに対して下位互換性を与える。EAP-EXTは現在若干のキャパビリティ、例えば、チャネル結合及び再認証を定義する。しかしながら、これに関連して、新たなキャパビリティがケルベロスとしてEAP-EXTに加えられる。ケルベロスブートストラッピングのために付加的キャパビリティビット（例えば、‘K’ビット）を持つEAP-EXTメッセージフォーマットがケルベロスブートストラッピングキャパビリティを持つEAP-EXTメッセージフォーマットと表記された図１７に示されている。

好ましくは、ピア及びサーバの両方が内部EAP認証メソッドから転送されるキーを用いて保護された完全性である最終EAP-EXTメッセージ交換に‘K’ビットを設定すると、ピア及びサーバはケルベロスをブートする。次の情報、即ちａ）モバイルノードと局所ＫＤＣとで共有される秘密キー(EAP-KRB-KEY)の長さ及び寿命、ｂ）局所KDCの主要名及びレルム並びにｃ）局所KDCのIPアドレスがケルベロスをブートするために必要とされ、‘K’ビットが設定された最終EAP-EXT要求メッセージのケルベロスブート(KRB-BOOT) TLV (Type-Length-Value)で搬送される。

EAP-KRB-KEYは次のようにEMSK (EAP Master Session Key) からUSRK (Usage Specific Root Key) (例えば、下記文献[18]参照)として得られる。但し、KDFは文献［18］に定義されたキー導出関数を示し、lengthは取得キーの長さを示す。

EAP-KRB-KEY = KDF(EMSK, “EAP-EXT-Kerberos-Boot-Key”, length)
EAPサーバもケルベロスブートストラッピングシーケンスとして表記された図８に示されるようにKRB-BOOT TLVに搬送された情報を局所KDCにインストールする。但し、「メソッド」はEAPメソッドペイロードを保有するメソッドTLVを示し、AUTHは完全保護データを保有するAUTH TLVを示す。

ケルベロスブートストラッピング手順を簡単化するために、最も好ましくは、EAPサーバ及び局所KDCはEAPサーバアイデンティティ及び局所KDCに対して同じ識別子を用いて同じノードにおいて実行される。そうでなければ、秘密キーを秘密に搬送するために3グループキー配信プロトコルがEAPピア、EAPサーバ及び局所KDCの間でキー配信を必要とされることになる。

5.結末注記
上記セクションは複数の問題を扱うためケルベロスを用いて新たなメディア独立ハンドオーバキー管理アーチテクチャを説明し、また、アーチテクチャがどのように複数のAAAドメインにわたり働くかを説明し、かつケルベロスがEAPメソッドを用いてどのように初期アクセス認証からブートし得るのかを説明している。KHK手順を実施するときに、ケルベロスプロトコル、ケルベロスブートストラッピング及びケルベロスのリンク層搬送に対する変更を含めて、KHKに必要な一連のプロトコルを定義することが、例えば、I.E.T.F.及びI.E.E.E. 802のような標準体には望ましくなる。更に、セクション４で説明したような初期ネットワークアクセス認証からのブートストラッピングはKHKをブートするだけでなくSSO (Single-Sign On)のような多くの他のアプリケーション対するセキュリティをもブートすることを可能にする。

文献
下記の背景文献の全開示は参照としてここに援用される。

[1] “Draft IEEE Standard for Local and Metropolitan Area Networks: Media Independent Handover Services,” IEEE LAN/MAN Draft IEEE
P802.21/D05.00, April 2007.
[2] B. Aboba, L. Blunk, J. Vollbrecht, J. Carlson and H. Levkowetz, “Extensible Authentication Protocol (EAP),” RFC 3748, June 2004 (上述した文献[RFC3748]も参照).
[3] “IEEE Standard for Local and Metropolitan Area Networks Port-Based Network Access Control,” IEEE Std. 802.1X-2004.
[4] “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.
[5] “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.
[6] C. Kaufman, “Internet Key Exchange (IKEv2) Protocol”, December 2005 (上述した文献 [RFC4306]も参照).
[7] 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.
[8] B. Aboba, D. Simon, “PPP EAP TLS Authentication Protocol”, RFC 2716, October 1999.
[9] IETF HOKEY WG charter, http://www.ietf.org/html.charters/hokey-charter.html.
[10] A. Dutta, T. Zhang, Y. Ohba, K. Taniuchi, and J. Schulzrinne, “MPA assisted Optimized Proactive Handover Scheme,” Mobiquitous 2005.
[11] C. Neuman, T. Yu, S. Hartman and K. Raeburn, “The Kerberos Network Authentication Service (V5)”, RFC 4120, July 2005 (上述した文献 [RFC4120]も参照).
[12] B. Aboba, “EAP GSS Authentication Protocol”, http://tools.ietf.org/html/draft-aboba-pppext-eapgss-12, August 2002.
[13] 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.
[14] “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.
[15] K. Raeburn and L. Zhu, “Generating KDC Referrals to Locate Kerberos Realms”, Internet-Draft, work in progress, March 2007.
[16] 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.
[17] Y. Ohba, S. Das and R. Lopez, “An EAP Method for EAP Extension (EAP-EXT)”, Internet-Draft, work in progress, March 2007.
[18] 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.
具体的コンピュータアーチテクチャ
図１９は、幾つかの実施形態において、例えば、ピア、クライアント、サーバ、authenticators、モバイル装置、アクセスポイントなどのような装置又はエンティティによって行われるプロセスステップ及び通信を実行するために使用できる具体的コンピュータ又は同様な構成を示す。幾つかの実施形態では、そのような装置又はエンティティはバス３２６を介して一組の入出力（I/O）装置324と通信できる中央処理装置（CPU）322を含む。I/O装置324は、例えば、キーパッド及び／又は他の装置を含むことができる。また、装置は（例えば、アンテナなどを使用する）通信用の送信機、受信機及び／又は送受信機を含むことができる。この通信は、この開示に基づく当業者には言うまでもないような妥当な装置機能性を達成するために必要に応じて無線通信、有線通信などを含むことができる。CPU322はバス326を介してコンピュータ読み取り可能媒体（例えば、一般的な揮発性又は不揮発性データ記憶装置）328（以後、「メモリ328」）と通信できる。CPU322、I/O装置324、バス326及びメモリ328の相互関係は従来知られているものと同様にできる。メモリ328は例えば、データ330を含むことができる。メモリ328はソフトウェア338も記憶できる。ソフトウェア338はプロセスのステップを実行するための複数のモジュール340を含むことができる。一般的プログラミング技術がこれらのモジュールを実施するために使用できる。メモリ328は上記及び／又は他のデータファイルも記憶できる。幾つかの実施形態では、ここに記載されている種々の方法はコンピュータシステムを用いてコンピュータプログラム製品を介して実施され得る。この実施は、コンピュータ読み取り可能媒体（例えば、ディスケット、CD-ROM, ROM又は同種のもの）に固定され、モデム又は同様なもののようなインターフェース装置を介してコンピュータシステムに送信できる一連のコンピュータ命令を含むことができる。通信媒体は実質的に有形（例えば、通信ライン）及び／又は実質的に無形（例えば、マイクロ波、光、赤外線などを用いた無線媒体）であってもよい。コンピュータ命令は種々のプログラム言語で書くことができ及び／又は半導体装置（例えば、チップ又は回路）、磁気装置、光学装置及び／又は他の記憶装置のような記憶装置に記憶できる。種々の実施形態では、送信は任意の適当な通信技術を使用できる。

本発明の広い範囲
本明細書では、本発明の具体的実施形態を説明しているが、本発明は、本明細書で説明した様々な好ましい実施形態だけに限定されず、本開示に基づけば当分野の技術者によって理解されるはずの、等価の要素、改変、省略、（様々な実施形態にまたがる態様などの）組合せ、適合及び／又は変更を有するありとあらゆる実施形態を含むものである。特許請求の範囲における限定は、特許請求の範囲で用いられる言葉に基づいて幅広く解釈されるべきであり、本明細書において、又は本出願の出願中において記述される例だけに限定されず、これらの例は、非排他的であると解釈されるべきである。例えば、本開示において、「好ましくは」という用語は、非排他的であり、「それだけに限らないが、好ましくは」を意味する。本開示において、かつ本出願の出願中において、手段プラス機能又はステッププラス機能限定は、特定のクレーム限定について、この限定において、ａ）「〜の手段」又は「〜のステップ」が明記されている、ｂ）対応する機能が明記されている、及びｃ）構造、材料又はこの構造をサポートする動作が記載されていないという条件すべてが存在する場合に限り用いられる。本開示において、かつ本出願の出願中において、「本発明」又は「発明」という用語は、本開示内の１つ又は複数の態様を指すものとして使用され得る。本発明又は発明という言葉は、誤って重要度のアイデンティティと解釈されるべきではなく、誤ってすべての態様又は実施形態にわたって適用されるものと解釈されるべきではなく（すなわち、本発明はいくつかの態様及び実施形態を有すると理解されるべきであり）、また、誤って本出願又は特許請求の範囲を限定するものと解釈されるべきではない。本開示において、かつ本出願の出願中において、「実施形態」という用語は、任意の態様、特徴、プロセス又はステップ、これらの任意の組合せ、及び／又はこれらの任意の部分などを記述するのに使用され得る。いくつかの例では、様々な実施形態が重なり合う特徴を含み得る。本開示では、「例えば」を意味する「ｅ．ｇ．」という省略用語が用いられ得る。

Claims (21)

1. サーバ、オーセンティケイタ（authenticator）及びケルベロス化ハンドオーバキーイングを採用しているモバイルノードの間での安全キー配信のためのメディア独立ハンドオーバキー管理のための方法であって、
   ａ）EAPメソッドを用いてネットワークアクセス認証証明書からブートストラッピングケルベロスを介して初期ネットワークアクセス認証中にキー配信センタのアイデンティティ及びアプリケーションサーバと共有する秘密キーをモバイルノードに取得させ、モバイルノードにAS-REQをキー配信センタに送信させ、前記モバイルノードにチケット許可チケット（TGT）によって前記キー配信センタからAS-REPを受信させること、
   ｂ）前記初期ネットワークからハンドオーバする前に前記モバイルノードに前記モバイルノードがハンドオーバできる隣接ネットワークにおいて少なくとも一つのオーセンティケイタを発見させること、
   ｃ）前記初期ネットワークからハンドオーバする前にTGS-REQを前記キー配信センタに送信させること及び前記少なくとも１つのオーセンティケイタの各々に対して異なるチケット（T)を取得するために前記モバイルノードにTGS-REPを前記キー配信センタから送信させること、
   ｄ）前記モバイルノード及び前記目標オーセンティケイタがクライアント及びケルベロスのサーバとしてそれぞれ作用するように前記少なくとも１つのオーセンティケイタの目標オーセンティケイタへのハンドオーバ中に前記モバイルノードにAP-REQを前記目標オーセンティケイタに送信させること、
   を含む方法。
2. 前記オーセンティケイタのための前記個別のチケット（T)を用いて前記モバイルノードと前記目標オーセンティケイタとの間に安全関連性を確立することを更に含む、請求項１の方法。
3. 前記モバイルノードにAP-REQを前記目標オーセンティケイタに送信させた後に前記目標オーセンティケイタにAP-REPメッセージを前記モバイルノードに送信させることを更に含む、請求項１の方法。
4. 前記ステップｄ）の後に、前記モバイルノードと前記オーセンティケイタとの間にリンク層安全関連性を確立するために前記モバイルノードに少なくとも１つのKRB-SAFEメッセージ又はリンク層特定SAPメッセージを前記目標オーセンティケイタと交換させることを更に含む、請求項１の方法。
5. 前記モバイルノードに少なくとも１つのオーセンティケイタを発見させる前記ステップは前記モバイルノードにI.E.E.E. 802.21情報サービスディスカバリ機構を採用させることを含む、請求項１の方法。
6. 前記目標オーセンティケイタが許可のためのハンドオーバ後にAAA信号伝達なしにアクセス制御を行うように前記少なくとも１つのオーセンティケイタの各々に対して各前記異なるチケットのチケット許可データに許可情報を埋め込めさせることを更に含む、請求項１の方法。
7. 次の許可方法：
   ａ）キー配信センタを実行するノードに許可目的のためAAAサーバと通信するAAAクライアントを実行させ、
   ｂ）前記AAAクライアントにAAAプロトコルを用いてAAAサーバから許可情報を取得させ、前記取得情報を前記キー配信センタに戻させること、を実行することを更に含む、請求項１の方法。
8. 前記キー配信センタに前記許可情報を事前モードにおいて前記モバイルノードを介して前記目標オーセンティケイタに間接的に通過させることを更に含む、請求項７の方法。
9. 前記モバイルノードが遠隔ケルベロスレルムから遠隔ケルベロスレルムのチケット許可サービスのためのチケット許可チケットを取得できるように異なるケルベロスレルムに対してレルム間キーを確立することを更に含む、請求項１の方法。
10. 前記モバイルノードはAAAドメインをわたって初期オーセンティケイタから目標オーセンティケイタに移動すると、前記モバイルノードはホームAAAドメインの局所キー配信センタにコンタクトすることによってビジテッド目標AAAドメインの遠隔キー配信センタに有効なクロスレルムチケット許可チケットを取得するように、複数のAAAドメイン間にケルベロスクロスレルムキーを事前に確立することを更に含む、請求項９の方法。
11. 局所レルムと遠隔レルム間に1以上の中間レルムを有することをさらに含み、前記モバイルノードはレルム間の認証経路に沿ったチケット許可チケット手順を繰り返す、請求項８の方法。
12. 単一AAAドメイン内にクロスレルムオペレーションを持つことをさらに含み、同じAAAドメインにおいて局所レルムと遠隔レルム間に１以上の中間レルムが存在し、前記モバイルノードはレルム間の認証経路に沿ってチケット許可チケット手順を繰り返し、前記認証経路はこの認証経路の横断を容易にするためDNSドメイン階層に基づいて構成される、請求項９の方法。
13. サーバ、オーセンティケイタ及びモバイルノードの間で安全キー配信のためのメディア独立ハンドオーバキー管理アーチテクチャであって、
    ａ）EAPサーバと通信するように構成されるEAPピアを持つモバイルノードを具備し、前記モバイルノードは初期ネットワークアクセス認証のための初期オーセンティケーションで初期ネットワークにEAP信号伝達を行うように構成され、
    ｂ）前記モバイルノードは個別のケルベロスクライアント又はサーバを持つ少なくとも１つの目標ネットワークに対して少なくとも１つのオーセンティケイタと通信するように構成されるケルベロスクライアント又はサーバをさらに有し、
    ｃ）前記モバイルノードはネットワークアクセス認証を含めて前記初期ネットワークから前記少なくとも１つのオーセンティケイタを介して前記少なくとも１つの目標ネットワークへのハンドオーバ中に安全信号伝達を行い、EAP及びAAA信号伝達を用いて再認証を行わないで前記少なくとも１つのオーセンティケイタを介して安全関連性を動的に確立するためケルベロスを用いてマスタセッションキーを取得するキー管理信号伝達を行うように構成され、前記モバイルノードは前記モバイルノードがハンドオーバ前に前記少なくとも１つのオーセンティケイタと通信しないでハンドオーバできる前記少なくとも１つの目標ネットワークにおいて前記少なくとも１つのオーセンティケイタの個別の一つに対して安全関連性を動的に確立するためにケルベロスを用いて異なるプレオーセンティケイタマスタセッションキーを取得するように構成される、メディア独立ハンドオーバキー管理アーチテクチャ。
14. 前記モバイルノードはケルベロスクライアントを有する、請求項１３のメディア独立ハンドオーバキー管理アーチテクチャ。
15. 前記少なくとも１つのオーセンティケイタは複数のオーセンティケイタを含み、前記モバイルノードは前記複数のオーセンティケイタのための事前オーセンティケイタキーを事前に取得するように構成される、請求項１３のメディア独立ハンドオーバキー管理アーチテクチャ。
16. 前記複数のオーセンティケイタは少なくとも１つのアクセスポイント又は基地局を含む、請求項１３のメディア独立ハンドオーバキー管理アーチテクチャ。
17. ハンドオーバ前にケルベロスを用いて一組のオーセンティケイタと安全関連性を前記モバイルノードに確立させることを更に含む、請求項１の方法。
18. 前記オーセンティケイタの個別のケルベロスサーバと通信するケルベロスクライアントを前記モバイルノードに含ませることさらに含ませる、請求項１７の方法。
19. 前記モバイルノード前にチケット許可チケットをオーセンティケイタに配送することをさらに含む、請求項１７の方法。
20. ハンドオーバ前に前記モバイルノードのための状態を前記オーセンティケイタに作成させないことをさらに含む、請求項１７の方法。
21. 前記ブートのために、EAPサーバ及び前記キー配信センタは前記EAPサーバアイデンティティ及びキー配信センタに対して同じ識別子を用いて同じノードで実行される、請求項１７の方法。

Images