JP4791535B2 - 汎用ブートストラッピング・アーキテクチャ（ｇｂａ）において、移動ノードの識別子を認証のプリファレンスと共に提供する装置、方法およびコンピュータ・プログラム - Google Patents

Description

本発明の非限定的な例示的実施形態は、全般的に通信システム、通信方法および通信デバイスに関し、特に、通信システムで使用される認証および関連技術に関する。

背景

ここで以下の定義が使用される。
3GPP 第三世代パートナーシップ・プロジェクト（Third Generation Partnership Project）
AAA 認証、認可および課金（Authentication， Authorization and Accounting）
GAA 汎用認証アーキテクチャ（Generic Authentication Architecture）
GBA 汎用ブートストラッピング・アーキテクチャ（Generic Bootstrapping Architecture）
BSF ブートストラッピング・サーバ機能（Bootstrapping Server Function）
AKA 認証および鍵共有（Authentication and Key Agreement）
IM IPマルチメディア（IP Multimedia）
ISIM IMサービス識別モジュール（IM Services Identity Module）
NAI ネットワーク・アクセス識別子（Network Access Identifier）
MN 移動ノード（Mobile Node）
UE ユーザ装置（User Equipment）
EV-DO エボリューション・データ・オンリー（Evolution Data Only）

3GPP GBA（上記の米国特許仮出願第60/759,487号に別紙Aとして添付されている、3GPP TS 33.220「GAA：GBA」を参照のこと）のねらいは、3GPP AKAメカニズムを通してアプリケーション・セキュリティのために認証および鍵共有をブートストラップするメカニズムを規定することである。GBAは、3GPP2にも導入されようとしており、AKAの他にSMEKEY（CDMA1xシステム向け）およびMN-AAA Key（CDMA1x EV-DOシステム向け）などのレガシー鍵材料に基づくブートストラップも標準化される。結果として、3GPP2システムにおいて動作している場合、MNは、2つ以上の認証およびブートストラップ・メカニズムをサポートすることもあるし、またはサポートすることが必要とされることもある。そのため、MNおよびネットワークが、ブートストラップで使用されるアルゴリズム・セットを一致させるための技術が必要とされている。3GPP端末が3GPP2ネットワークをローミングしても（逆の場合も同じ）GBAを使用できるよう、3GPPネットワークおよび3GPP2ネットワークの両方をサポートする今後の端末にも、同じことが必要とされる。加えて、オペレータは、3GPPネットワークおよび3GPP2ネットワークの両方を同じ地理的位置に展開できる。そのような場合端末は、使用するブートストラップ・メカニズムもネットワークとネゴシエートしなければならない。

3GPPは、1つのみの認証およびブートストラップ・メカニズム、つまり、ダイジェストAKAメカニズムおよび3GPPにより定義されたアルゴリズムを用いるAKAプロトコルをサポートする。ダイジェスト認証とのAKAの使用は、ダイジェストAKAに規定されている（上記の米国特許仮出願第60/759,487号に別紙Bとして添付されている、IETF RFC 3310「ダイジェストAKA（Digest AKA）」を参照のこと）。

レガシー端末および非レガシー端末の両方がサポートされる必要があるため、3GPP2では、ネットワーク側で種々のブートストラップ・メカニズムがサポートされている。

MNは、認証および鍵生成メカニズム（AKA、MN-AAA、CAVEなど）を複数サポートすることも、事前に用意されたシークレットを複数有することもある。3GPP2では、メカニズム選択手順が定義されている。MNは、BSFへ送信する第１メッセージのペイロード内に、サポートされている認証機構のリストを挿入するよう命令されており、BSFが好む認証機構を選択できるようになっている。BSFが認証および鍵生成メカニズムを選択すると、BSFは正しいデータベースに接触して認証データを取得する。例えば、MNがMN-AAAをその他のメカニズムに加えてサポートしており、BSFがMN-AAAを選択すると、BSFはH-AAAに接触してチャレンジを取得する。

加えて、MNは1つまたは複数の識別子を有する。例えば、MNがISIMのアプリケーションを有する場合、MNはプライベート識別子を有する。MNがEV-DO端末である場合、MNはNAIを有する。MNが1x端末の場合は、MNはIMSIのような識別子を有する。

HTTP GETリクエストを送信することでMNがBSFに最初に接触するときに（上記の米国特許仮出願第60/759,487号に別紙Cとして添付されている、3GPP2 S.P0109-0、バージョン0.6、2005年12月8日、「汎用ブートストラッピング・アーキテクチャ（GBA）・フレームワーク（Generic Bootstrapping Architecture (GBA) Framework）」に基づく）、そのリクエストに識別子を挿入するよう命令されているため、これは問題を引き起こす。識別子の多くは、特定の認証および鍵生成メカニズムのみと共に使用できる（例えば、プライベート識別子はAKAのみと使用でき、IMSIはCAVEによってのみ使用でき、EV-DO NAIはMN-AAAによってのみ使用される）ため、MNは、識別子のうちの1つを選択してGETリクエストに含めることにより、暗に認証機構もあらかじめ選択する。すでに1つの特定の識別子が挿入されている状態では、BSFは、当該識別子を共に使用できるメカニズムを選択せざるを得ない。あるいは、MNの種々の識別子のマッピングがBSFによりアクセス可能であることが必要なこともあるが、この手法はいくつかの理由から望ましくないと思われる。
米国特許仮出願第60/759,487号 IETF RFC 3310「ダイジェストAKA（Digest AKA）」 3GPP2 S.P0109-0、バージョン0.6、2005年12月8日、「汎用ブートストラッピング・アーキテクチャ（GBA）・フレームワーク（Generic Bootstrapping Architecture (GBA) Framework）」

摘要

本発明は、その非限定的な例示的実施形態に基づき、ノードによりサポートされている認証機構のリストと、各認証機構に関連し対応する識別子とを備える第１メッセージを、無線ネットワーク（WN：wireless network）において受信すること；ノードから受信されたリストに少なくとも基づき、ブートストラップに使用される認証機構をWNにおいて決定すること；ならびに、決定された認証機構を対応する識別子と共に含む情報をノードへ送信される第２メッセージ内に含めること、を含む方法を提供する。

本発明は、その非限定的な例示的実施形態に基づき、コンピュータ可読媒体に統合されたコンピュータ・プログラムをさらに提供する。ノードのデータ・プロセッサによるこのコンピュータ・プログラムの実行は、ノードによりサポートされている認証機構のリストと、各認証機構に関連し対応する識別子とを備える第１メッセージを無線ネットワーク（ＷＮ）へ送信する動作；および、第１メッセージ内でノードにより提供されたリストからWNにより選択された認証機構に関連する情報を、対応する識別子と共に含む第１応答メッセージを、WNから受信する動作を含む。

本発明は、その非限定的な例示的実施形態に基づき、送信機及び受信機に組み合わされたデータ・プロセッサを含むデバイスをさらに提供する。このデータ・プロセッサは、デバイスによりサポートされている認証機構のリストと、各認証機構に関連し対応する識別子とを備える第１メッセージを、送信機を介してネットワークへ送信し、リストからネットワークにより選択された認証機構に関連する情報を、対応する識別子と共に含む第１応答メッセージを、受信機を介してネットワークから受信するよう動作可能である。

さらに本発明は、その非限定的な例示的実施形態に基づき、コンピュータ可読媒体に統合されたコンピュータ・プログラムを提供する。無線ネットワーク構成要素（WNE：wireless network element）のデータ・プロセッサによるこのコンピュータ・プログラムの実行は、ノードによりサポートされている認証機構のリストと、各認証機構に関連し対応する識別子とを備える第１メッセージをノードから受信する動作；ブートストラップに使用される認証機構を、ノードから受信されたリストに少なくとも基づき決定する動作；決定された認証機構に関する情報および対応する識別子を含む第１応答メッセージをノードへ送信する動作；ならびに、ノードがサポートする認証機構のリストおよび対応する識別子を、完全性が保護された形式で少なくとも含む、少なくとも部分的に完全性が保護された第２メッセージをノードから受信する動作を含む。

さらに本発明は、その非限定的な例示的実施形態に基づき、送信機及び受信機に組み合わされたデータ・プロセッサを含むネットワーク・デバイスを提供する。このデータ・プロセッサは、ノードによりサポートされている認証機構のリストと、各認証機構に関連し対応する識別子とを備える第１メッセージを、受信機を介してノードから受信するよう動作可能である。データ・プロセッサは、ブートストラップに使用される認証機構を、ノードから受信されたリストに少なくとも部分的に基づき決定し、決定された認証機構に関する情報および対応する識別子を含む第１応答メッセージを、送信機を介してノードへ送信するようさらに動作可能である。データ・プロセッサは、ノードがサポートする認証機構のリストおよび対応する識別子を完全性が保護された形式で含む、少なくとも部分的に完全性が保護された第２メッセージを、ノードから受信するようさらに動作可能である。

さらに本発明は、その非限定的な例示的実施形態に基づき、デバイスを提供する。デバイスは、このデバイスによりサポートされている認証機構のリストと、各認証機構に関連し対応する識別子とを備える第１メッセージをネットワークへ送信する手段；ならびに、リストからネットワークにより選択された認証機構を記述した情報および対応する識別子を含む第１応答メッセージを、ネットワークから受信する手段を含む。デバイスは、このデバイスによりサポートされている認証機構のリストの完全性を保護し、少なくとも部分的に完全性が保護された第２メッセージをネットワークへ送信する手段をさらに含み、この第２メッセージは、デバイスがサポートする認証機構のリストと、各認証機構に関連し対応する識別子とを、完全性が保護された形式で含む。

さらに加えて、本発明は、その非限定的な例示的実施形態に基づき、ネットワーク・デバイスを提供する。このネットワーク・デバイスは、ノードによりサポートされている認証機構のリストと、各認証機構に関連し対応する識別子とを備える第１メッセージをノードから受信する手段、ブートストラップに使用される認証機構を、ノードから受信されたリストに少なくとも部分的に基づき選択する手段、ならびに、選択された認証機構に関する情報および対応する識別子を含む第１応答メッセージをノードへ送信する手段を含む。受信手段は、ノードがサポートする認証機構のリストと、各認証機構に関連し対応する識別子とを含む、少なくとも部分的に完全性が保護された第２メッセージを、ノードから受信するようさらに動作可能である。

さらに加えて、本発明は、その非限定的な例示的実施形態に基づき、ネットワーク・デバイスにつながれたデバイスを有するシステムを提供する。デバイスは、送信機及び受信機に組み合わされたデータ・プロセッサを含み、このデータ・プロセッサは、デバイスによりサポートされている認証機構のリストと、各認証機構に関連し対応する識別子とを備える第１メッセージを、送信機を介してネットワーク・デバイスへ送信するよう動作可能である。ネットワーク・デバイスは、送信機及び受信機に組み合わされたデータ・プロセッサを含み、このデータ・プロセッサは、リストから認証機構を選択するよう動作可能である。デバイスは、ネットワーク・デバイスによりリストから選択された認証機構に関する情報および対応する識別子を含む第１応答メッセージを、受信機を介してネットワーク・デバイスから受信する。このデバイスのデータ・プロセッサは、少なくとも、デバイスによりサポートされている認証機構のリストおよび対応する識別子の完全性を、少なくとも部分的に保護し、送信機を介してネットワーク・デバイスへ第２メッセージを送信するよう動作可能であり、この第２メッセージは、認証機構のリストおよび対応する識別子を含む。

さらに加えて、本発明は、その非限定的な例示的実施形態に基づき、デバイスによりサポートされている認証機構のリストと、各認証機構に関連し対応する識別子とを備える第１メッセージをネットワークへ送信すること；およびリストからネットワークにより選択された認証機構に関する情報を、対応する識別子と共に含む第１応答メッセージを、ネットワークから受信することを含む方法を提供する。

詳細な説明

本発明の非限定的な例示的実施形態は、全般的に認証を対象とし、特に、3GPPにおいて定義され3GPP2にも導入されている、3GPP汎用ブートストラッピング・アーキテクチャ（GBA）を対象としている。図1は、一般的で非限定的なブートストラッピング・リファレンス・アーキテクチャを示す。図1では、ホーム・サブスクライバ・システム（HSS：Home Subscriber System）2、ホーム・ロケーション・レジスタ（HLR：Home Location Register）4、アクセス、認証および課金（AAA）サーバ6、BSF8、ネットワーク・アプリケーション機能（NAF：Network Application Function）10およびユーザ装置/移動ノード（ＭＮ）12、ならびにこれら構成要素間のインタフェースが示されている。適切な送信機（Tx：transmitter）および受信機（Rx：receiver）が、MN12、BSF8およびその他ネットワーク構成要素間で情報およびメッセージを伝達するために使用されていると想定される。本発明の非限定的な例示的実施形態は、ブートストラップが実行されるMN12とBSF8との間のUbインタフェースに関係した手順を主として取り扱う。なお、移動端末は3GPPではユーザ装置（UE）と呼ばれ、3GPP2では移動ノード（ＭＮ）と呼ばれる。これらの用語は本特許出願において、一般性を失うことなく同義的に使用できるものとし、加えてこれらはさらに一般化されて、デバイスまたはノードと呼ばれてもよいものとする。

本発明の非限定的な例示的実施形態により、MN12とネットワークとの間でブートストラップ用にサポートされているメカニズム/アルゴリズムをネゴシエートするメカニズムが提供される。

本発明の、非限定的な例示的実施形態により、MN12およびネットワーク構成要素（BSF8）が、GBA（3GPP2環境）で用いる認証およびブートストラップ・メカニズムについて一致するための解決策が提供され、加えて、メカニズムをどのようにして既存の3GPP手順に組み込めるかが定義される。MN12は、例えばデータ・プロセッサ（DP：data processor）12Bにつながれた記憶装置（MEM：memory）12Aにリスト11を格納することで、サポートする認証およびブートストラップ・メカニズムのリスト11を有すると想定される。加えて、記憶装置12Aは、DP12Bを本発明の種々の実施形態に従って動作させるプログラム・コードを含むと想定される。さらに、BSF8も、データ・プロセッサ（DP）8Bにつながれた記憶装置（MEM）8Aを含むと想定される。記憶装置8Aは、DP8Bを本発明の種々の実施形態に従って動作させるプログラム・コードを含むと想定される。

一般的に、MN12の種々の実施形態は、セル式電話、無線通信機能を有する携帯情報端末（PDA：personal digital assistant）、無線通信機能を有する携帯用コンピュータ、無線通信機能を有するデジタル・カメラなどの画像キャプチャ・デバイス、無線通信機能を有するゲーム・デバイス、無線通信機能を有する音楽記憶再生機器、無線でのインターネット・アクセスおよびブラウジングが可能なインターネット機器、ならびにそのような機能の組み合わせが組み込まれた携帯用ユニットまたは携帯端末を含み得るが、これらに限定はされない。他の実施形態では、電気相互接続および光相互接続の一方または両方など、ケーブルまたは配線を介する有線接続が代わりに使用されてもよいため、ノードは、無線リンクを介してネットワークと無線通信ができる送信機および受信機を含まなくてもよい。

記憶装置8Aおよび12Aは、ローカル技術環境に適した任意の種類でよく、半導体ベースの記憶デバイス、磁気記憶デバイスおよび磁気記憶システム、光学記憶デバイスおよび光学記憶システム、固定記憶装置および取り外し可能な記憶装置など、任意の適切なデータ格納技術を使用して実装されるとよい。データ・プロセッサ8Bおよび12Bは、ローカル技術環境に適した任意の種類でよく、非限定的な例として、汎用コンピュータ、専用コンピュータ、マイクロプロセッサ、デジタル信号プロセッサ（DSP：digital signal processor）およびマルチコア・プロセッサ構造に基づくプロセッサのうち、1つまたは複数を含むとよい。

概して、本発明の例示的な実施形態は、DP12Bなど、MN12のデータ・プロセッサにより実行可能なコンピュータ・ソフトウェアにより、もしくはハードウェア回路により、またはソフトウェアとハードウェア回路との組み合わせにより実装されるとよい。加えて、本発明の実施形態は、DP8Bなど、BSF8のデータ・プロセッサにより実行可能なコンピュータ・ソフトウェアにより、もしくはハードウェア回路により、またはソフトウェアとハードウェア回路との組み合わせにより実装されるとよい。

まず、2005年9月21日出願の、「汎用ブートストラッピング・アーキテクチャ（GBA）においてブートストラップ・メカニズム選択をもたらす方法、装置およびコンピュータ・プログラム（Method, Apparatus and Computer Program Product Providing Bootstrapping Mechanism Selection in Generic Bootstrapping Architecture (GBA)）」と題された、ガボール・バジコ（Gabor Bajko）およびタット・キョン・チェン（Tat Keung Chan）による、米国特許出願第11/232,494号を参照する。これは、参照によって、その内容全体を本願明細書に完全に再記述したかのように引用されたものとする。米国特許出願第11/232,494号は、上記の米国特許仮出願第60/759,487号に別紙Dとして添付されており、2005年6月13日出願の米国特許仮出願第60/690，528号および2005年6月21日出願の米国特許仮出願第60/692,855号（以下で数回参照される）の合衆国法典35巻（35U.S.C）第１19条（e）に基づく優先権を主張するものであり、その開示全体を参照によって本願明細書に引用したものとする。

ここでは、本発明の例示的な実施形態についてさらに論じる前に、理解が深まるよう、米国特許出願第11/232,494号で開示されている内容について論じる。これに関連し、以下では図2〜7が参照される。

米国特許出願第11/232,494号で開示されている非限定的な実施形態に従ったブートストラップ手順は、例示的実施形態において以下のステップを含み、これらは以下で図2に関連してさらに詳しく説明される。

A. MN12は、最初のブートストラップ・リクエストにおいて、サポートする認証機構のリスト11をリクエスト内でBSF8に示す。MN12はユーザの識別子も含める。

B. BSF8は、MN12から受信されたリスト11およびその他の情報（非限定的な例としては、BSF8自体がサポートするメカニズム、およびユーザ識別子に基づき読み出されたユーザ・プロファイルなど）に基づいて、ブートストラップに使用される認証機構を決定する。続いて、BSF8は選択された認証機構を進めるが、これは一般的に、認証チャレンジを用いて応答することを含む。加えてBSF8は選択された認証機構の指示も応答に含める。

C. MN12は、選択された認証機構に基づき生成されたチャレンジへの応答を含む、新たなHTTPリクエストをBSF8へ送信する。このメッセージは、MS12がサポートする認証機構の元のリスト11も含むが、ただし今回は完全性が保護されている。

D. BSF8は、チャレンジに対する応答が正しいかどうかを確認し、その応答が期待される応答と一致すれば、MNの認証は成功と見なす。認証が成功し、ステップCで受信されたリスト11がステップAのものと同一であれば、BSF8は、HTTP成功応答を用いてMNに応答する。この応答メッセージは、完全性が保護されている、選択された認証機構の指示も含むとよい。

E. MN12は、成功応答を受信し、選択された認証機構が指示の通りであることを確認するとよい。

一般的に、2つのパーティが互いを認証していないことが原因で、最初の2つのメッセージ（ステップAおよびB）は保護できないため、MITM攻撃者がメッセージAを傍受し、リスト内の強力な認証機構を削除してBSF8の選択対象のリスト内に脆弱な認証機構（単数または複数）のみを残すこともある。これは"ビッドダウン"攻撃を招き、たとえ両パーティ（例えばBSF8およびMN12）がより強力な認証機構をサポートしていても、ブートストラップ手順はより脆弱なものに基づかざるを得なくなる。米国特許出願第11/232,494号で開示されている非限定的な実施形態に従った手順では、MN12にステップCにおいて完全性が保護された形式でリストを再送させ、その結果、BSF8が、ステップAおよびCのリストが一致しない場合にMITM攻撃を検出できるようにすることにより、このような種類の"ビッドダウン"攻撃をなくす。

米国特許出願第11/232,494号で開示されている非限定的な実施形態の種々の態様を、ここでさらに詳しく説明するが、3GPPでは、Ubインタフェース（MN12とBSF8との間）はHTTPダイジェスト認証に基づく。同じメカニズムが3GPP2で採用されている。例えば、3GPPおよび3GPP2 AKAにはダイジェストAKAが使用される一方、CDMA1xおよびCDMA EV-DOシステム用のブートストラップでは、パスワード保護されたディフィー・ヘルマンを用いたHTTPダイジェスト認証（それぞれSMEKEYおよびMN-AAA Keyに基づく）が使用される（3GPPコントリビューション：「CDMA1xおよびCDMA1x EV-DOシステム用のブートストラップ手順」（3GPP2 contribution: "Bootstrapping procedures for CDMA 1x and CDMA 1x EV-DO Systems"）、3GPP2 TSG-S WG4、ポートランド（Portland）、2005年5月）。言い換えると、可能な認証およびブートストラップ・メカニズムは、少なくとも以下を含む：

3GPP AKA（アルゴリズムは指定されておらず、オペレータ特有）；
3GPP2 AKA（SHA-1が要求されるアルゴリズム）；
SMEKEYに基づくブートストラップ；および
MN-AAA Keyに基づくブートストラップ。

今後、より多くの認証機構が利用可能になると思われ、容易にMN-BSF選択手順に含めることが可能である。

あらゆる認証機構それぞれについて、ダイジェストの変形をIETFにおいて標準化する必要をなくすよう、サポートされている認証機構のリストおよび選択された認証機構をHTTPメッセージのペイロードに埋め込む方が、ダイジェスト認証のヘッダ中でこの情報を伝えるよりも好ましい。

図2は、認証機構の選択を伴うGBAブートストラップ手順のメッセージ・シーケンスを示しており、これは以下のように詳しく説明される。

1. MN12は、最初のブートストラップ・リクエストをHTTP GETの形式でBSF8へ送信する。MN12は、ユーザ識別子をAuthorizationヘッダに含める。さらに、サポートされている認証機構のリスト（［A，B，C］など）が、HTTPペイロード内に含まれる。

2. BSF8は、ブートストラップ・リクエストを受信すると、サポートされている認証機構のリストをペイロードから抽出する。抽出された認証機構、BSF8自体がサポートする認証機構のリスト、ユーザ・プロファイル（ユーザ識別子に基づき読み出される）、および場合によりその他の情報に基づき、BSF8はブートストラップに使用する認証機構を決定する。

3. BSF8は、HTTP 401 Unauthorized応答をMN12へ送信する。この応答は、選択された認証機構に基づく適切な情報を含む。例えば、3GPP AKAが選択された場合、WWW-Authenticateヘッダは、IETF RFC 3310「ダイジェストAKA」に従ったAKAパラメータを含む。加えて、ペイロードは、選択された認証機構（この場合はA）の指示を含む。さらに、ダイジェスト認証の保護品質（qop：quality of protection）が"auth-int"に設定され、ペイロードの完全性の保護が必要であることを表す。

4. MN12は、BSF8の選択をペイロードから読み出し、この選択に従って認証処理を続ける。これは一般的に、受信されたチャレンジおよび何らかの共有シークレットに基づき応答を計算することを含む。

5. MN12は、新たなブートストラップ・リクエストを、選択された認証機構に従い計算した応答と共にHTTP GETの形式でBSF8へ送信する。さらに、ペイロードはMN12がサポートする認証機構の元のリストを含む。qopが"auth-int"に設定されているため、この元のリストはダイジェスト応答の計算に含まれ、その結果、完全性が保護されている。

6. BSF8はまず、ペイロード内で示されたリストが、ステップ2で受信されたものと一致することを確認する。一致が確認された場合に限り、BSF8は選択されたメカニズムに基づく認証を続ける。これは一般的に、受信されたダイジェスト応答を確認すること、およびサーバ側の認証を目的としてサーバ応答を計算することを含む。

7. BSF8は、HTTP 200 OKメッセージを用いて応答し、認証およびブートストラップ動作の成功を示す。このメッセージは、BSFにより計算されたダイジェスト応答も含む。さらに、このメッセージは、MN12による参照用に、選択された認証機構の指示も含むとよい。同じくqopを"auth-int"に設定することにより、この指示も完全性が保護されている。

8. MN12は、選択された認証機構が、ステップ3で指示されたものと確かに同じであることを確認するとよい。なお、たとえ選択された認証機構をHTTP 200 OK応答に含めなくても、このメカニズムは完全に機能する。

9. BSF8およびMN12はどちらも、選択された認証およびブートストラップ・メカニズムに基づきブートストラップ・キーを得る。

図3は、上記のようにMITM攻撃者14がビッドダウン攻撃を試行した場合のシナリオを示している。以下は図3の各ステップの説明である。

1. 図2のステップ1と同じである。元のリスト11は、例えば、サポートされている3つのメカニズム、すなわちA、BおよびCを含む。

1a. メッセージ1はMITM攻撃者14により傍受される。元のリスト11はメカニズムCのみを含むリストと交換される。メカニズムCは、サポートされている3つの中で最も脆弱であると思われる。

2. BSF8はメカニズムCのみを含むリストを抽出し、その結果Cを選択して進める。

3. 図2のステップ3と同じである。メカニズムCが指示される。

4. MN12は、BSF8がメカニズムCを選択したと信じ、その結果それに合わせて進める。

5. 図2のステップ5と同じである。MN12はメカニズムCを進めるが、ペイロード内に完全性が保護されている元のリストの［A，B，C］を含めるため、MITM攻撃者14はメッセージに変更を加えることができない。

6. BSF8は、受信したリストの確認中に、ステップ2で受信したものと同一ではないことを発見する。BSF8は、ビッドダウン攻撃が加えられたと判断し、その結果、HTTP 403 Forbiddenメッセージを用いてブートストラップ手順を中止する。

あるいは、BSF8は、ステップ2で受信されたリストが、ユーザ・プロファイルに示されているものと一致しない場合にこの攻撃を検出し、この場合もブートストラップ手順の中止を決定するとよい。これは、図4のステップ1、2および3に示されている。

さらに、米国特許出願第11/232,494号で開示されている非限定的な実施形態によると、少なくとも1つの実施形態は、選択された認証機構のブートストラップ手順が、完了までにリクエスト/応答を3ラウンド以上必要とする場合に関する。例えば、ダイジェストAKAに基づくブートストラップは、完了までに2ラウンドのリクエスト/応答を必要とする。先の実施形態でも、SMEKEYおよびMN-AAA Keyに基づくブートストラップが2ラウンドのリクエスト/応答を必要とし得る場合について説明しているが、3ラウンド以上のリクエスト/応答が必要とされる場合もあると思われる。そのような場合でも、米国特許出願第11/232,494号で開示されている非限定的な実施形態は当てはまる。このシナリオは図5に示されており、以下のように説明される。

1. MN12は、最初のブートストラップ・リクエストにおいて、サポートする認証機構のリスト（｛A，B，C｝など）をリクエスト内でBSF8に示す。MN12はユーザ識別子も含める。多くの場合、このリストは保護されていないと想定される。

2. BSF8は、MN12から受信されたリストおよびその他の情報（BSF8自体がサポートするメカニズム、およびユーザ識別子に基づき読み出されたユーザ・プロファイルなど）に基づいて、ブートストラップに使用される認証機構を決定する。非限定的な例として、図5では、メカニズムAが選ばれると想定される。

3. 次に、BSF8は選択された認証機構を進めるが、これは一般的に、認証チャレンジを用いて応答することを含む。BSF8は、選択された認証機構（この例ではメカニズムA）の指示もこの応答に含める。この場合も、この指示は保護されていないと思われる。

なお、ここから先MN12およびBSF8は、選択されたメカニズム（例えば、図5に示されているようにメカニズムA）を続ける。上記の通り、異なるメカニズムでは、ブートストラップ手順の完了までに異なるラウンド数のメッセージ交換（リクエスト/応答など）が必要とされると思われる。例えば、ダイジェストAKAメカニズムでは、ステップ3の後、完了までにリクエスト/応答がもう1つ必要である。一方、CAVEおよびMN-AAA Keyに基づくブートストラップでは、さらに複数のラウンドが必要とされることもある。この発明の例示的な実施形態によれば、これらの後続メッセージの1つにおいて、MN12は元のリスト11（メッセージ1で送信された）を再度送信するが、これは保護されている（完全性の保護など）。一方BSF8は、選択されたメカニズム（メッセージ3で送信された）を再度送信するとよいが、これは保護されている（完全性の保護など）。なお、MN12が元のリスト11を保護された状態で再度送信しても、BSF8が選択されたメカニズムを保護された状態で再度送信するかどうかは任意選択である（ただし好ましい）。このようなパラメータが保護された状態で再度送信されれば、もう一方のパーティは、送信されたパラメータが受信した元のパラメータと同じであることを確認して、保護されずに送信された元のパラメータを変更しようとするMITM攻撃者の試行をすべて検出できる。以下の説明では、パラメータを保護する例示的な技術として完全性の保護が採用されている。当然のことながら、パラメータは暗号化されてもよい。

4. さらに図5を参照すると、MN12は、ステップ4でメカニズムAに従い応答を計算する。

5-6. 説明した通り、MN12とBSF8との間で、複数ラウンドのリクエスト/応答があってもよい。これらのラウンドの一部では、選択されたメカニズムが、必要とされる完全性の保護をもたらすことができないこともある。そのため、MN12およびBSF8は、完全性が保護されたパラメータを送信できないこともある。

7. ブートストラップ手順のある特定の時点で、MN12が、完全性が保護されたデータを含むメッセージを送信できるとよい。例えば、このようなメッセージをMN12がメッセージ7で送信できると仮定する。その場合MN12は、図5においてP［｛A，B，C｝］で表されている、完全性が保護された元のリスト11（本例ではリスト｛A，B，C｝）を含める。

8. メッセージを受信すると、BSF8は、完全性が保護されたリストがメッセージ1内でMN12により最初に送信されたリストと同じであることを確認する。同じでない場合、BSF8はMN12へエラー応答を送信して動作を中止するとよい（図示せず）。あるいは、BSF8は通知なしで動作を中止してもよい。

9. ブートストラップ手順の特定の時点で、BSF8が、完全性が保護されたデータを含むメッセージを送信できるとよい。例えば、このようなメッセージをBSF8がメッセージ9で送信できると仮定する。BSFは、図5においてP［A］で表されている、完全性が保護されている選択されたメカニズム（本例ではメカニズムA）を含めるとよい。

10. メッセージを受信すると、MN12は、完全性が保護されている選択されたメカニズムがメッセージ2内でBSF8により最初に送信されたものと同じであることを確認する。同じでない場合、MN12はBSF8へエラー・メッセージを送信して動作を中止するとよい（図示せず）。あるいは、MN12は通知なしで動作を中止するとよい。

11. 成功すると、両パーティは、ブートストラップ・キーKsを選択されたブートストラップ・メカニズムに従って得ることができる。

なお、ステップ7および8、ならびに9および10（ある場合）は、説明された順である必要はなく、連続したメッセージである必要もない。つまり、BSF8が最初に、完全性が保護されたパラメータ（選択されたメカニズム）を伴うメッセージを送信してもよく、後からMN12が、完全性が保護されたパラメータ（サポートしているメカニズム）を伴うメッセージを送信してもよい。加えて、完全性が保護されたメッセージが送信される前後に、さらなるラウンドのメッセージがあってもよい。

以下の説明では、米国特許出願第11/232,494号で開示されている非限定的な実施形態に従った、HTTPダイジェスト認証（図6）およびプレーンHTTPトランスポート（図7）を使用した例示的な実装が提供される。なお、米国特許出願第11/232,494号で開示されている非限定的な例示的実施形態は、これら2つの例により限定されずに、他のトランスポート/認証機構を使用して実装することも同様に可能である（例えば、拡張可能認証プロトコル（EAP：Extensible Authentication Protocol））。以下の説明では、メカニズムのネゴシエーションに必要とされるパラメータ（MN12により送信される、サポートされているメカニズムのリスト11、およびBSF8により送信される、選択されたメカニズム）が、HTTPメッセージのペイロード内で送信されるものと想定されている。ただし、これらのパラメータは、HTTPメッセージ内の適切なヘッダ中で代わりに伝えられてもよい。

HTTPダイジェスト認証
この例示的な実装では、パスワード保護されたディフィー・ヘルマンを用いたHTTPダイジェスト認証が、ブートストラップに使用される。MS_AUTHおよび/またはBS_AUTHを使用し、初期設定のパスワード（"11...1"など）がダイジェスト・パスワードとして使用され、MN12とBSF8との間の相互認証が、パスワード保護されたディフィー・ヘルマン・メカニズムに実質的に基づくようにしてもよい。パスワードで保護されたディフィー・ヘルマン・メカニズムの詳細は、3GPP2において規定されている無線LAN相互接続の仕様書で説明されている、WKEY（無線LAN鍵（Wireless LAN Key））生成手順に基づく（2005年6月21日出願の米国特許仮出願第60/692,855号に別紙Dとして添付された、3GPP2 X.P0028「無線LAN相互接続（Wireless LAN interworking）」の第7.1.1節を参照のこと）。

図6は、選択されたメカニズムがCAVEである状態での、ブートストラップ・メカニズムのネゴシエーションの例示的な1つの実装を示しており、このCAVEを用いたブートストラップ手順は、全体で3ラウンドのHTTPリクエスト/応答を必要とする。MN-AAA Keyに基づくブートストラップのシナリオも非常に似ているため、さらに詳しくは説明されない。

以下は、図6に示されているステップのさらに詳しい説明である。

1. MN12は、HTTP GETリクエストをBSF8に対して送信する。"IMSI＠realm.com"という形式のユーザ識別子が、ユーザ名としてAuthorizationヘッダに含まれている。加えて、ユーザはサポートされているブートストラップ/認証機構のリスト11をペイロード内で送信する（例えば、MN12がCAVEおよびその他2つのメカニズム、BおよびCをサポートしていることを意味する、｛CAVE，B，C｝）。

2. BSF8は、サポートされているメカニズムのリストをペイロードから読み出し、リスト、ユーザ名、ユーザ・プロファイル、および/またはその他の情報に基づいて決定する。この非限定的な例では、BSF8は、ブートストラップ・メカニズムとしてCAVEを選択する。この時点から、ブートストラップはこの選択されたメカニズム、CAVEに基づく。BSF8は、32ビットのRANDチャレンジ値を生成する。

3. BSF8は、HTTP 401応答をMN12へ送信する。RANDは、base64エンコードされ、WWW-Authenticateヘッダのnonceフィールドで伝えられる。フィールド"qop-options"は"auth-int"に設定される。ペイロードは、CAVEが選択されたメカニズムであるという指示も含む。

4. MN12は、選択されたメカニズムをペイロードから抽出し、それに合わせて進める。CAVEでは、GBA機能により受信されたRANDチャレンジ値が、シミュレーテッド・グローバル・チャレンジ（simulated Global Challenge）としてR-UIM端末または1X端末へ送信される。

5. 1X端末（またはR-UIM）が、AUTHRおよびSMEKEYを用いてグローバル・チャレンジに応答する。その結果、AUTHRおよびSMEKEYがGBA機能に届けられる。

6. GBA機能が、MS_PWをSMEKEYに設定する。加えて、GBA機能は、ディフィー・ヘルマン法のための秘密の乱数"x"を生成する。さらに、GBA機能は、ダイジェスト認証用にclient nonceとして使用される32ビットの乱数、CRANDも生成する。

7. MN12は、もう1つのHTTP GETリクエストを、適切なAuthorizationヘッダと共にBSF8へ送信する。ダイジェスト応答は、RFC2617（2005年6月21日出願の米国特許仮出願第60/692,855号に別紙Cとして添付）に従い、初期設定のパスワードを使用して計算されると想定される。CRANDは、base64エンコードされ、cnonceフィールド内で伝えられる。HTTPペイロードは、AUTHRおよびMS_RESULT、つまりMS_PW＝SMEKEYの状態で、SMEKEYのハッシュにより保護されたg^x mod pを含む。

8. BSF8は、受信したMS_RESULTがゼロでないことを確認する。VLRとして機能しているBSF8は、AUTHREQをHLR/AC4’へ送信する。AUTHREQは、RAND、SYSACCTYPE＝GAAアクセスおよびAUTHRのパラメータを含む。ESNパラメータは全てゼロに設定される。SYSCAPパラメータは、Authenticationパラメータがこのシステム・アクセスでリクエストされたこと（bit-A＝1）および信号メッセージ暗号化がシステムによりサポートされていること（bit-B＝1）を示すよう設定される。SYSCAPパラメータのその他のビットは全てゼロに設定されることが好ましい。

9. HLR/AC4’は、AUTHRを確認してSMEKEYを生成する。

10. HLR/AC4’は、SMEKEYパラメータを含むTIA-41 AUTHREQを用いて応答する。認証が失敗した場合は、AUTHREQはアクセス拒否の指示のみを含む。

11. BSF8は、初期設定のパスワードを使用してダイジェスト応答を確認することでMN12を認証する。成功した場合、BSF8はBS_PW＝SMEKEYを設定して、ディフィー・ヘルマン法のための秘密の乱数"y"を生成する。

12. BSF8は、128ビットのKsを生成する。加えて、ステップ3からのbase64エンコードされたRAND値、およびBSF8サーバ名を取得することで、B-TID（Bootstrapping Transaction Identifier）値もNAIの形式で生成され、つまり、base64encode(RAND)＠BSF_servers_domain_nameとなる。

13. BSF8は、200 OK応答をMN12へ送信する。サーバ・ダイジェスト応答"rspauth"が、RFC 2617（2005年6月21日出願の、米国特許仮出願第60/692,855号の別紙C）に従い、初期設定のパスワードを使用して計算され、Authentication-Infoヘッダで伝えられる。加えて、200 OK応答のペイロードは、BS_RESULT、つまりSMEKEYのハッシュで保護されたg^y mod p、B-TID、鍵Ksの存続期間、選択されたメカニズム（CAVE）の指示およびBS_AUTHも含む。なお、BS_AUTHの計算にデータを含めることで完全性の保護をもたらすことができる。例示的な一方法は、以下の通りである。

BS_AUTH［data］＝SHA-1（0x00000005｜0x00000C80＋sizeof(data)｜BS_PARAM｜data｜BS_PARAM｜data）modulo 2¹²⁸

ここでdataは完全性の保護が必要な情報であり、この場合、B-TID、鍵の存続期間、および選択されたメカニズム（CAVE）の指示を含む。

14. MN12は、RFC 2617（2005年6月21日出願の米国特許仮出願第60/692,855号の別紙C）に従い、初期設定のパスワードを使用してrspauthを確認し、BS_AUTHがXBS_AUTH'と等しいことを確認する（BS_AUTHと同じ計算を使用）。加えてMN12は、指示されている選択されたメカニズムがCAVEであることを確認する。成功すると、サーバおよび送信されたメッセージは認証される。成功しなければ、MN12はブートストラップ手順を中止し、直ちにまたは後から再試行するとよい。

15. MN12は128ビットのKsを生成する。

16. MN12は、もう1つのHTTP GETリクエストを、適切なAuthorizationヘッダと共にBSF8へ送信する。初期設定のパスワードを使用してダイジェスト応答が計算される。ペイロードは、サポートされているメカニズムの元のリスト（この例では｛CAVE，B，C｝）およびMS_AUTHを含む。MS_AUTHの計算に保護が必要なデータを含めることで、完全性の保護をもたらすこともできる。例示的な一方法は、以下の通りである。

MS_AUTH［data］＝SHA-1（0x00000004｜0x00000C80＋sizeof（data）｜MS_PARAM｜data｜MS_PARAM｜data）modulo 2¹²⁸

ここでdataは完全性の保護が必要な情報であり、この場合、サポートされているメカニズムの元のリスト（｛CAVE，B，C｝）である。

17. BSF8は、初期設定のパスワードを使用してダイジェスト応答を確認し、MS_AUTHがXMS_AUTHと等しいことを確認することで（MS_AUTHと同じ計算）MN12を認証する。加えてBSF8は、サポートされているメカニズムのリストが、ステップ2で受信されたリストと同じであることを確認する。同じでない場合、BSF8はHTTP 403 Forbidden応答もしくはその他のエラー応答をMN12へ送信するか、または通知なしでブートストラップ手順を中止するとよい（図示せず）。

18. 成功すると、BSF8は200 OK応答をMN12へ送信する。

なお、上記の手順は数多くの変形が考えられる。しかし、米国特許出願第11/232,494号で開示されている非限定的な例示的実施形態に従った基本概念は変わらず、そのため、可能な変形全ては説明されない。1つの変形では、MS_AUTHおよびBS_AUTHが、ステップ16および17でそれぞれダイジェスト・パスワードとして使用され、この場合、"data"はMS_AUTHおよびBS_AUTHの計算に含まれなくてもよい。完全性の保護はこの場合、ダイジェスト認証機構により提供されることになる。さらに別の変形では、MN12側でMS_AUTH、BSF8側でBS_AUTHを使用せず、両方でMS_AUTHのみまたはBS_AUTHのみが使用される。この場合も、"data"はMS_AUTHまたはBS_AUTHの計算に含まれず、完全性の保護はダイジェスト認証機構により提供される。

プレーンHTTPトランスポート
この非限定的な例では、プレーンHTTPが、MN12およびBSF8がパスワード保護されたディフィー・ヘルマン・パラメータを交換するためのトランスポート・メカニズムとして使用される。MN12とBSF8との間の相互認証は、MS_AUTHおよびBS_AUTHを使用した、パスワード保護されたディフィー・ヘルマン・メカニズムに基づく。

図7は、選択されたメカニズムがCAVEである状態での、ブートストラップ・メカニズムのネゴシエーションの例示的な1つの実装を示しており、このCAVEを用いたブートストラップ手順は、3ラウンドのHTTP GET/応答を必要とする。MN-AAA Keyに基づくブートストラップのシナリオは非常に似ているため、ここには含まれない。以下は、ステップのさらに詳しい説明である。

1. MN12は、HTTP GETリクエストをBSF8に対して送信する。"IMSI＠realm.com"という形式のユーザ識別子がペイロードに含まれる。加えて、ユーザはサポートされているブートストラップ/認証機構のリストをペイロードに含める（例えば、MN12がCAVEおよびその他2つのメカニズム、BおよびCをサポートしていることを意味する、｛CAVE，B，C｝）。

2. BSF8は、サポートされているメカニズムのリストをペイロードから読み出し、リスト、ユーザ名（同じくペイロードから）、ユーザ・プロファイル、および/またはその他の情報に基づいて決定する。BSF8は、ブートストラップ・メカニズムとしてCAVEを選択し、この時点から、ブートストラップはこの選択されたメカニズム（例えばCAVEなど）に基づくと仮定する。BSF8は、32ビットのRANDチャレンジ値を生成する。

3. BSF8は、応答（200 OKなど）をMN12へ送信する。RANDは、base64エンコードされ、ペイロード内で伝えられる。ペイロードは、CAVEが選択されたメカニズムであるという指示も含む。

4. GBA機能により受信されたRANDチャレンジ値が、シミュレーテッド・グローバル・チャレンジとしてR-UIM端末または1X端末へ送信される。

5. 1X端末（またはR-UIM）が、AUTHRおよびSMEKEYを用いてグローバル・チャレンジに応答する。その結果、AUTHRおよびSMEKEYがGBA機能に届けられる。

6. GBA機能が、MS_PWをSMEKEYに設定する。加えて、GBA機能は、ディフィー・ヘルマン法のための秘密の乱数"x"を生成する。

7. MN12は、もう1つのHTTP GETリクエストをBSF8へ送信する。HTTPペイロードは、AUTHRおよびMS_RESULT、つまりSMEKEYのハッシュにより保護されたg^x mod pを含む。

8. BSF8は、受信されたMS_RESULTがゼロでないことを確認する。VLRとして機能しているBSF8は、AUTHREQをHLR/AC4’へ送信する。AUTHREQは、RAND、SYSACCTYPE＝GAAアクセスおよびAUTHRのパラメータを含む。ESNパラメータは全てゼロに設定される。SYSCAPパラメータは、Authenticationパラメータがこのシステム・アクセスでリクエストされたこと（bit-A＝1）および信号メッセージ暗号化がシステムによりサポートされていること（bit-B＝1）を示すよう設定される。SYSCAPパラメータのその他のビットは全てゼロに設定するとよい。

9. HLR/ACは、AUTHRを確認してSMEKEYを生成する。

10. HLR/ACは、SMEKEYパラメータを含むTIA-41 AUTHREQを用いて応答する。認証が失敗した場合は、AUTHREQはアクセス拒否の指示のみを含むとよい。

11. BSF8は、BS_PW＝SMEKEYを設定して、ディフィー・ヘルマン法のための秘密の乱数"y"を生成する。

12. BSF8は、128ビットのKsを生成する。加えて、ステップ3からのbase64エンコードされたRAND値、およびBSF8サーバ名を取得することで、B-TID値もNAIの形式で生成することができ、つまり、base64encode（RAND）＠BSF_servers_domain_nameとなる。

13. BSF8は、応答（例えば200 OK）をMN12へ送信する。応答のペイロードは、BS_RESULT、つまりSMEKEYのハッシュで保護されたg^y mod p、B-TID、鍵Ksの存続期間、選択されたメカニズム（CAVE）の指示およびBS_AUTHも含むことができる。なお、BS_AUTHの計算にデータを含めることで完全性の保護をもたらすことができる。例示的な一方法は、以下の通りである。

BS_AUTH［data］＝SHA-1（0x00000005｜0x00000C80＋sizeof（data）｜BS_PARAM｜data｜BS_PARAM｜data）modulo 2¹²⁸

ここでdataは完全性の保護が必要な情報であり、B-TID、存続期間、および選択されたメカニズム（CAVE）の指示を含む。

14. MN12は、BS_AUTHがXBS_AUTHと等しいことを確認する（BS_AUTHと同じ計算）。加えてMN12は、指示されている選択されたメカニズムがCAVEであることを確認する。成功すると、サーバおよび送信されたメッセージは認証される。成功しなければ、MN12はブートストラップ手順を中止し、直ちにまたは後から再試行することが好ましい。

15. MN12は128ビットのKsを生成する。

16. MN12は、もう1つのHTTP GETリクエストをBSF8へ送信する。ペイロードはMS_AUTHを含む。ペイロードは、サポートされているメカニズムの元のリスト（この例では｛CAVE，B，C｝）およびMS_AUTHも含むとよい。MS_AUTHの計算に保護が必要なデータを含めることで、完全性の保護をもたらすこともできる。例示的な一方法は、以下の通りである。

MS_AUTH［data］＝SHA-1（0x00000004｜0x00000C80＋sizeof（data）｜MS_PARAM｜data｜MS_PARAM｜data）modulo 2¹²⁸

ここでdataは完全性の保護が必要な情報およびサポートされているメカニズムの元のリスト（｛CAVE，B，C｝）である。

17. BSF8は、MS_AUTHがXMS_AUTHと等しいことを確認することで（MS_AUTHと同じ計算）MN12を認証する。加えてBSF8は、サポートされているメカニズムのリストが、ステップ2で受信したリストと同じであることを確認する。同じでない場合、BSF8はHTTP 403 Forbidden応答もしくはその他のエラー応答をMN12へ送信するか、または通知なしでブートストラップ手順を中止するとよい（図示せず）。

18. BSF8は、応答（200 OKなど）をMN12へ送信する。

なお、上記の手順は数多くの変形が考えられる。しかし、米国特許出願第11/232,494号で開示されている、非限定的な例示的実施形態に従い開示された基本概念は変わらない。

XMLスキーマの定義
3GPP GBAでは、ブートストラップが成功すると、最後の200 OK応答中で、B-TID（ブートストラップ・トランザクション識別子）および鍵の存続期間がHTTPペイロードにより伝えられる。関連するXMLスキーマが、3GPP TS 24.109の別紙Cで定義されている。3GPPは、このスキーマを拡張して、SMEKEYおよびMN-AAA Keyに基づくブートストラップに必要な他の情報をペイロードが伝えられるようにし、これら情報にはパラメータAUTHR（CAVEに関して）およびパスワード保護されたディフィー・ヘルマン・パラメータが含まれる。米国特許出願第11/232,494号で開示されている非限定的な実施形態では、認証機構のリストならびに選択されたメカニズムの指示を含めるよう、XMLスキーマのさらなる拡張が実現されている。考えられるスキーマの定義は以下の通りであり、米国特許出願第11/232,494号で開示されている非限定的な例示的実施形態に対応するために使われる拡張部分が、下線のついた斜体で示されている。

このスキーマでは、図2および3のメッセージ1および5において認証およびブートストラップ・メカニズムのリスト11を伝えるために、要素"auth_list"が使用されている。要素"auth"は、図2および3のメッセージ3および7においてBSFにより選択されたメカニズムの指示を伝えるために使用される。種類"authType"は、種々の標準における現行の認証およびブートストラップ・メカニズムを列挙したものと定義され、以下の例示的な値をとってもよい：

"3GPP-AKA"：3GPP AKAメカニズムに基づくブートストラップ；
"3GPP2-AKA"：3GPP2 AKAメカニズムに基づくブートストラップ；
"CAVE"：SMEKEY（CAVE）に基づくブートストラップ；および
"MN-AAA"：MN-AAA Keyに基づくブートストラップ。

より多くの認証機構がGBAにおいてサポートされると、新たな認証機構に対応する名前がauthTypeに追加される。

あるいは、"3GPP-AKA"および"3GPP2-AKA"の両方ではなく、"AKA"のみがスキーマにおいて定義されてもよい。その場合、AKAで実際に使用されるメカニズムが、ネットワーク・オペレータにより事前設定される。

なお、上記のスキーマは現実には具体例であり、その他の技術で同じ目的を達成することも可能である。加えて、スキーマを拡張して、ペイロード内で伝えられると有用な他の情報を含めてもよい。例えば、上記の、パスワード保護されたディフィー・ヘルマンを伝えるためのトランスポートとしてプレーンHTTPを使用している例示的な実装では、ペイロードは、ユーザ名、RAND、MS_AUTH、BS_AUTHなどのような他の情報を伝えることが好ましい。したがってスキーマは、これらのパラメータも伝えられるようしかるべく拡張されるとよい。

なお、上記の定義における認証機構名は具体例であり、一般性を失うことなく本願明細書で使用される。

当然のことながら、図1〜7に記載されている例示的な実施例は、単純、効率的かつセキュアであり、IETFにおける標準化の取り組みを必要とせず、将来的な認証およびブートストラップ・メカニズムをサポートするよう拡張可能であり、3GPPシステムおよび3GPP2システムの両方をサポートする。

米国特許出願第11/232,494号で開示されている非限定的な例示的実施形態に従った装置、方法およびコンピュータ・プログラムに基づき、ブートストラップ手順を実行するBSF8などのネットワーク・デバイスまたはネットワーク・ノード、およびMN12などのデバイスまたはノードにより実行される技術が提供される。このブートストラップ手順は、MN12が最初のブートストラップ・リクエストで、MN12がサポートする認証機構のリストを含む第１リクエスト・メッセージをBSF8へ送信すること；BSF8が、MN12から受信したリストに少なくとも基づき、ブートストラップに使用される認証機構を決定して選択された認証機構を進め、MN12への応答メッセージ内に決定された認証機構の指示を含めること；MN12がサポートする認証機構のリストを完全性が保護された形式で含む、少なくとも部分的に完全性が保護された第２リクエスト・メッセージを、決定された認証機構に基づき、MN12がBSF8へ送信することを含む。認証が成功し、第２リクエスト・メッセージ内で受信されたリストが第１リクエスト・メッセージ内で受信されたリストと一致すると、ネットワークは、選択された認証機構の指示を完全性が保護された形式で含む、少なくとも部分的に完全性が保護された成功応答メッセージを用いてMN12に応答するとよい。MN12は、成功応答メッセージを受信すると、MN12により使用された認証機構がBSF8により選択された認証機構と一致することを確認するとよい。加えて、MN12により送信された第１リクエスト・メッセージはユーザ識別子も含むとよく、このユーザ識別子は、BSF8により使用され認証機構の選択に役立てられるとよい。

この発明に基づく教示により、複数のメッセージ・ラウンドを適応させることが可能である。非限定的な例として、ネゴシエーションはダイジェスト認証により進められてもよいし、またはHTTPを使用して進められてもよい。

このように、米国特許出願第11/232,494号で開示されている発明の非限定的な例示的実施形態を説明してきたが、ここからは、本発明に従った、その非限定的な例示的実施形態について説明する。なお、本発明の例示的な実施形態は、米国特許出願第11/232,494号で説明されている発明の種々の例示的な実施形態の全てまたは一部と共に使用できる。

本発明の例示的な実施形態に基づき、サポートされている認証機構と、その特定のメカニズムと共に使用できる単数または複数の識別子（ids：identities）との間の"結びつき"を明確に特定するようXMLスキーマが変更される。1つの識別子が複数のメカニズムと共に使用できる場合、XMLスキーマは可能な組み合わせを全て記載することが好ましい。例えば次のようになる。
mechanism1 id1
mechanism1 id2
mechanism2 id3

ここで図8を参照すると、ペイロードとしてのXMLドキュメント（XMLスキーマに基づく）を伴う最初のHTTP GETメッセージがBSF8に受信されると（図8のメッセージ1）、BSF8は、ネットワークにより好まれるメカニズムを選択し、ブートストラップ手順を進めるために適切なデータベースに接触する。選択されたメカニズムが偶然2つ以上の識別子と共に使用できる場合（MN12によってHTTPペイロード内のXMLドキュメント内に記載されている）、BSF8は識別子のうちの1つを選択する。選択が実行されると、BSFによってGETリクエストへの401応答（図8のメッセージ5）内でMN12へ戻されるXMLドキュメントは、選択されたメカニズムおよび対応する関連の識別子を明確に特定する。

なお、XMLスキーマは、XMLドキュメントがどのように現れるかを定義する。次に、XMLドキュメントはHTTPメッセージのペイロード内で送信される。そのため、XMLスキーマは固定されていると見なされるとよく、ブートストラップ中には送信されない。なお、このXMLスキーマに従ったXMLドキュメントは、ブートストラップに必要とされる情報を伝達するようHTTPペイロードとして送信される。

上記の内容に従いブートストラップ手順のメッセージに挿入される識別子は以下の通りである。

A. MN12からBSF8へのHTTP GETリクエスト（図8のメッセージ1）

HTTP GETリクエスト内のAuthorizationヘッダは、MN12の識別子のいずれかを含むとよい。BSF8は、この時点ではこの識別子を利用しない。HTTPペイロード内のXMLドキュメントは、上記のように、サポートされているメカニズムのリストおよびMN12の識別子を含むことが好ましい。

B. BSF8からMN12へのHTTP 401 Unauthorized応答（図8のメッセージ5）

BSF8は、1つの認証機構および1つの対応する識別子を、MN12から受信されたHTTPペイロード内のXMLドキュメント内で発見されたリストから選択する。選択された認証機構および対応する識別子は、応答メッセージのペイロード内でMN12へ戻される。

C. MN12からBSF8へのHTTP GETリクエスト（図8のメッセージ7）

MN12は、先のメッセージのペイロード内でBSF8により戻された識別子を、HTTPダイジェスト認証でユーザ識別子として使用する（Authorizationヘッダ・フィールド）。続いて、MN12およびBSF8は、BSFにより選択された認証機構に従い進める。上記のように、HTTPペイロード内のXMLドキュメントは、サポートされているメカニズムおよびMN12の識別子を含むことが好ましい。メッセージ1とは異なり、この情報は完全性が保護されている。

D. BSF8からMN12へのHTTP 200 OK応答（図8のメッセージ9）

BSF8は、HTTP 200 OKメッセージを用いて応答し、認証およびブートストラップ動作の成功を示す。加えて、このメッセージは、BSFにより計算されたダイジェスト応答も含む。さらにこのメッセージは、選択された認証機構および対応する識別子の指示も、MN12の参照用に含む。同じく、qopを"auth-int"に設定することにより、この指示は完全性が保護される。

続いて、残りのブートストラップ手順は、上記の米国特許仮出願第60/759,487号に別紙Cとして添付された、3GPP2 S.P0109-0、バージョン0.6、2005年12月8日、「汎用ブートストラッピング・アーキテクチャ（GBA）・フレームワーク」で説明されているように続くとよい。この文書は、3GPP2 S.S0109-0、v1.0として発行される予定であり、現在の最新バージョンはS00-20060220-121A_SP0109_V＆V_changes.docである。

〔XMLスキーマの変更〕
現在のXMLスキーマは以下の通りである。

本発明の例示的な実施形態を実装するよう、前述のXMLスキーマに加えることができる変更がいくつか考えられる。以下は、本発明の例示的な実施形態の実践および/または使用を限定するものとしてではなく、具体例として読まれることを目的とした、いくつかの例である。

〔例１〕

XMLスキーマ１

以下は、前述のXMLスキーマに従った"auth_list"の例の「断片」である。

〔例２〕

XMLスキーマ２

以下は、このXMLスキーマに従った"auth_list"の例の「断片」である。

〔例３〕

XMLスキーマ３

以下は、"auth_list"および"clientid_list"の例の「断片」である。

図8は、上記のXMLスキーマ1を使用したコール・フローの例を示す。この例は、上記の米国特許仮出願第60/759,487号に別紙Cとして添付されている、3GPP2 S.P0109-0、バージョン0.6、2005年12月8日、「汎用ブートストラッピング・アーキテクチャ（GBA）・フレームワーク」の添付書類Cの図C.3-1から取得された。図8の例は、HTTPペイロード内の変更を強調しており、そのため、メッセージ1、5、7および9のみが、本発明の例示的な実施形態の理解に特に関連する。図の残りの部分は、添付書類Cで示されているものから変更がなくてよい。

メッセージ１． 最初のGETリクエスト（MN12からBSF8）

このメッセージの目的は、MN12とBSF8との間のブートストラップ手順を開始することである。MN12は、プライベート・ユーザ識別子を含むHTTPリクエストをBSF8に対し送信する。MN12は、サポートするブートストラップ・メカニズムのリストも、対応する識別子と共にメッセージのペイロード内で示す。

表：最初のGETリクエストの例（MN12からBSF8）
GET/HTTP/1.1

メッセージ５． 401 Unauthorized応答（BSF8からMN12）
BSF8は、HTTP 401 Unauthorized応答内で、チャレンジをMN8へ送信する（CK、IKおよびXRESなし）。これは、MN12に、MN12自体が本物であることを証明するよう要求するためである。チャレンジは、RANDおよびAUTINを含み、これらはRFC3310（上記の米国特許仮出願第60/759,487号に別紙Bとして添付されている、IETF RFC 3310「ダイジェストAKA」）に従いnonceフィールドに入れられる。

表： 401 Unauthorized応答の例（BSF8からMN12）
HTTP/1.1 401 Unauthorized

メッセージ７． GETリクエストの例（MN12からBSF8へ）
MN12は、応答計算に使用されるRESと共にHTTP GETリクエストを再度BSF8へ送信する。

表：GETリクエストの例（MN12からBSF8）
GET/HTTP/1.1

メッセージ９． 200 OK応答の例（BSF8からMN12）
BSF8は、200 OK応答をMN12へ送信して認証の成功を示す。

表：200 OK応答（BSF8からMN12）

前述の内容を踏まえると当然のことではあるが、本発明の例示的な実施形態により、ノードによりサポートされている認証機構のリストと、各認証機構に関連し対応する識別情報とを備える第１メッセージを、無線ネットワーク（ＷＮ）へ送信し、ブートストラップに使用される認証機構を、ノードから受信されたリストに少なくとも基づきWNにおいて決定し、ノードへの第１応答メッセージ内に、決定された認証機構に関する情報を対応する識別情報と共に含める方法、装置およびコンピュータ・プログラム（単数または複数）が提供される。

当然のことながら、本発明において、その例示的な実施形態の態様は、"認証機構"がHTTPペイロード内で送信されるときに対応する識別情報も含められるというものである。識別情報は、本願明細書において、一般性を失うことなく、識別子とも呼ばれる。このような点から、MN12からの第１リクエストおよび第２リクエストでは、サポートされているメカニズムのリストがHTTPペイロード内に含まれ、そのため対応する識別情報も含まれる。同様に、WNにより送信される第１応答および第２応答では、選択された認証機構がペイロード内に含まれ、対応する識別情報も含まれる。さらに、MN12からの第２リクエストはリストおよび対応する識別情報も含み、この情報は完全性が保護される。同様に、第２応答内に選択されたメカニズムおよび対応する識別情報がある場合、これらも完全性が保護されることが好ましい。

概して、種々の実施形態は、ハードウェアまたは専用回路、ソフトウェア、論理またはこれらの任意の組み合わせにおいて実装され得る。例えば、一部の態様をハードウェアに実装する一方、他の態様を、制御装置、マイクロプロセッサまたは他のコンピュータ・デバイスによる実行が可能なファームウェアもしくはソフトウェアに実装してもよいが、本発明はこれに限定はされない。本発明の種々の実施形態は、ブロック図、流れ図として、またはその他の図形表現を使用して図示および表現できるが、当然のことながら、本願明細書で説明されたこれらのブロック、装置、システム、技術または方法は、非限定的な例として、ハードウェア、ソフトウェア、ファームウェア、専用回路または専用論理、汎用ハードウェアもしくは汎用制御装置、もしくはその他コンピュータ・デバイス、またはこれらの何らかの組み合わせに実装されてもよい。

本発明の実施形態は、集積回路モジュールなどの種々の構成要素で実践することができる。集積回路の設計は全般的にみて、高度に自動化されたプロセスである。論理レベルの設計を、半導体基板上にすぐにエッチングおよび形成ができる半導体回路設計に変換するために利用できる、複雑かつ強力なソフトウェア・ツールが複数ある。

カリフォルニア州マウンテン・ビュー（Mountain View，California）のシノプシス社（Synopsys，Inc.）、およびカリフォルニア州サンノゼ（San Jose，California）のケイデンス・デザイン（Cadence Design）により提供されているようなプログラムは、確立された設計ルール、ならびに記憶済みの設計モジュールのライブラリを使用して、自動的に半導体チップ上に導体を経路付けし、構成要素を位置付ける。半導体回路の設計が完了すれば、結果として生じた設計が製造用に、半導体加工施設、つまり"fab（生産工場）"へ、標準化された電子形式（例えばOpus、GDSII、または同様のものなど）で伝送されればよい。

当業者であれば、前述の説明を添付の図面と共に読み考慮すると、種々の変更および適応がすぐに分かるであろう。非限定的な例として、他の種類のメッセージ・フォーマットなどが、デバイス12と無線ネットワーク構成要素（単数または複数）8との間の情報伝達に使用されてもよく、加えて/または他の種類の認証機構が、上で具体的に記載したものの代わりに、またはそれらに加えて採用されてもよい。なお、本発明の教示にいかなる変更を加えても、本発明の非限定的な実施形態の範囲に入る。

さらに、本発明の非限定的な種々の実施形態の一部の特徴を、他の特徴の使用を伴わずに使用し、役立ててもよい。このように、上記の説明は、本発明の原理、教示、例示的実施形態を説明するに過ぎず、本発明を限定するものではないと見なされるべきである。

3GPP2 GBAのリファレンス・ネットワーク・アーキテクチャを示すブロック図である。 認証機構の選択を伴うブートストラップ手順である。 MITM攻撃によるエラー・シナリオの例である。 MITM攻撃によるエラー・シナリオの別の例である。 複数ラウンドのメッセージ交換を使用するブートストラップ伴うメカニズム選択の例である。 図６の上半分である。図６は、HTTPダイジェスト認証を使用したネゴシエーションの非限定的な例である。 図６の下半分である。図６は、HTTPダイジェスト認証を使用したネゴシエーションの非限定的な例である。 図７の上半分である。図７は、プレーンHTTPトランスポートを使用したネゴシエーションの非限定的な例である。 図７の下半分である。図７は、プレーンHTTPトランスポートを使用したネゴシエーションの非限定的な例である。 本発明の例示的な実施形態に従った、認証機構の選択を伴うブートストラップ手順であり、出典は、上記の米国特許仮出願第60/759,487号に別紙Cとして添付されている3GPP2 S.P0109-0、バージョン0.6、2005年12月8日、「汎用ブートストラッピング・アーキテクチャ（GBA）・フレームワーク」の添付書類Cにある、図C.3-1：AKAに基づいたブートストラップの信号伝達（Bootstrapping signaling based on AKA）である。

Claims (48)

1. 汎用ブートストラッピング・アーキテクチャ（ＧＢＡ）において、ブートストラッピング・サーバ機能要素によって実行される方法であって、
   ノードによりサポートされている認証法のリストと、各認証法に対応する識別子とを含む第１のブートストラップ・リクエストを、前記ノードから受信することと；
   ブートストラップに使用される認証法を、前記ノードから受信した前記リストに少なくとも基づいて決定することと；
   前記決定された認証法に関する情報と、前記決定された認証法に対応する識別子とを含むエラー応答を、前記ノードへ送信することと；
   前記決定された認証法によって計算された応答情報と、前記ノードによりサポートされている認証法のリストとを含む第２のブートストラップ・リクエストを、前記ノードから受信することと；
   前記第２のブートストラップ・リクエストによって受信した前記リストが、前記第１のブートストラップ・リクエストによって受信した前記リストに一致する場合、前記決定された認証法による認証処理を続行することと；
   を含む方法。
2. 前記決定された認証法が２つ以上の識別子と共に使用可能であれば、前記識別子のうち、前記決定された認証法に関連付けられる１つを選択することをさらに含む、請求項１に記載の方法。
3. 前記応答情報は、前記ノードによりサポートされている認証法のリストに基づいて計算されたものである、請求項１または２に記載の方法。
4. 前記第２のブートストラップ・リクエストに使用された認証法が、前記決定された認証法と一致することを確認することをさらに含む、請求項１から３のいずれかに記載の方法。
5. 前記第１のブートストラップ・リクエストがHTTP GETリクエストにより実装され、該HTTP GETリクエストのHTTPペイロード内に前記リストを含める、請求項１から４のいずれかに記載の方法。
6. 前記エラー応答はHTTP 401 Unauthorized応答である、請求項１から５のいずれかに記載の方法。
7. 前記第２のブートストラップ・リクエストは、前記決定された認証法に従って計算された応答情報を含むHTTP GETリクエストである、請求項１から６のいずれかに記載の方法。
8. 前記第１のブートストラップ・リクエストによって受信した前記リストと、前記第２のブートストラップ・リクエストによって受信した前記リストとが一致した場合に、肯定応答を送信することを更に含む、請求項１から７のいずれかに記載の方法。
9. 前記肯定応答はHTTP 200 OKメッセージである、請求項８に記載の方法。
10. 汎用ブートストラッピング・アーキテクチャ（ＧＢＡ）において、ブートストラッピング・サーバ機能要素のデータ・プロセッサにより実行されることにより、該ブートストラッピング・サーバ機能要素に、
    ノードによりサポートされている認証法のリストと、各認証法に対応する識別子とを含む第１のブートストラップ・リクエストを、前記ノードから受信することと；
    ブートストラップに使用される認証法を、前記ノードから受信した前記リストに少なくとも基づいて決定することと；
    前記決定された認証法に関する情報および前記決定された認証法に対応する識別子を含むエラー応答を、前記ノードへ送信することと；
    前記決定された認証法によって計算された応答情報と、前記ノードがサポートする認証法のリストとを少なくとも含む第２のブートストラップ・リクエストを、前記ノードから受信することと；
    前記第２のブートストラップ・リクエストによって受信した前記リストが、前記第１のブートストラップ・リクエストによって受信した前記リストに一致する場合、前記決定された認証法による認証処理を続行することと；
    を含む処理を実行させる、コンピュータ・プログラム。
11. 前記処理が、
    前記第２のブートストラップ・リクエストによって受信した前記リストが、前記第１のブートストラップ・リクエストによって受信した前記リストに一致した場合に、肯定応答を送信することを更に含む、
    請求項１０に記載のコンピュータ・プログラム。
12. 前記処理が、
    前記第１のブートストラップ・リクエストに含まれるユーザ識別子に基づきプロファイルを読み出すことをさらに含み、前記決定することは、前記プロファイルを考慮に入れて行われる、請求項１０または１１に記載のコンピュータ・プログラム。
13. 前記第１のブートストラップ・リクエストがHTTP GETリクエストにより実装され、前記リストは該HTTP GETリクエストのHTTPペイロード内に含まれる、請求項１０から１２のいずれかに記載のコンピュータ・プログラム。
14. 前記エラー応答は、HTTP 401 Unauthorized応答として送信される、請求項１０から１３のいずれかに記載のコンピュータ・プログラム。
15. 前記第２のブートストラップ・リクエストは、前記決定された認証法に従って計算された応答情報を含むHTTP GETリクエストとして受信される、請求項１０から１４のいずれかに記載のコンピュータ・プログラム。
16. 前記肯定応答はHTTP 200 OKメッセージとして送信される、請求項１１に記載のコンピュータ・プログラム。
17. 汎用ブートストラッピング・アーキテクチャ（ＧＢＡ）のためのブートストラッピング・サーバ機能要素であって、送信機及び受信機と、前記送信機及び前記受信機に組み合わされたデータ・プロセッサとを備えるブートストラッピング・サーバ機能要素において、
    前記データ・プロセッサは、ノードによりサポートされている認証法のリストと、各認証法に対応する識別子とを含む第１のブートストラップ・リクエストを、前記受信機を介して前記ノードから受信するよう動作可能であり、
    前記データ・プロセッサは、ブートストラップに使用される認証法を、前記ノードから受信された前記リストに少なくとも部分的に基づき決定し、前記決定された認証法に関する情報および前記決定された認証法に対応する識別子を含むエラー応答を、前記送信機を介して前記ノードへ送信するようさらに動作可能であり、
    前記データ・プロセッサは、前記決定された認証法によって計算された応答情報と、前記ノードがサポートする認証法のリストとを少なくとも含む第２のブートストラップ・リクエストを、前記受信機を介して前記ノードから受信し、前記第２のブートストラップ・リクエストによって受信した前記リストが、前記第１のブートストラップ・リクエストによって受信した前記リストに一致する場合、前記決定された認証法による認証処理を続行するようにさらに動作可能である、
    ブートストラッピング・サーバ機能要素。
18. 前記データ・プロセッサは、
    前記第２のブートストラップ・リクエストによって受信した前記リストが、前記第１のブートストラップ・リクエストによって受信した前記リストに一致した場合に、肯定応答を送信することを更に含む、ようさらに動作可能である、請求項１７に記載のブートストラッピング・サーバ機能要素。
19. 前記データ・プロセッサは、前記第１のブートストラップ・リクエストに含まれるユーザ識別子に基づきプロファイルを読み出し、該プロファイルに基づいて前記決定を行うようさらに動作可能である、請求項１７または１８に記載のブートストラッピング・サーバ機能要素。
20. 前記第１のブートストラップ・リクエストがHTTP GETリクエストにより実装され、前記リストは該HTTP GETリクエストのHTTPペイロード内に含まれる、請求項１７から１９のいずれかに記載のブートストラッピング・サーバ機能要素。
21. 前記エラー応答は、HTTP 401 Unauthorized応答として送信される、請求項１７から２０のいずれかに記載のブートストラッピング・サーバ機能要素。
22. 前記第２のブートストラップ・リクエストは、前記決定された認証法に従って計算された応答情報を含むHTTP GETリクエストとして受信される、請求項１７から２１のいずれかに記載のブートストラッピング・サーバ機能要素。
23. 前記肯定応答はHTTP 200 OKメッセージとして送信される、請求項１８に記載のブートストラッピング・サーバ機能要素。
24. 汎用ブートストラッピング・アーキテクチャ（ＧＢＡ）のためのブートストラッピング・サーバ機能要素であって、
    ノードによりサポートされている認証法のリストと、各認証法に対応する識別子とを含む第１のブートストラップ・リクエストを、前記ノードから受信する手段と、
    ブートストラップに使用される認証法を、前記ノードから受信された前記リストに少なくとも部分的に基づき選択する手段と、
    前記選択された認証法に関する情報および前記選択された認証法に対応する識別子を含むエラー応答を、前記ノードへ送信する手段と、
    前記決定された認証法によって計算された応答情報と、前記ノードがサポートする認証法のリストとを少なくとも含む第２のブートストラップ・リクエストを、前記ノードから受信する手段と、
    前記第２のブートストラップ・リクエストによって受信した前記リストが、前記第１のブートストラップ・リクエストによって受信した前記リストに一致する場合、前記決定された認証法による認証処理を続行する手段と、
    を備える、ブートストラッピング・サーバ機能要素。
25. 前記第２のブートストラップ・リクエストによって受信した前記リストが、前記第１のブートストラップ・リクエストによって受信した前記リストに一致した場合に、肯定応答を送信する手段を更に備える、請求項２４に記載のブートストラッピング・サーバ機能要素。
26. 前記認証法の選択時に前記選択手段により使用されうるように、前記第１のブートストラップ・リクエストに含まれるユーザ識別子に基づきプロファイルを読み出す手段をさらに備える、請求項２４又は２５に記載のブートストラッピング・サーバ機能要素。
27. 汎用ブートストラッピング・アーキテクチャ（ＧＢＡ）において、移動ノードによって実行される方法であって、
    前記移動ノードによりサポートされている認証法のリストと、各認証法に対応する識別子とを含む第１のブートストラップ・リクエストを、前記汎用ブートストラッピング・アーキテクチャ（ＧＢＡ）のブートストラッピング・サーバ機能要素へ送信することと；
    前記ブートストラッピング・サーバ機能要素によって前記リストから選択された認証法に関する情報と、該選択された認証法に対応する識別子とを含むエラー応答を、前記ブートストラッピング・サーバ機能要素から受信することと；
    前記選択された認証法によって計算した応答情報と、前記リストとを含む第２のブートストラップ・リクエストを、前記ブートストラッピング・サーバ機能要素へ送信することと；
    を含む方法。
28. 前記第２のブートストラップ・リクエストの送信に応じて、前記選択された認証法に関する情報を含む肯定応答を、前記ブートストラッピング・サーバ機能要素から受信することをさらに含む、請求項２７に記載の方法。
29. 前記第１のブートストラップ・リクエストはHTTP GETとして送信され、前記リストは前記HTTP GETのHTTPペイロード内に含まれ、前記エラー応答はHTTP 401 Unauthorized応答として受信される、請求項２７ままたは２８に記載の方法。
30. 前記第２のブートストラップ・リクエストはHTTP GETとして送信される、請求項２７から２９のいずれかに記載の方法。
31. 前記肯定応答はHTTP 200 OKメッセージとして受信される、請求項２８に記載の方法。
32. 前記肯定応答により示される認証法が、前記エラー応答により示される認証法と一致することを確認することをさらに含む、請求項２８または３１に記載の方法。
33. 汎用ブートストラッピング・アーキテクチャ（ＧＢＡ）において、移動ノードのデータ・プロセッサにより実行されることにより、該移動ノードに、
    前記移動ノードによりサポートされている認証法のリストと、各認証法に対応する識別子とを含む第１のブートストラップ・リクエストを、前記汎用ブートストラッピング・アーキテクチャ（ＧＢＡ）のブートストラッピング・サーバ機能要素へ送信することと；
    前記第１メッセージで前記ノードにより提供された前記リストから、前記ブートストラッピング・サーバ機能要素が選択した認証法に関する情報と、該選択された認証法に対応する識別子とを含むエラー応答を、前記ブートストラッピング・サーバ機能要素から受信することと；
    前記選択された認証法によって計算した応答情報と、前記リストとを含む第２のブートストラップ・リクエストを、前記ブートストラッピング・サーバ機能要素へ送信することと；
    を含む処理を実行させる、コンピュータ・プログラム。
34. 前記処理が、
    前記第２のブートストラップ・リクエストの送信に応じて、前記選択された認証法に関する情報を含む肯定応答を、前記ブートストラッピング・サーバ機能要素から受信することをさらに含む、請求項３３に記載のコンピュータ・プログラム。
35. 前記第１のブートストラップ・リクエストはHTTP GETとして送信され、前記リストは前記HTTP GETのHTTPペイロード内に含まれ、前記エラー応答はHTTP 401 Unauthorized応答として受信される、請求項３３または３４に記載のコンピュータ・プログラム。
36. 前記第２のブートストラップ・リクエストはHTTP GETとして送信される、請求項３３から３５のいずれかに記載のコンピュータ・プログラム。
37. 前記肯定応答はHTTP 200 OKメッセージとして受信される、請求項３４に記載のコンピュータ・プログラム。
38. 前記肯定応答により示される認証法が、前記エラー応答により示される認証法と一致することを確認することをさらに含む、請求項３４または３７に記載のコンピュータ・プログラム。
39. 汎用ブートストラッピング・アーキテクチャ（ＧＢＡ）における移動ノードであって、送信機及び受信機と、前記送信機及び前記受信機に組み合わされたデータ・プロセッサとを備える移動ノードにおいて、前記データ・プロセッサは、
    前記移動ノードによりサポートされている認証法のリストと、各認証法に対応する識別子とを含む第１のブートストラップ・リクエストを、前記汎用ブートストラッピング・アーキテクチャ（ＧＢＡ）のブートストラッピング・サーバ機能要素へ、前記送信機を介して送信し、
    前記ブートストラッピング・サーバ機能要素によって前記リストから選択された認証法に関する情報と、該選択された認証法に対応する識別子とを含むエラー応答を、前記受信機を介して前記ブートストラッピング・サーバ機能要素から受信し、
    前記選択された認証法によって計算した応答情報と、前記リストとを含む第２のブートストラップ・リクエストを、前記受信機を介して前記ブートストラッピング・サーバ機能要素へ送信する、
    よう動作可能である、移動ノード。
40. 前記データ・プロセッサはさらに、
    前記第２のブートストラップ・リクエストの送信に応じて、前記選択された認証法に関する情報を含む肯定応答を、前記ブートストラッピング・サーバ機能要素から受信しうるように構成される、請求項３９に記載の移動ノード。
41. 前記第１のブートストラップ・リクエストはHTTP GETとして送信され、前記リストは前記HTTP GETのHTTPペイロード内に含まれ、前記エラー応答はHTTP 401 Unauthorized応答として受信される、請求項３９または４０に記載の移動ノード。
42. 前記第２のブートストラップ・リクエストはHTTP GETとして送信される、請求項３９から４１のいずれかに記載の移動ノード。
43. 前記肯定応答はHTTP 200 OKメッセージとして受信される、請求項４０に記載の移動ノード。
44. 前記データ・プロセッサは、前記肯定応答により示される認証法と、前記エラー応答により示される認証法とが一致することを確認するようさらに動作可能である、請求項４０または４３に記載の移動ノード。
45. 汎用ブートストラッピング・アーキテクチャ（ＧＢＡ）における移動ノードであって、
    前記移動ノードによりサポートされている認証法のリストと、各認証法に対応する識別子とを含む第１のブートストラップ・リクエストを、前記汎用ブートストラッピング・アーキテクチャ（ＧＢＡ）のブートストラッピング・サーバ機能要素へ送信する手段と；
    前記ブートストラッピング・サーバ機能要素によって前記リストから選択された認証法に関する情報および前記選択された認証法に対応する識別子を含むエラー応答を、前記ブートストラッピング・サーバ機能要素から受信する手段と；
    前記選択された認証法によって計算した応答情報と、前記移動ノードがサポートする認証法の前記リストとを含む第２のブートストラップ・リクエストを、前記ブートストラッピング・サーバ機能要素へ送信する手段と；
    を備える、移動ノード。
46. 前記受信手段は、前記第２のブートストラップ・リクエストが送信されることに応じて、前記選択された認証法に関する情報を含む肯定応答を、前記ブートストラッピング・サーバ機能要素から受信しうるように構成される、請求項４５に記載の移動ノード。
47. 前記肯定応答により示される認証法が、前記エラー応答により示される認証法と一致することを確認する手段をさらに含む、請求項４５または４６に記載の移動ノード。
48. 請求項１７から２３のいずれかに記載のブートストラッピング・サーバ機能要素と、請求項３９から４４のいずれかに記載の移動ノードとを有する、システム。

Images