JP4643657B2 - 通信システムにおけるユーザ認証及び認可 - Google Patents

Description

発明の分野
本発明は、通信システムにおけるユーザ認証及び認可に関するものであり、特に、通信システムのネットワークアプリケーション機能に対するユーザを認証及び認可するための方法及び装置に関するものである。

発明の背景
ＧＳＭのような既存の第２世代セルラー無線通信システムは、第３世代システムによって補完される処理下にあり、また、第３世代システムに置き換わるもののいくつかに向けられている。これらは、ユニバーサル移動体電気通信システム（ＵＭＴＳ）として知られる３Ｇシステムを含んでいる。セキュリティは、ＵＭＴＳ規格のキー要素であり、また、第２世代システムのセキュリティよりも優れるものとなることが意図されていて、それと同時に、ＧＳＭからＵＭＴＳへの移動、及びＧＳＭアクセスネットワークとＵＭＴＳアクセスネットワーク間のハンドオーバの両方を容易にするためにＧＳＭとの互換性を保証している。ＵＭＴＳ（３Ｇ ＴＳ３３．１０２参照）用の認証及びキーアグリーメント（ＡＫＡ）プロトコルの設計は、少なくとも、アクセスネットワークに対する加入者の認証及び無線リンクを介するユーザデータの安全の確保に関する目的を満足することが意図されている。

ＡＫＡプロトコルは、３つの通信パーティ、即ち、ユーザのホーム環境（ＨＥ）の認証局（ＡｕＣ）、ユーザの在圏ネットワーク（ＳＮ）のビジターロケーションレジスタ（ＶＬＲ）、及び自身のＵＭＴＳ加入者アイデンティティモジュール（ＵＳＩＭ）によって示されるユーザ自身に関与する。シークレットキーは、ＡｕＣとＵＳＩＭによって共有される。ＨＥによる認証データリクエストの受信に続いて、ＡｕＣは、（ｎ）認証ベクトル配列を生成する。この配列はＳＮへ送信され、ユーザによるｎ回の認証の試行に適している。ＳＮは、配列内の次のベクトルを選択し、そのベクトルのコンポーネント群をＵＳＩＭへ送信する。これらは、ＵＳＩＭに、ＳＮを検証し、セッションキーを計算し、そして応答を生成することを可能にする。その応答はＳＮへ返答され、ＳＮは、その応答と、選択されているベクトルに含まれている期待応答とを比較する。それらがマッチする場合、ＳＮは、認証交換は正常に完了していると仮定する。確立されているセッションキーは、ＵＳＩＭによってユーザの移動機器に送信され、また、ＶＬＲによってＵＭＴＳ無線アクセスネットワーク（ＵＴＲＡＮ）の在圏無線ネットワークコントローラ（ＲＮＣ）へ送信される。これによって、無線リンクを介して送信されるデータの暗号化を可能にする。

ネットワークレベルではなく、アプリケーションレベルで認証及び認可が必要とされる場合が存在する。いくつかの場合、アプリケーションレイヤでのデータの暗号化が望ましいあるいは必要とされる場合がある。例えば、暗号化ビデオデータがウェブサーバからブロードキャストサービスの加入者へ「ブロードキャスト」される場合を検討してみる。加入者は、まず、ウェブサーバに対して自身を認証しなければならない。その後、加入者には、ブロードキャストデータを解読するためのキーが提供される。アプリケーションレイヤのセキュリティを容易にする完全に別のメカニズムを提供するのではなく、このセキュリティが、ＡｕＣ、ＵＳＩＭ及び３ＧＰＰ ＡＫＡプロトコルを含む３ＧＰＰ認証基盤上で「ブートストラップ（bootstrapped）」されることを可能にするための提案がなされている。この方法は、少なくとも最初に、ネットワーク側のアプリケーション機能がアクセスネットワークオペレータの制御下にあるが、アクセスネットワークオペレータと、アプリケーション機能が配置されているネットワークのオペレータ間にいくつかの信頼関係が存在している場合は必要とされないことを見込んでいる。

３ＧＰＰ ＴＳ ３３．２２０は、認証のブートストラップ用の汎用ブートストラップアーキテクチャ（ＧＢＡ）と、３ＧＰＰ ＡＫＡメカニズム上のアプリケーションセキュリティ用のキーアグリーメント処理を記載している。新規の処理は、ユーザのＨＥに配置されているブートストラップサーバ機能（ＢＳＦ）として知られる機能に基づくネットワークを導入している。ＢＳＦは、ホーム加入者サブシステム（ＨＳＳ）であるＡｕＣと通信して、リクエストに応じて、認証ベクトルを取得する。ＢＳＦとＨＳＳ間のインタフェースは、Ｚｈインタフェースとして知られている。ネットワーク側のアプリケーション機能を実現する機能エンティティは、ネットワークアプリケーション機能（ＮＡＦ）と呼ばれている。ＮＡＦは、Ｚｎインタフェースを介してＢＳＦと通信する（例えば、ＤＩＡＭＥＴＥＲプロトコルを使用して）。ユーザ機器（ＵＥ）とＢＳＦ間のインタフェース及びユーザ機器（ＵＥ）とＮＡＦ間のインタフェースはそれぞれＵｂインタフェース及びＵａインタフェースと呼ばれ、これらは、ハイパーテキスト転送プロトコル（ＨＴＴＰ）を利用する。

ＵＥが、ＧＢＡが、与えられるＮＡＦで使用されることを確認し、かつ必要なキーがまだ存在していないことを確認すると想定すると、ＵＥは、まず、Ｕｂインタフェースを介して、ＢＳＦとのＨＴＴＰダイジェストＡＫＡメカニズムを開始しなければならない。（この処理の一部として、ＢＳＦは、ＨＳＳから取得されるベクトルを変更しても良い。）その結果、ＵＥは、ＢＳＦによって認証され、また、必要なセキュリティキーが提供される。加えて、ＵＥには、トランザクション識別子（ＴＩ）が提供される。このＴＩは、Ｕａインタフェースを介して、ＵＥによってＮＡＦへ提供される。ＮＡＦは、そのＴＩをＢＳＦへ送信し、一方で、関係するセキュリティキーを受信する。ＵＥとＮＡＦは、安全な方法でＵａインタフェースを使用することができる。

Ｕｂインタフェースの使用が頻繁にあることが予想されないととはいえ（注、同一のキーイング（keying：キー生成）要素はいくつかの異なるＮＡＦを用いて再使用され得る。ここで、各新規のＮＡＦは、共通のＴＩを使用してＢＳＦからキーイング要素をリクエストする）、それが使用される場合、時間がかかる。例えば、１０回のラウンドトリップには、ＨＴＴＰダイジェストがＵａインタフェース上で使用されることが想定されることを含んでいる。また、ＵＥは、ＮＡＦとＢＳＦとの両方と通信するために、２つの別のトランスポートレイヤ接続を使用しなければならず、その結果、ハイレベルのトランスポートレイヤリソースをもたらすことになる。

発明の要約
本発明の目的は、上述の欠点を解消するあるいは少なくとも軽減することである。これらの目的は、１つのインタフェースに２つのインタフェースを組み込み、認可及び認証処理を平行して実行することを可能にすることによって達成される。

本発明の第１の構成に従えば、通信ネットワークを介して、２つ以上のサーバに接続されているクライアントを認証する方法が提供される。ここで、前記クライアントと第１サーバは、共有シークレットを保有している。この方法は、
前記共有シークレットを使用して第１サーバに対する前記クライアントを認証し、第２サーバを介して、前記クライアントと前記第１サーバ間で行われる認証に係る処理に関係するシグナリングを実行し、
前記クライアントと前記第１サーバでセッションキーを生成し、そのセッションキーを前記第２サーバへ提供し、
前記セッションキーを使用して、前記第２サーバに対する前記クライアントを認証する。

好ましくは、本方法は、前記第１サーバに対する前記第２サーバを認証し、その認証処理後に、前記第１サーバから前記第２サーバへ前記セッションキーを提供する。

本発明の第２の構成に従えば、通信システム内の認証サーバを操作する方法が提供される。この方法は、
クライアントと更なる認証サーバ間の認証に係るシグナリングと、前記クライアントと前記更なる認証サーバが共有するシークレットとを中継し、
前記更なる認証サーバからセッションキーを受信し、前記セッションキーを使用して前記クライアントを認証する。

本発明の第３の構成に従えば、通信システム内の認証サーバを操作する方法が提供される。この方法は、
クライアントの認証のために、更なるサーバを介して前記クライアントとシグナリングを交換し、
前記クライアントと前記認証サーバ間で共有されるシークレットを使用して、セッションキーを生成し、
前記セッションキーを前記更なるサーバへ送信する。

本発明の第４の構成に従えば、通信ネットワークに接続されているクライアントを操作する方法が提供される。この方法は、
第１サーバに対する前記クライアントを認証するために、第２サーバを介して前記第１サーバとシグナリングを交換し、
前記クライアントと前記第１サーバ間で共有されるシークレットを使用して、セッションキーを生成し、
前記第２サーバから認証チャレンジを受信し、前記セッションキーを使用してチャレンジ応答を生成する。

本発明の方法の各処理は、特定の順序で実行される必要はない。特に、本方法における処理は、重複していても良い。

本発明の第５の構成に従えば、通信ネットワークを介して２つ以上のサーバに接続されているクライアントを認証する方法が提供される。ここで、前記クライアントと第１サーバは、共有シークレットを保有している。この方法は、
第２サーバを介して、前記クライアントから前記第１サーバへ認証リクエストを送信し、
前記第１サーバでの前記認証リクエストの受信に応じて、前記共有シークレットを使用して第１認証チャレンジを生成し、前記第１認証チャレンジを前記第２サーバへ送信し、
前記第１認証チャレンジを前記第２サーバへ転送し、前記第２サーバで、第２認証チャレンジを生成し、前記第１認証チャレンジと前記第２認証チャレンジとを前記第２サーバから前記クライアントへ送信し、
前記クライアントでの前記第１認証チャレンジと前記第２認証チャレンジとの受信に応じて、該第１認証チャレンジに対する第１チャレンジ応答を生成し、前記共有シークレットを使用してセッションキーを生成し、前記セッションキーを使用して前記第２認証チャレンジに対する第２チャレンジ応答を生成し、
前記第２サーバへ、前記第１チャレンジ応答と前記第２チャレンジ応答とを送信し、該第１チャレンジ応答を前記第１サーバへ転送し、
前記第１チャレンジ応答と前記共有シークレットを使用して、前記第１サーバで前記クライアントを認証し、前記クライアントが認証されるイベントにおいて、前記第１サーバで前記セッションキーを生成し、該セッションキーを前記第２サーバへ送信し、
前記第２チャレンジ応答と前記セッションキーを使用して、前記第２サーバで前記クライアントを認証する。

本発明の第６の構成に従えば、通信ネットワークのネットワークアプリケーション機能に対するユーザ機器を認証する方法が提供される。

前記ユーザ機器からのアクセスリクエストを前記ネットワークアプリケーション機能へ送信し、
前記アクセスリクエストが、前記通信ネットワークのいくつかの他の機能によって実行されなければならない認証に関連することを、前記ネットワークアプリケーション機能で判定し、
前記アクセスリクエストを、前記他の機能へ転送し、
前記他の機能から前記ネットワークアプリケーション機能へ、チャレンジを返信し、
前記チャレンジと、前記ネットワークアプリケーション機能の更なるチャレンジを前記ユーザ機器へ送信し、
前記ユーザ機器から前記ネットワークアプリケーション機能へチャレンジ応答を送信し、前記他の機能の前記チャレンジに関する応答を、該他の機能へ転送し、
前記ネットワークアプリケーション機能で前記チャレンジ応答の有効性を検証し、かつ前記他の機能で前記応答の有効性を検証する。

本発明の第７の構成に従えば、通信ネットワークを介して２つ以上のサーバと接続されるクライアントを認証する方法が提供される。ここで、前記クライアントと第１サーバが共有シークレットを保有する。この方法は、
クライアントから認証サーバへ、前記認証サーバが配置されているドメイン以外の他のドメインを識別する認証ヘッダを含む認証リクエストを送信し、
前記認証サーバで、他のドメインに向けられている前記認証リクエストを認識、前記認証ヘッダを、前記他のドメインの認証サーバへ転送し、
第２認証サーバでの前記認証リクエストの受信に応じて、第１認証サーバを認証し、前記クライアントを認証し、前記クライアントを認証する手段を、前記第１認証サーバへ提供する。

上記で参照する、更なるサーバから中間サーバ転送される認証リクエストあるいはアクセスリクエストは、受信されるリクエストメッセージ全体の転送、あるいはその一部だけの転送を含んでいる。また、このリクエストは、受信されるフォーマットから異なるフォーメットへ変換されるという可能性をも保証する。このリクエストの本質が維持されることだけが重要である。

本発明の他の構成は、本方法を使用するための、ユーザ機器及び認証サーバに関連している。

実施形態の詳細説明
本発明は、ユーザ及びユーザデバイスの少なくとも一方に対して「平行」認証メカニズムを提供する。このメカニズムでは、第２の認証処理用の信用証明書が、第１の認証処理が完了する前に、第１の認証処理の信用証明書から導出される。第２の認証処理は、第１の認証処理の完了時に完了される。

クライアントと認証サーバ（ＡＵＳ）は、シークレットＳを共有している。クライアントは、（第２）サーバへコンタクトをとると、サーバはクライアントを認証しなければならない。しかしながら、サーバは、自身の信用証明書をクライアントととは共有していない。クライアント、サーバ及びＡＵＳは、既存のシークレットＳが再使用されることを同意する。図１は、このプロセスで介在するシグナリングステップを示している。

１）クライアントは、リクエストをサーバへ送信する。このリクエストには、ＡＵＳによって保持されるシークレットＳをサーバが再使用してクライアントを認証することができることを示す認証方法特定情報を含んでいる。

２）サーバは、ＡＵＳからの情報を再使用することができることを認識し、その認証方法特定情報をＡＵＳへ転送する。サーバとＡＵＳは、通信の開始時に互いに相互に認証する。

３）ＡＵＳがサーバと協働することを決定する場合、ＡＵＳは、ＡＵＳチャレンジを生成し、そのチャレンジをサーバへ転送する。

４）サーバは、ＡＵＳ−チャレンジ（第１認証方法）をクライアントへ中継し、かつ自身のサーバ−チャレンジ（第２認証方法）を付加する。この段階で、サーバは、クライアントに関してステートレスを維持することができる。

５）クライアントは２つのチャレンジを受信する。クライアントは、共有シークレットＳを使用して、ＡＵＳ−チャレンジへの応答を用意する。次に、クライアントは、第２のチャレンジの応答を用意するために、シークレットＳからサーバ特定キー要素を導出する。クライアントは、サーバが同一のキーを保有することを確実にするために、サーバからの相互認証を要求する。これは、ＡＵＳがサーバを信頼し、かつ導出されるキーをサーバへ提供することをクライアントへ証明する。クライアントは、ＡＵＳ−応答とサーバ−応答の両方をサーバへ送信する。

第１認証方法の性質に依存して、クライアントは、この段階で、ＡＵＳを認証することができる。例えば、これは、ＵＭＴＳ ＡＫＡ、ＥＡＰ ＡＫＡ及びＨＴＴＰダイジェストＡＫＡメカニズムを用いることで実現可能である。これは、選択的には、以下のステップ９）で実行されても良い。

６）サーバは、サーバ応答を記憶し、かつＡＵＳ−応答をＡＵＳへとトンネルする。同時に、サーバは、サーバ−チャレンジに関連するサーバ特定キー要素（シークレットＳから導出される）をリクエストする。

７）ＡＵＳは、ＡＵＳ−応答と共有シークレットＳを使用して、クライアントを認証する。次に、ＡＵＳは、クライアントがステップ５）で処理したＳから同一キー要素を用意し、そのキー要素をサーバへ送信する。ＡＵＳは、また、その新規のキー要素に対する有効期限を特定して、それをサーバへ提供することもできる。クライアントの認証が失敗する場合、ＡＵＳは、そのキー要素を返信しない代わりに、認証失敗メッセージでリプライする。

８）サーバは、ステップ６）からのサーバ−応答と、ステップ７）からの受信したキー要素を使用してクライアントを認証する。認証が成功する場合、サーバは、サービスをクライアントへ配信することになる。

９）クライアントは、サーバ−応答とＳから導出されるキー要素を使用してサーバを認証する。第１認証方法の性質に依存して、クライアントは、この段階で、ＡＵＳを認証することもできる。例えば、これは、ＨＴＴＰダイジェストを用いる場合であり、この場合は、クライアントは、ＡＵＳを認証するために、認証−Ｉｎｆｏヘッダを含めるための応答メッセージ（例えば、２００ＯＫ）を要求する。

クライアントとＡＵＳは、導出されるキーが有効であることを維持するための時間長についてのスタティックポリシーを持っていてもよい。このポリシーは、シークレットＳが特定される時と同時にクライアントで構成されても良い。但し、例えば、認証メッセージにいくつかのパラメータで、そのキー有効期限を符号化することで、そのキー有効期限に合意するための様々な方法が存在していても良い。

ここで、一般的な場合には、クライアントアイデンティティが再使用されるあるいは再生成されるかを特定することは困難であることに注意されたい。アイデンティティの合意は、特定アプリケーションに依存することになる。

本発明の第１の実装例を、図２を参照して説明する。ここでは、いくつかの無線アクセスネットワーク（不図示）と通信する、加入者所有３Ｇ移動端末（ＵＥ）を示している。ここで、ＵＥは無線アクセスネットワークに対して既に認証されていて、また、３ＧＰＰ ＡＫＡ処理（上述のような、アクセスネットワークの在圏ノードと加入者のホーム環境の認証サーバ間のシグナリング交換を含む）を使用してネットワークによって提供されるサービスを使用することが認可されていると想定する。また、図２には、ネットワーク認証機能（ＮＡＦ）と、ブートストラップサーバ機能（ＢＳＦ）とが示されている。ＮＡＦの位置は、ここでの説明の目的のためには重要ではないが、例えば、無線アクセスネットワークのオペレータによって操作され、かつ制御されても良い。ＢＳＦは、典型的には、加入者のホーム環境内に配置されておる。既に説明しているように、ＵＥは、Ｕａインタフェースを介してＮＡＦと通信し、Ｕｂインタフェースを介してＢＳＦと通信する。

加入者所有端末ＵＥが、サービスの使用を行い、ＮＡＦによって制御されるアクセスを行いたいと想定する。このサービスは、ウェブサーバからのリアルタイムあるいはストリーミングビデオブロードキャストであっても良い。典型的には、ＮＡＦは、加入者がだれが要求していて、かつ加入者との請求関係を確立することができることを知っていることが必要となる。これを行うために、ＮＡＦは、加入者のホーム環境とコンタクトをとらなければならない。従来の方法を介してかなり簡略化される処理について説明する。この処理は、３ＧＰＰ ＧＢＡ規格ＴＳ ３３．２２０（ｖ．６．２．０）及びＴＳ２４．１０９（ｖ６．０．０）を基礎としている。

最適化処理は、ハイパーテキスト転送プロトコルＨＴＴＰがＵａインタフェースでは使用されるものと想定しているが、他のプロトコルでも可能である。この処理は、以下のステップを有している。

１）ＵＥは、Ｕａインタフェースを介して、ＨＴＴＰリクエスト（典型的には、ＨＴＴＰ ＧＥＴ）をＮＡＦへ送信する。ＵＥがＧＢＡ最適化処理をサポートしている場合、Ｕｂインタフェースで使用する認可ヘッダを、このＨＴＴＰメッセージへ含めても良い。この認可ヘッダは、ユーザアイデンティティとＢＳＦの「アドレス体系（realm）」を含んでいる。プライバシーの理由のために、ユーザアイデンティティは、通常のＵｂインタフェース関連アイデンティティ（ＩＭＳＩあるいはＩＭＰＩ）でなくても良い。むしろ、このアイデンティティは、予め有効なＵａインタフェース関連アイデンティティ、即ち、Ｂ−ＩＴＤであっても良い。このリクエストは、他の認可ヘッダ、特に、ＮＡＦへ向けられる認可ヘッダを含んでいても良い。

ＵＥは、例えば、セキュリティキーの有効期限が満了しようとしている場合に、ＧＢＡ最適化処理の使用を試行するか、あるいはＧＢＡ処理が使用されるべきであるかをどうかをＵＥが知らない場合にはデフォルトによる試行を行うかを決定しても良い。

２）ＨＴＴＰリクエストが、Ｕｂインタフェースで使用される認可ヘッダを含んでいるイベントでは、ＮＡＦは、このヘッダが、自身以外のアドレス体系に対するものであることを認識することになる。ヘッダ情報に基づいて、ＮＡＦは、そのヘッダ情報あるいはその関連部分を、Ｚｎインファエースを介して、例えば、ＤＩＡＭＥＴＥＲプロトコルを使用してＢＳＦへ転送しても良い。

ＮＡＦがＧＢＡ最適化をサポートしていない場合、認可ヘッダは無視するべきである。これは、それがいくつかの他のアドレス体系に対するものであるからである。ＮＡＦがＧＢＡ最適化をサポートするとしても、ＮＡＦは、依然として、ＧＢＡ最適化を使用しないことのポリシー決定を行う可能性がある。［ここで、この場合、ＮＡＦは、ＨＴＴＰ４０１認証チャレンジを用いて、直接ＵＥへのチャレンジを行うことになり、ＵＥとＮＡＦが有効なパスワードを共有していると想定する。］ＮＡＦは、Ｕｂインタフェースを介して、ブートストラップ処理を開始するメッセージを用いて、リプライを行っても良い。

ＮＡＦからＨＴＴＰプロトコル情報を受信すると、ＢＳＦは、ＮＡＦが、最適化ＧＢＡ処理を使用することが認可されているかどうかをチェックする。例えば、ＢＳＦは、ＴＬＳを使用してＮＡＦを認証して、ローカルデータベースから認可データをチェックすることができる。

３）そうである場合、ＢＳＦは、ＤＩＡＭＥＴＥＲプロトコルメッセージ内で、ＨＴＴＰダイジェストＡＫＡチャレンジをＮＡＦヘ返信する。このチャレンジは、例えば、ナンスパラメータで、ＵＥに対する新規のアイデンティティである、Ｂ−ＴＩＤ２を含んでいる。このチャレンジに対して、ＵＥがどのようにしてＢ−ＴＩＤ２を構築することができるかについての「ヒント」だけを、そのヒントからアイデンティティを構築するためのルールを知っているＵＥとＢＳＦに含ませることもできる。ＢＳＦは、加入者のＩＭＳＩ／ＩＭＰＩの後にＢ−ＴＩＤを関連付けることが可能であり、これによって、正常なＡＫＡチャレンジを選択する。

４）ＮＡＦからＵＥへのＨＴＴＰ４０１応答メッセージは、２つの認証チャレンジを含んでいて、１つはＢＳＦからのものであり、もう１つはＮＡＦからのものである。この段階で、ＮＡＦは、ステートレスを維持することができる。即ち、ＵＥを「忘れる」ことができる。

５）ＵＥは、ダイジェストＡＫＡチャレンジ（ＢＳＦで生成される）を使用して、ホームネットワークを認証する。ＵＥは、ＨＴＴＰダイジェストＡＫＡチャレンジ及び他の関連情報に基づいて、新規のＧＢＡ関連キーイング要素を生成する。次に、ＵＥは、Ｂ−ＴＩＤ２と関連するキーイング要素を使用して、ＮＡＦ特定キーを構築し、その情報を使用して、第２認証チャレンジに対する応答（ＮＡＦに向けての）を生成する。第２ＨＴＴＰリクエストは、ＵＥによってＮＡＦに向けて送信され、これには、２つの認可ヘッダを含んでいて、１つはＮＡＦに対するものであり、もう１つはＢＳＦに対するものである。

６）ＮＡＦは、ＡＫＡ応答（即ち、ＢＳＦ認可ヘッダ）をＢＳＦへ「トンネル」する。同時に、これは、Ｂ−ＴＩＤ２アイデンティティに関連するキーイング要素をリクエストする。

７）ＢＳＦは、ダイジェストＡＫＡ処理に従ってＵＥを認証する。次に、これは、ＵＥ（ステップ５）におけるキーイング要素と同一のキーイング要素を構築し、その関連キーをＮＡＦへ返信する。ＡＫＡ認証が失敗する場合、ＢＳＦは、エラーメッセージをＮＡＦへ返信する。

８）ＮＡＦが、ＢＳＦから適切なキーイング要素を受信するイベントでは、ＮＡＦは、第２ＨＴＴＰリクエスト［ステップ５）］に含まれる第２認可ヘッダを使用して、ＵＥを認証することができる。次に、ＮＡＦは、リクエストされたサービスのＵＥへの配信を進める。

別の平行認証メカニズムを、まずは、一般的に説明し、そして、詳細な実装に関して説明する。

図３は、上述の通信システムの構成要素を示している。ここで、クライアントと認証サーバ（ＡＵＳ）は、シークレットＳを共有している。ステップ１）から３）は、図１を参照して説明したものと同一である。しかしながら、ステップ４）で、サーバがクライアントに対するＡＵＳチャレンジを受信した後は、サーバは、自身の任意のチャレンジを付加することなくそのＡＵＳチャレンジをクライアントへ転送する。

クライアントはチャレンジを受信し、共有シークレットＳからサーバ特定キー要素を導出し、そして、それを使用して、ＡＵＳチャレンジへの応答を用意する。クライアントは、サーバ特定キー要素（Ｓから導出される）を使用して、ＡＵＳからの相互認証を要求する。これは、ＡＵＳがサーバを信頼し、それゆえ、Ｓからサーバ特定キー要素が導出されることをクライアントに証明することになる。クライアントは、ステップ５）で、ＡＵＳ−応答をサーバへ送信する。図１の処理のように、第１認証方法の性質に依存して、クライアントは、この段階で、ＡＵＳをすぐに認証することが可能となっている。

ステップ６）で、サーバは、ＡＵＳ応答をＡＵＳへトンネルしながら、その応答のコピーを自身で維持する。同時に、サーバは、ＡＵＳから（Ｓから導出される）サーバ特定キー要素をリクエストする。サーバは、進行中の認証処理においてはこのキー要素は必要としないが、これは、将来クライアントを認証するために使用されても良い。

ＡＵＳは、ステップ５）でクライアントが用意した共有シークレットＳから同一のキー要素を用意し、そして、ＡＵＳ応答と導出されたキー要素を使用してクライアントを認証する。ステップ７）で、ＡＵＳは、サーバ特定キー要素を使用して認証リプライを用意し、そして、それをサーバへ送信する。ＡＵＳは、クライアントが認証されたことをサーバへ指示し、かつキー要素をサーバへ送信する。再度、ＡＵＳは、新規のキー要素に対して有効期限を特定しても良く、そして、それをサーバへ提供する。クライアントの認証が失敗する場合、ＡＵＳは、キー要素を返信しないが、認証失敗メッセージをリプライする。ここで、ＡＵＳは、認証リプライを用意しない代わりに、キー要素をサーバへ返信することも可能である。これにより、サーバは、認証リプライを用意することが可能になる。

サーバは、ＡＵＳから、認証指示とキー要素を受信する。認証が成功した場合、サーバはサービスをクライアントへ配信することになる。ステップ８）で、サーバは、認証リプライをクライアントへ転送する。サーバは、ＡＵＳによって返信されたキーを使用して、ステップ５）でクライアントによって送信されたＡＵＳ応答をテストすることができる（但し、これは、サーバが、ＡＵＳによって提供される認証に依存している場合は必要ない）。

ステップ９）で、クライアントは、認証リプライと、共有シークレットＳから導出されるキー要素を使用して、サーバを認証する。これは、ＡＵＳがサーバを信頼していることをクライアントへ証明することになる。認証方法の性質に依存して、クライアントは、この段階で、ＡＵＳを認証しても良い。例えば、これには、ＨＴＴＰダイジェストメカニズムを使用する場合にあてはまる。

この一般的な処理の詳細実装は、ＨＴＴＰがＵａインタフェース内で使用されるものと想定する。この処理は、図４で示される。ステップ１）から３）は、図２で参照したものと同様である。但し、ステップ４）で、ＮＡＦは、４０１応答メッセージをＵＥに向けて転送する。これには、ＢＳＦからの認証チャレンジを含んでいるが、ＮＡＦによって生成されるチャレンジは含んでいない。

ＵＥは、ダイジェストＡＫＡチャレンジ（ＢＳＦから）を使用して、ＢＳＦを認証する。ＵＥは、ＨＴＴＰダイジェストＡＫＡチャレンジと他の関連情報に基づいて、新規のＧＢＡ関連キーイング要素を生成する。ＵＥは、このキーイング要素と他の関連情報（例えば、ＮＡＦのアイデンティティ）を使用して、ＮＡＦ特定キーを導出し、次に、そのＮＡＦ特定キーを、ＢＳＦに向けてのＨＴＴＰダイジェストＡＫＡ応答を用意する場合のパスワードとして使用する。ステップ５）で、ＵＥは、ＨＴＴＰダイジェストＡＫＡ応答にクライアントナンス（client nonce）を含めて、その応答をＮＡＦに向けて送信する。

ここで、このＵＥの動作は、ＨＴＴＰダイジェストＡＫＡチャレンジに応答する場合には、ＲＦＣ３３１０（ＨＴＴＰダイジェストＡＫＡ）の標準動作に違反していることに注意されたい。ＨＴＴＰダイジェストＡＫＡで使用されるパスワードは、「ＲＥＳ」であるべきであるが、ＮＡＦ特定キーであるべきではない。しかしながら、この例外処理は、ＮＡＦアイデンティティが認証処理に結びづけられることを保証する。

ステップ６）で、ＮＡＦは、ＡＫＡ応答をＢＳＦにトンネルする。同時に、ＮＡＦは、ＵＥに関連するキーイング要素（例えば、ＩＭＳＩ／ＩＭＰＩあるいは新規のＢ−ＴＩＤによって識別される）をリクエストする。ＢＳＦは、ステップ５）でＵＥが実行したものと同一のＮＡＦ特定キーイング要素を構築する。次に、ＢＳＦは、ＮＡＦ特定キーを使用して、ＵＥ（ダイジェストＡＫＡ応答）を認証する。ステップ７）で、ＢＳＦは、ＮＡＦ特定キーとクライアントナンスを使用して２００ＯＫメッセージを用意して、それをＮＡＦへ送信する。このメッセージは、ＵＥに対する新規のアイデンティティ、即ち、Ｂ−ＴＩＤ２を含んでいても良い。また、このメッセージは、ＵＥがどのようにしてアイデンティティＢ−ＴＩＤ２を構築することができるかについてのヒントだけを含ませることも可能である［新規のアイデンティティは、ステップ３）あるいはステップ７）で割り当てられても良い］。

また、ＢＳＦは、関連キーを、ＵＥが正常に認証されていることの通知とともにＮＡＦへ送信する。ＮＡＦがまだ新規のアイデンティティＢ−ＴＩＤ２を確認していない場合、ＢＳＦは、その情報をＮＡＦへも返信する。ＡＫＡ認証が失敗する場合、ＢＳＦは、エラーメッセージをＮＡＦヘ返信する。

ステップ８）で、ＮＡＦは、２００ＯＫメッセージをＵＥへ転送する。ＮＡＦは、例えば、次のアクセスリクエストの場合にＵＥを認証するために、ＮＡＦ特定キーを記憶する。ここで、ＮＡＦは、ＵＥへサービスを配信するための準備をする。ステップ９）で、ＵＥは、２００ＯＫメッセージとＮＡＦ特定キーの受信に基づいて、ＮＡＦを認証することができる。これが可能となるのは、ＢＳＦもＮＡＦ特定キーを導出していて、ＵＥがＢＳＦを認証している、ここでは、間接的にＮＡＦを認証しているからである。

本発明の範囲から逸脱することなく、上述の実施形態を様々に変形することができることが当業者には理解されるであろう。

一般的な場合での、平行認証処理に関係するシグナリングのフローを示す図である。 汎用ブートストラップアーキテクチャに適用される平行認証処理に関係するシグナリングのフローを示す図である。 一般的な場合での、変形された平行認証処理に関係するシグナリングのフローを示す図である。 汎用ブートストラップアーキテクチャに適用される、変形された平行認証処理に関係するシグナリングのフローを示す図である。

Claims (20)

1. 通信ネットワークを介して２つ以上のサーバに接続されているクライアントを認証する方法であって、前記クライアントと第１サーバが、共有シークレットを保有している、方法であって、
   第２サーバを介して、前記クライアントから前記第１サーバへ認証リクエストを送信し、
   前記第１サーバでの前記認証リクエストの受信に応じて、前記共有シークレットを使用して第１認証チャレンジを生成し、前記第１認証チャレンジを前記第２サーバへ送信し、
   前記第２サーバで、第２認証チャレンジを生成し、前記第１認証チャレンジと前記第２認証チャレンジとを前記第２サーバから前記クライアントへ送信し、
   前記クライアントでの前記第１認証チャレンジと前記第２認証チャレンジとの受信に応じて、該第１認証チャレンジに対する第１チャレンジ応答を生成し、前記共有シークレットを使用してセッションキーを生成し、前記セッションキーを使用して前記第２認証チャレンジに対する第２チャレンジ応答を生成し、
   前記第２サーバへ、前記第１チャレンジ応答と前記第２チャレンジ応答とを送信し、該第１チャレンジ応答を前記第１サーバへ転送し、
   前記第１チャレンジ応答と前記共有シークレットを使用して、前記第１サーバで前記クライアントを認証し、前記クライアントが認証されるイベントにおいて、前記第１サーバで前記セッションキーを生成し、該セッションキーを前記第２サーバへ送信し、
   前記第２チャレンジ応答と前記セッションキーを使用して、前記第２サーバで前記クライアントを認証する
   ことを特徴とする方法。
2. 前記第１サーバに対する前記第２サーバを認証し、その認証処理後に、前記第１サーバから前記第２サーバへ前記セッションキーを提供する
   ことを特徴とする請求項１に記載の方法。
3. 前記第１サーバに対する前記クライアントの認証と、前記第２サーバに対する前記クライアントの認証の少なくとも一方では、ＨＴＴＰダイジェストプロトコルを使用する
   ことを特徴とする請求項１または２に記載の方法。
4. 前記ＨＴＴＰダイジェストプロトコルは、ＨＴＴＰダイジェストＡＫＡプロトコルである
   ことを特徴とする請求項３に記載の方法。
5. 前記ＨＴＴＰダイジェストプロトコルは、別のプロトコルを使用して、前記第１サーバと前記第２サーバ間をトンネルされる
   ことを特徴とする請求項３または４に記載の方法。
6. 前記別のプロトコルは、ＤＩＡＭＥＴＥＲである
   ことを特徴とする請求項５に記載の方法。
7. 前記クライアントに対する、前記第１サーバ及び前記第２サーバの少なくとも一方を認証する
   ことを特徴とする請求項１乃至６のいずれか１項に記載の方法。
8. 前記クライアントは、前記第１認証チャレンジを使用して、前記第１サーバを認証する
   ことを特徴とする請求項７に記載の方法。
9. 前記クライアントは、前記第２認証チャレンジの受信に応じて前記第２サーバを認証する
   ことを特徴とする請求項７に記載の方法。
10. 通信システム内の認証サーバを操作する方法であって、
    シークレットを共有するクライアントと更なる認証サーバ間の認証に係るシグナリングとして、前記更なる認証サーバから前記クライアントへ送信される第１認証チャレンジと、前記クライアントから前記更なる認証サーバへ送信される第１チャレンジ応答とを含む認証に係るシグナリングを中継し、
    第２認証チャレンジを生成し、前記第２認証チャレンジを前記第１認証チャレンジとともに前記クライアントへ送信し、第２チャレンジ応答を前記第１チャレンジ応答とともに前記クライアントから受信し、
    前記更なる認証サーバからセッションキーを受信し、前記セッションキーと前記第２チャレンジ応答とを使用して前記クライアントを認証する
    ことを特徴とする方法。
11. 前記認証サーバは、Ｕａインタフェースを介してクライアントと通信を行い、かつＺｎインタフェースを介して更なる認証サーバと通信するネットワーク認証機能である
    ことを特徴とする請求項１０に記載の方法。
12. 通信ネットワークで使用するように適合されている認証サーバであって、
    クライアントと更なる認証サーバ間の認証に係るシグナリングとして、前記更なる認証サーバから前記クライアントへ送信される第１認証チャレンジと、前記クライアントから前記更なる認証サーバへ送信される第１チャレンジ応答を含む認証に係るシグナリングを中継する中継手段と、
    第２認証チャレンジを生成し、前記第２認証チャレンジを前記第１認証チャレンジとともに前記クライアントへ送信し、第２チャレンジ応答を前記第１チャレンジ応答とともに前記クライアントから受信する処理手段と、
    前記更なる認証サーバによる前記クライアントの認証を行う、該更なる認証サーバからセッションキーを受信する受信手段と、
    前記セッションキーと前記第２チャレンジ応答とを使用して、前記クライアントの認証を行う処理手段と
    を備えることを特徴とする認証サーバ。
13. 当該認証サーバは、ネットワーク認証サーバである
    ことを特徴とする請求項１２に記載の認証サーバ。
14. 前記中継手段は、前記クライアントから受信するアクセスリクエストが、前記通信ネットワーク内のいくつかの他の機能によって実行されなければならない認証に関連することを判定し、その判定に応じて、前記アクセスリクエストを前記更なる認証サーバへ中継するように構成されている
    ことを特徴とする請求項１３に記載の認証サーバ。
15. 通信ネットワークに接続されているクライアントを操作する方法であって、
    第１認証サーバに対する前記クライアントを認証するために、第２認証サーバを介して前記第１認証サーバとのシグナリングとして、前記第１認証サーバから前記クライアントへ送信される第１認証チャレンジと、前記クライアントから前記第１認証サーバへ送信される第１チャレンジ応答を含むシグナリングを交換し、
    前記クライアントと前記第１認証サーバ間で共有されるシークレットを使用して、セッションキーを生成し、
    前記第２認証サーバから第２認証チャレンジを前記第１認証チャレンジとともに受信し、前記セッションキーを使用して第２チャレンジ応答を生成し、前記第２チャレンジ応答を前記第１チャレンジ応答とともに前記第２認証サーバへ送信する
    ことを特徴とする方法。
16. 前記クライアントは、移動無線通信端末である
    ことを特徴とする請求項１５に記載の方法。
17. クライアントであって、
    第１認証サーバに対する前記クライアントを認証するために、第２認証サーバを介して前記第１認証サーバとのシグナリングとして、前記第１認証サーバから前記クライアントへ送信される第１認証チャレンジと、前記クライアントから前記第１認証サーバへ送信される第１チャレンジ応答を含むシグナリングを交換する処理通信手段と、
    当該クライアントと前記第１認証サーバ間で共有されるシークレットを使用して、セッションキーを生成する処理手段と、
    前記第２認証サーバから第２認証チャレンジを前記第１認証チャレンジとともに受信し、前記セッションキーを使用して第２チャレンジ応答を生成し、前記第２チャレンジ応答を前記第１チャレンジ応答とともに前記第２認証サーバへ送信する入力処理手段と
    を備えることを特徴とするクライアント。
18. 通信ネットワークのネットワークアプリケーション機能に対するユーザ機器を認証する方法であって、
    前記ユーザ機器からのアクセスリクエストを前記ネットワークアプリケーション機能へ送信し、
    前記アクセスリクエストが、前記通信ネットワークのいくつかの他の機能によって実行されなければならない認証に関連することを、前記ネットワークアプリケーション機能で判定し、
    前記アクセスリクエストを、前記他の機能へ転送し、
    前記他の機能から前記ネットワークアプリケーション機能へ、チャレンジを返信し、
    前記チャレンジと、前記ネットワークアプリケーション機能の更なるチャレンジを前記ユーザ機器へ送信し、
    前記ユーザ機器から前記ネットワークアプリケーション機能へチャレンジ応答を送信し、前記他の機能の前記チャレンジに関する応答を、該他の機能へ転送し、
    前記ネットワークアプリケーション機能で前記チャレンジ応答の有効性を検証し、かつ前記他の機能で前記応答の有効性を検証する
    ことを特徴とする方法。
19. 前記ユーザ機器と前記他の機能は、シークレットを共有し、かつ認証処理中に前記シークレットからセッションキーを導出し、
    前記他の機能は、前記セッションキーを前記ネットワークアプリケーション機能へ提供し、
    前記ユーザ機器は、前記セッションキーを使用して、前記チャレンジ応答を生成する
    ことを特徴とする請求項１８に記載の方法。
20. 前記通信システムは、無線アクセスネットワークを備え、
    前記クライアントは、移動体無線通信端末である
    ことを特徴とする請求項１乃至１１、１５、１６、１８及び１９のいずれか１項に記載の方法。

Images