JP5651313B2

JP5651313B2 - 連続する再認証を必要としないｓｉｐシグナリング

Info

Publication number: JP5651313B2
Application number: JP2009207082A
Authority: JP
Inventors: フランクジェイボイル; ゴードンブルンソン; デイビットチャベツ; ステファンドゥルネイ; グレゴリーウエバー
Original assignee: アバイアインク．
Priority date: 2008-09-30
Filing date: 2009-09-08
Publication date: 2015-01-07
Anticipated expiration: 2029-09-08
Also published as: GB2463758B; DE102009041805A1; JP2010086529A; GB2463758A; US20100082977A1; CN101714978A; GB0913599D0; US8689301B2

Description

本発明は、通信ネットワークの伝送プロトコルに関する。

セッション・イニシャル・プロトコル（ＳＩＰ）は、コンピュータネットワークのプロトコルである。このプロトコルは、ＩＰ電話（Voice over Internet Protocol）（マルチメディアを含む）でしばしば使われ、通信セッションを確立し管理し終了させる。セッションとは、通信エンティティの間での半永久的に相互作用する情報交換（例：呼び）である。ＳＩＰは、ＴＣＰ／ＩＰモデルの中のアプリケーション層と、ＩＳＯのOpen Systems Interconnection（ＯＳＩ）のモデルのセッション層にある。標準のＳＩＰシグナリングでは、クライアントからのあらゆるリクエストは、リクエスト毎にチャレンジ／応答メカニズムにより認証され、許可され、リクエストを処理する。この処理は、リクエストが同一セッション内にある場合でも行われる。これは、ＳＩＰを使用するシステムにとって、認証プロセスに際し、大きなオーバーヘッド（負荷）となる。

ある種のＴＣＰ／ＩＰアプリケーション層・シグナリング・プロトコル、例えばTransport Layer Security（ＴＬＳ）プロトコル、あるいはInternet Protocol security（ＩＰｓｅｃ）プロトコルは、クライアントとサーバとの間で、ＴＬＳチャネル又はＩＰｓｅｃチャネルを介して、証明に基礎をおいた（certificate-based）のトラスト関係を確立している。このようなトラスト・ベースの関係は、各リクエストに対するチャレンジの必要性を無くしている。しかし、これは、ＴＬＳ（の上部にあるもの）をトランスポート層プロトコルとして使用するより高度なプロトコル（例：ＳＩＰ）の操作には、影響を及ぼさない。因みに、トランスポート層とは、アプリケーション層からのリクエストに応答して、データをホストコンピュータ上にある適切なアプリケーションプロセスに分配する。さらにこれは、各クライアントの装置上で独自のサーティフィケート（証明）を展開する必要がある。例えば、３ＧＰＰ／ＴＩＳＰＡＮＩＭＳシステムは、Proxy Call Session Control Function（ＰＣＳＣＦ）と称する要素を有する。このＰＣＳＣＦは、ＩＭＳ端末用の接続の第一ポイントである。ＰＣＳＣＦは、ＳＩＰプロキシであるが、ビジターネットワークか或いはホームネットワークの何れかにある。ある種のネットワークは、この機能の為に、Session Border Controller（ＳＢＣ）を使用する。ＩＭＳ端末は、ＰＣＳＣＦを、Dynamic Host Configuration Protocol（ＤＨＣＰ）を介して、発見するか、或いはGeneral Packet Radio System（ＧＰＲＳ）のPacket Data Protocol（ＰＤＰ）コンテキスト内に割り当てられる。ＰＣＳＣＦは、登録された端末に割り当てられて、登録の間、変化しない。ＰＣＳＣＦは、全てのシグナリングのメッセージのパス内にあり、すべてのメッセージを検査する。ＰＣＳＣＦは、ユーザを認証し、ＩＭＳ端末とのIPsec trusted security 関係を確立する。これにより、顧客に管理負荷をかけることになる。

Single Sign-On（ＳＳＯ）は、ユーザが一旦ログインすると、再びログインを催促されることなく、複数のシステムのリソースへのアクセスを獲得できるアクセス制御の方法である。これはセッションとユーザの認証の両方を提供する。各クライアントには、ネットワーク認証サーバで、認証を取り扱うトークン又はソフトウエアが与えられる。Single Sign-Off（ＳＳＯ）は、逆の処理も行い、シグナリングアウトの一回の操作で、複数のシステムへのアクセスを終了する。ＳＳＯは、ＳＳＯに使用されるプロトコルの操作に影響を及ぼさない。

Secure Shell（ＳＳＨ）は、ネットワークで接続された２つの装置の間で、セキュアチャネルを用いて、データを交換するネットワーク・プロトコルである。ＳＳＨは、遠隔にあるサーバにログインし、コマンドを実行するが、これは公開キー方式の暗号化技術を用いて、クライアントとサーバとを認証している。クライアントは、サーバへのセキュア・コネクションを確立し、サービスを要求し、チャレンジを受け、このチャレンジに応答すると、その後の後続のリクエストは、チャレンジを受けない。この認証は、接続が確立している限り、永続的なものであり、サーバは再度チャレンジを受けることはない。

公開キー方式のインフラ（Public Key Infrastructure（ＰＫＩ））により、コンピュータ・ユーザは、前の接触先に互いに認証を要求されることなく、互いにメッセージを暗号化できる。公開キー方式のインフラは、それぞれのユーザの識別子と公開キーとを、サーティフィケート認証機関（信頼された第三者とも称する）で、連結す（関連付け）る。署名者の公開キーサーティフィケートを、信頼された第三者が用いて、署名者の秘密キーを用いて生成されたメッセージのデジタル署名を認証する。一般的に、公開キー方式のインフラは、対話中の両者が、秘密裏にメッセージの完全性を確立する。これは、ユーザの認証機関が、予め秘密情報を交換することなく、更には事前の接触なしで行うことができる。かくして安全を確保した通信を確立するために、多くのアプリケーション層のプロトコルが用いられる。

Ｘ．５０９は、公開キー方式のインフラ用とPribilege Management Infrastructure（ＰＭＩ）用のＩＴＵ−Ｔの標準である。Ｘ．５０９は、特に、公開キー・サーティフィケート（public key sertificate）用と、サーティフィケートの撤回リスト（certificate revocation list）用と、属性サーティフィケート（attribute certificate）用と、サーティフィケートパス有効化アルゴリズム（certification path validation algorithm）用の標準フォーマットを規定する。

Hypertext Transfer Protocol over Secure Sokets Layer（ＨＴＴＰＳ）は、アプリケーション層のプロトコルである。これを用いて、セキュリティが必要な通信に対するワールドワイドウエブ（ＷＷＷ）上の認証と暗号化を提供する。Simple Object Access Protocol（ＳＯＡＰ）は、ＴＣＰ／ＩＰのアプリケーション層のプログラムである。これは、ＨＴＴＰＳを、トランスポート層のプロトコルとして用い、ネットワークを介したメッセージ交換を行う。ＨＴＴＰＳは、アドミニストレーターに対し、あるウエブサーバ用に公開キーサーティフィケートを生成するよう、要求する。このウエブサーバは、アクセスを試みているあらゆるクライアントが、クライアントが既に所有している信頼されたサーティフィケートに基づいて、有効化できるウエブサーバである。有効になるためには、サーティフィケートは、サーティフィケートオーソリティーがサインしなければならない。このスキームは、ウエブサーバへのアクセス権を認証されたユーザにのみ制限するために、クライアントの認証用に用いることもできる。これにより、サイトのアドミニストレーターは、各ユーザに対しサーティフィケートを創設することが要求される。このサーティフィケートは、ユーザのブラウザ、或いはクライアントの装置内に置かれる。

ＳＳＯとＨＴＴＰＳの両方とも、クッキー・ベースである。クッキーは、第一リクエストに応答して確立され、このクッキーに基づいたセキュアトークンを、後続の各リクエストが受領する。このトークンは有効化しなければならず、この有効化には、メッセージ毎にサーバの動作が必要である。このことは、クッキーの管理、記憶、使用に関し、クライアントの機能も必要とすることになる。

時空を越えた公開キー情報の公称認証（public asuthentification）の問題に対する別なアプローチは、トラストスキームのウエブ（Web of Trust scheme）である。これは、自己サインされたサーティフィケート(self-signed certicate)とこのサーティフィケートの第三者立証（third party attestation）を用いて、公開キーとユーザ（の識別子）との間の連結の認証（authenticity）を確立する。このトラストスキームのウエブは、公開キー方式のインフラ（これは、認証機関或いはそのハイラルキーに基礎を置く）とは異なり、分散化している（decentralized）。つまり、このトラストスキームのウエブは、単一のトラストスキームのウエブ、或いはトラストの共通点を意味せず、あらゆる数に分離されたトラストスキームのウエブを意味する。トラストスキームのウエブにおいては、クッキーベースのアプローチと同様に、あらゆる新たなリクエストは、認証しなければならない。これによりネットワーク側の処理のボトルネックが発生する。同様に、クライアントは、トラストスキームのウエブで使用されたサーティフィケートを、管理し、記憶し、適切に有効化しなければならない。

本発明は、安全が確保された接続を介して行われた第一のリクエストに続く後続のリクエストはチャレンジされることはない。ただし以下の条件がある。接続が破られておらず、後続のリクエストは同一のクライアントのためであり、クライアントがシステムから外れたりせず、クライアントのパスワードは変更されず、「セーフティネット」のタイマーが時間経過しておらず、サーバが保証するために選択する他のポリシーがある場合である。言い換えると、接続された第一リクエストはチャレンジされるが、このチャレンジの応答が成功した場合は、クライアントには「フリーパス」が与えられる。その結果、後続のリクエストは、所定の基準に達するまで、チャレンジされる事はない。好ましくは本発明は、下層（例：ＴＬＳ）のプロトコルにおいて、適正に安全確保されたトランスポート層の接続を保護できる利点があり、これにより、接続が、破壊されたり、古くなったり、盗まれたりしない限り、上層のレベルのプロトコル（ＳＩＰ）に送られるあらゆるリクエストを認証する負荷を取り除くことができる。本発明は従来技術と以下の点で異なる。本発明は、セッション内では、あらゆるリクエストに対する後続のチャレンジ／応答のオーバーヘッド（負荷）を無くすことができ、更に好ましくは、クライアント毎の独自のホストクレデンシャル（host credential）（サーティフィケート）の必要性を無くし、このようなサーティフィケートによる管理負荷を無くすことができる点である。

本発明の一実施例によれば、本発明の方法は、（Ａ）通信接続上のクライアントの第一リクエスト（例、ＳＩＰリクエスト）に応答して、前記クライアントを認証する（チャレンジ／応答機構を介して）。（Ｂ）前記通信接続上のクライアントの、前記第一リクエストの後の第二リクエストに応答して、前記クライアントの認証を中止する、即ち、認証が中止される。（Ｃ）前記通信接続上のクライアントの、前記第二リクエストの後の第三リクエストに応答して、前記クライアントを再度認証する。例えば、この再認証（第三リクエスト）は、元となっている接続が破れ再度確立された時、リクエストが別のクライアントの為にものであった時、「セーフェティネット」タイマーが時間切れになった時に起こる。認証が成功した場合はリクエストは応じられ、認証が不成功の場合はリクエストは応じられない。

本発明は方法としても装置としても更には又方法のインストラクションを含むコンピュータで読み込み可能な媒体としても実行できる。又本発明はコンピュータで実行できる。

通信ネットワークのブロック図。図１の通信ネットワークの従来技術のＳＩＰシグナリングのブロック図。ユーザデータ・レコードのブロック図。本発明による図１の通信ネットワークのシグナリングのブロック図。本発明による図１の通信ネットワークのシグナリングのブロック図。本発明の他の通信ネットワークのブロック図

図１は通信システムを表す。この通信システムにおいて、複数の通信端末１０２−１０４が、相互に接続され、一つ或いは複数のネットワーク１１０により認証機構１１２に接続される。通信端末１０２−１０４は、あらゆる種類のエンドユーザ通信機器（例えば、携帯電話、パーソナルデジタルアシスタント、インターネット電話、パソコン等）、或いはあらゆる種類のサーバ（例えばウエブページサーバ、Ｅメールサーバ、インスタントメッセージ（ＩＭサーバ）、データベースサーバ、ゲートウェイキャッシュ等）でもよい。ネットワーク１１０は、あらゆる種類のネットワークを含む。例えばＬＡＮ、ＷＡＮ（インターネット）、非同期転送モード（ＡＴＭ）、ネットワーク等である。

認証機構１１２は、通信端末１０２−１０４のユーザのＩＤ（身元）を認証するあらゆる機構である。この実施例においては、認証機構１１２は、プロキシ・サーバ１１４と認証機関１１６とを含む。プロキシ・サーバ１１４は、複数の通信端末１０２−１０４の中のクライアントからのリクエストにサービスするサーバであり、これは、このリクエストを通信端末１０２−１０４内のサーバに送ることにより行われる。サービスを要求するクライアントがプロキシ・サーバ１１４に接続される。このサービルは、例えばファイル接続、ウエブページ、或いはサーバから利用可能な他のリソースである。プロキシ・サーバ１１４は、クライアントをサーバに接続し、サービスをクライアントのために要求することにより、リソースを提供する。プロキシ・サーバ１１４により提供されるサービスの一つは、ユーザ認証（user authentification）である。それは、認証機関１１６の助けを借りて（即ち認証機関１１６を介して）提供する。プロキシ・サーバ１１４は、記憶されたプログラムで制御される機械である。この機械は、インストラクションを記憶する記憶装置と、このインストラクションを実行するプロセッサ（例：コンピュータ）とを含む。この記憶装置とプロセッサがプロキシ・サーバ１１４を構成する。認証機関１１６は、サーバー、例えば認証マネージャー、或いは信頼された第三者装置である。このサーバは、ユーザを認証するのに用いられる情報を含む。

図に示すように、ネットワーク１１０は、ＳＩＰネットワーク、Ｘ．３２３ネットワーク、ウエブサービス・ネットワーク、或いは他の種類のネットワークを含む。この他の種類のネットワークは、セッション内で各ユーザのリクエストを認証するプロトコルを利用する。これは、元となるプロトコルが、通信接続セキュリティを提供する場合（例：ＴＬＳプロトコル、ＴＣＰプロトコルの場合）、又は通信接続セキュリティを提供しない場合（ＵＤＰプロトコル又はＴＣＰプロトコルの場合）に拘わらず、行われる。これにより、ユーザがリクエストをプロキシ・サーバ１１４に送っている間、認証機関１１６と通信するために、プロキシ・サーバ１１４を要求するユーザを常に再度認証する必要がある。

この一例を図２に示す。同図を参照して、ＳＩＰネットワークを例に説明する。通信を開始するために、通信端末１０２は、ＳＩＰ登録リクエスト（ＲＥＧ）を生成する。このリクエストは、通信端末１０２のユーザ（クライアント）の登録アドレス（ＡＯＲ：address of record）を含む。元となるトランスポートプロトコルは、通信端末１０２とプロキシ・サーバ１１４（プロキシ・サーバ１１４の特定のソケット）との間の接続ライン１２０を確立する。この接続は、独自の識別子（接続識別子（connection identifier））を有する。その後、通信端末１０２は、ＲＥＧをプロキシ・サーバ１１４に接続ライン１２０を介して送信する（ステップ２０２）。通信端末１０２からプロキシ・サーバ１１４にセッションの一部として送信された各リクエストは、ＲＥＧリクエストを含むが、クライアントのＡＯＲと接続ライン１２０の接続識別子も含む。例えば、ＴＣＰは、端末ＩＰアドレス、端末ＩＰポート、サーバＩＰアドレス、サーバ一ＩＴポートからなるの４つの組を接続識別子として用いる。ＲＥＧを受信したことに応答して、プロキシ・サーバ１１４は、認証リクエスト（ＡＵＴＨ．ＲＥＱ）を認証機関１１６に送信する（ステップ２０６）。この認証リクエストはＡＯＲを含む。認証機関１１６は、プロキシ・サーバ１１４へクライアントに対する第一のチャレンジ（ＣＨＡＬＬＥＮＧＥ１）を送信することにより、応答する（ステップ２０８）。それに応答して、プロキシ・サーバ１１４は、通信端末１０２への第一のチャレンジを含む４０１（認証がリクエストされる）ＳＩＰメッセージ（又は４０７（プロキシ認証が要求される））のような他のＳＩＰメッセージを、接続ライン１２０を介して送信する（ステップ２１２）。通信端末１０２は、第一チャレンジへのクライアントの応答を含む他のＲＥＧリクエスト（ＷＩＴＨＣＨＡＬＬＥＮＧＥ１ＲＥＳＰＯＮＳＥ）で応答する（ステップ２１４）。プロキシ・サーバ１１４は、この応答を認証機関１１６に転送する（ステップ２１６）。この応答が時間内にある場合には、認証機関１１６は、通信端末１０２から受信した応答と登録した正しい応答とを比較し、それらが一致した場合には、「チャレンジは成功裏に応答された」のメッセージをプロキシ・サーバ１１４に送る（ステップ２１７）。これに応答して、プロキシ・サーバ１１４は２００ＯＫＳＩＰメッセージを、通信端末１０２に送る（ステップ２２０）。

通信端末１０２が電話の呼びを開始しようとすると、通信端末１０２は、インバイトＳＩＰリクエスト（ＩＮＶ）をプロキシ・サーバ１１４に送る（ステップ２２２）。このリクエストに応答して、プロキシ・サーバ１１４は、別の認証リクエストを認証機関１１６に送る（ステップ２３０）。認証機関１１６は、クライアントへの第二のチャレンジで応答する（ステップ２３２）。プロキシ・サーバ１１４は、第二のチャレンジを、通信端末１０２に、４０１ＳＩＰメッセージに含めて、転送する（ステップ２３４）。通信端末１０２は、クライアントの応答を含むＩＮＶＳＩＰメッセージで、応答する（ステップ２３６）。このメッセージをプロキシ・サーバ１１４が認証機関１１６に転送する（ステップ２３８）。クライアントの応答が、タイムリーであり且つ正しい応答と一致する場合には、認証機関１１６は、「チャレンジは成功裏に応答された」のメッセージをプロキシ・サーバ１１４に送り（ステップ２３９）、プロキシ・サーバ１１４は、２００ＯＫＳＩＰメッセージを、通信端末１０２に送る（ステップ２５０）。

通信端末１０２が、別のリクエストをプロキシ・サーバ１１４に送ると（ステップ２５２）、プロキシ・サーバ１１４は、別の認証リクエストを認証機関１１６に送り（ステップ２６０）、認証機関１１６は、第三のチャレンジを戻す（ステップ２６２）。プロキシ・サーバ１１４は、４０１ＳＩＰメッセージを第三のチャレンジと共に通信端末１０２に送る（ステップ２６４）。通信端末１０２は、このリクエストと第三のチャレンジへのクライアントの応答を、プロキシ・サーバ１１４に再度送る（ステップ２６６）。これをプロキシサーバが、認証機関１１６に転送する（ステップ２６８）。クライアントの応答が、タイムリーであり且つ正しい応答と一致する場合には、認証機関１１６は、「チャレンジは成功裏に応答された」とのメッセージをプロキシ・サーバ１１４に送り（ステップ２６９）、プロキシ・サーバ１１４は、２００ＯＫＳＩＰメッセージを、通信端末１０２に送る（ステップ２７４）。このプロセスを、後続のＳＩＰリクエストに対し繰り返す。

特に、プロキシ・サーバ１１４と認証機関１１６が、互いにネットワーク（例：図１のネットワーク１１０）を介して通信する離れた位置にあるデバイスの場合には、プロキシ・サーバ１１４と認証機関１１６との間で継続する通信は、認証機関１１６上に重い負荷となり、大量のネットワークトラフィックを形成し、時間を浪費することになる。これ等は全て好ましいことではない。

本発明の一態様によれば、プロキシ・サーバ１１４の動作を修正して、プロキシ・サーバ１１４が、各クライアントの各リクエストを認証機関１１６では認証しないようにする。その代わりに、プロキシ・サーバ１１４は、通信端末１０２−１０４とプロキシ・サーバ１１４との間で、接続ライン１２０を介して、トランスポートプロトコル（例、ＴＬＳ又はＩＰｓｅｃ）で確立された信頼された関係に依存する。これにより長時間のセキュリティを提供する。トランスポートプロトコルの安全が確保されていない（例えばＵＤＰ又はＴＣＰ）場合でも、各リクエストの認証は、高レベルのセキュリティが必要ではない場合には、必要としない。このような場合、元となるトランスポートプロトコルは、そのセッションに、ハイジャックに対する保護を与え、このセッションの破壊を報告することが重要である。

ＳＩＰプロトコルを例に説明した変形例の他の実施例によれば、プロキシ・サーバ１１４は、通信端末１０２−１０４の登録されたユーザ用に、ユーザ・データ・レコード３００を保持する（図３）。このユーザ・データ・レコード３００は、エントリ（ＡＯＲ）３０２と、エントリ（接続識別子）３０４と、エントリ（タイマー／消滅時間）３０６とを有する。エントリ（ＡＯＲ）３０２は、クライアントのＡＯＲを含む。エントリ（接続識別子）３０４は、クライアントのプロキシ・サーバ１１４への接続識別子を含む。エントリ（タイマー／消滅時間）３０６は、クライアントの現在の認証が消滅する時間或いはタイマーの何れかを含む。

この実施例によれば、通信端末１０２のユーザは、従来と同様に、プロキシ・サーバ１１４に登録される（ステップ４０２−４１７）で、これは図２のステップ２０２−２１７の繰り返しである。通信端末１０２のユーザの認証を行った後、プロキシ・サーバ１１４は、エントリ（タイマー／消滅時間）３０６のタイマーを開始させ、エントリ（タイマー／消滅時間）３０６に、認証が消滅する時間を入力する（ステップ２１６）。エントリ（タイマー／消滅時間）３０６内で測定された或いは示された時間は、所望の如何なる時間でもよく、例えば２４時間である。その後、プロキシ・サーバ１１４は、２００ＯＫＳＩＰメッセージを、通信端末１０２に送り（ステップ４２０）、これにより登録を完了する。

通信端末１０２のユーザが呼びを開始すると、通信端末１０２は、ＩＮＶＳＩＰリクエストを生成し、それをプロキシ・サーバ１１４に送る（ステップ４２２）。それに応答して、プロキシ・サーバ１１４は、そのクライアントの認証が消滅したか否かをチェックする（ステップ４２４）。プロキシ・サーバ１１４は、これを、クライアントのユーザ・データ・レコード３００のエントリ（タイマー／消滅時間）３０６をチェックして行い、タイマーが時間切れになったか、或いはエントリ（タイマー／消滅時間）３０６内に登録された時間が現在の時間を過ぎているかの何れかを決定する。認証が消滅していない場合には、プロキシ・サーバ１１４は、ＩＮＶＳＩＰリクエストで受領したＡＯＲと接続識別子とを、クライアントのユーザ・データ・レコード３００内のエントリ（ＡＯＲ）３０２，エントリ（接続識別子）３０４の対の内容とチェックして、それらが一致するかを決定する（ステップ４２６）。それらが一致しない場合とは、通信端末１０２とプロキシ・サーバ１１４との間の接続ライン１２０が、切断されて（故障して）、再度確立され、その結果、リクエストで受信した接続識別子が、クライアントのユーザ・データ・レコード３００内のエントリ（接続識別子）３０４に記録された接続識別子と異なる場合である。そのため、プロキシ・サーバ１１４は、クライアントのユーザ・データ・レコード３００の更新を、エントリ（接続識別子）３０４の内容を新たな接続識別子に変更することにより行う（ステップ４２８）。認証が消滅しているか或いはデータ対が一致しない場合には、再度の認証が要求され、その結果、プロキシ・サーバ１１４は、クライアントを再度認証する（ステップ４３０−４３９）。これは、図２のステップ２３０−２３９の繰り返しである。その後、プロキシ・サーバ１１４は、タイマーを再度スタートさせるか、クライアントのユーザ・データ・レコード３００内のエントリ（タイマー／消滅時間）３０６に新たな消滅時間を設定する（ステップ４４０）。認証が消滅しておらずデータ対が一致する場合には、クライアントの再認証は必要ない。その結果、プロキシ・サーバ１１４は、ステップ４２８−４３６をスキップする。その後、プロキシ・サーバ１１４は、２００ＯＫＳＩＰメッセージを通信端末１０２に送り、図５のステップ５５０を実行する。

通信端末１０２が、別のリクエストをプロキシ・サーバ１１４に送る（ステップ５５２）と、プロキシ・サーバ１１４は、ステップ４２４−４２８の実行を繰り返す（ステップ５５４−５５８）。認証が消滅しているかデータ対が一致しない場合には、プロキシ・サーバ１１４は、クライアントを再度認証し（ステップ５６０−５６９）、これはステップ４３０−４３９の繰り返しであるが、タイマーを再度スタートさせるか、或いはユーザ・データ・レコード３００のエントリ（タイマー／消滅時間）３０６に新たな時間を入れる（ステップ５７０）。認証が消滅しておらずデータ対が一致する場合には、プロキシ・サーバ１１４は、ステップ５５８−５７０をスキップし、直接、２００ＯＫＳＩＰメッセージを通信端末１０２に送信する（ステップ５７４）。このプロセスを、各後続のＳＩＰリクエストに対し実行する。

図２に示したのとは別の構成として、プロキシ・サーバ１１４は、ステップ２１４の後、ステップ２３０−２３２を実行し、第二のチャレンジを、通信端末１０２に、２００ＯＫメッセージの形態で送信する（ステップ２２０）。これにより、ステップ２２２と２３４をスキップする。同様にプロキシ・サーバ１１４は、ステップ２３６の後のステップ２６０−２６２を実行し、第三のチャレンジを、通信端末１０２に、２００ＯＫメッセージで送信する（ステップ２５０）。これによりステップ２５２，２６４をスキップできる。後も同様である。これも「ｎｅｘｔｎｏｎｃｅ」構造として公知である。この別の構成のシグナリングスキームは、プロキシ・サーバ１１４と通信端末１０２との間のシグナリングトラフィックの量を減らすが、プロキシ・サーバ１１４と認証機関１１６との間のシグナリングトラフィックの周期の量には影響を及ぼさない。

本発明は別の構成でも同様に使用できる。これは、クライアントに、最後に送ったチャレンジを各２００ＯＫメッセージと共に、再度送信することにより、行う。

図６は、図１の通信システムの別の形態を示す。この実施例においては、ネットワーク１１０は、ゲ−トウエイで接続された少なくとも２個のネットワーク６４０、６４２を有する。ＳＩＰネットワークにおいては、ゲートウエイはセッション・ボーダ・コントローラ６４４である、例えばBorder Security Controller（ＢＳＣ）である。通信端末１０２−１０４は、セッション・ボーダ・コントローラ６４４に、ネットワーク６４０内の接続ライン６３０を介して接続される。また、セッション・ボーダ・コントローラ６４４は、プロキシ・サーバ１１４に、ネットワーク６４２内の一つ或いは複数の接続ライン６２０を介して接続される。その結果、接続ライン６３０のうちの一つがダウンすると、セッション・ボーダ・コントローラ６４４上の別の接続に再度回復されることになる。その結果、この接続ライン６３０の接続識別子が変わり、プロキシ・サーバ１１４は、この変更を知らされない。その理由は、接続ライン６２０の接続識別子が変更されていないからである。セッション・ボーダ・コントローラ６４４が、１つの通信端末１０２のみをプロキシ・サーバ１１４に接続ライン６２０を介して接続する場合には、この問題に対する一つの解決方法は、対応する接続ライン６３０がダウンし再登録された時にはいつでも、セッション・ボーダ・コントローラ６４４がダウンし、接続ライン６２０を回復する。しかし、セッション・ボーダ・コントローラ６４４が、複数の通信端末１０２−１０４をプロキシ・サーバ１１４に接続ライン６２０を介して接続する場合には、この解決方法は実際的ではない。この場合、この問題に対する実際の解決方法は、接続ライン６２０が回復されてた場合には何時でも、セッション・ボーダ・コントローラ６４４は、プロキシ・サーバ１１４に信号を送り、プロキシ・サーバ１１４が、この通知を同じように処理し（図４、５）、図１の接続ライン１２０の接続識別子の変更を通知することである。この所望のシグナリングスキームは、この為に採用されている。このシグナリングを行う一つの方法は、高級ＳＩＰシグナリングを介することである。この場合、ＰＡＤトランスポートヘッダーは、フロートークン−パラメータを有する。このパラメータは、ダウンし回復されたあらゆる接続ライン６３０のセッション・ボーダ・コントローラ６４４上の接続を識別する。

例えば本発明の変形例として、上記の説明はＳＩＰに関するものであるが、本発明は低いレベルの接続指向トランスポートプロトコルの上で走り、認証を必要とする高いレベルのプロトコルにも適用可能である。このようなプロトコルの一例は、例えばファイルトランスファ、ＳＳＨ、ＨＴＴＰ、アプリケーションシェアリング、ｅ−メール或いはリクエストにチャレンジする他のアプリケーションプロトコルである。

以上の説明は、本発明の一実施例に関するもので、この技術分野の当業者であれば、本発明の種々の変形例を考え得るが、それらはいずれも本発明の技術的範囲に包含される。特許請求の範囲の構成要素の後に記載した括弧内の番号は、図面の部品番号に対応し、発明の容易なる理解の為に付したものであり、発明を限定的に解釈するために用いてはならない。また、同一番号でも明細書と特許請求の範囲の部品名は必ずしも同一ではない。これは上記した理由による。

１０２−１０４通信端末
１０２通信端末
１１０ネットワーク
１１２認証機構
１１４プロキシ・サーバ
１１６認証機関
１２０接続ライン
３００ユーザ・データ・レコード
３０２エントリ（ＡＯＲ）
３０４エントリ（接続識別子）
３０６エントリ（タイマー／消滅時間）
６２０接続ライン
６３０接続ライン
６４０ネットワーク
６４２ネットワーク
６４４セッション・ボーダ・コントローラ
図４
ステップ
４１８タイマー開始／消滅時間の設定
４２４認証は消滅したか？
４２６データ対は一致するか？
４２８記録の更新
４４０タイマー開始／消滅時間の設定
５５４認証は消滅したか？
５５６データ対は一致するか？
５５８記録の更新
５７０タイマー開始／消滅時間の設定

Claims

ＳＩＰシグナリングを認証する方法において、
（Ａ）通信接続上のクライアントの音声の呼びを開始する第一リクエストに応答して、前記クライアントを認証するか否かのクライアント認証処理を実行して、前記認証されたクライアントと前記第一リクエストに含まれる第一接続識別子とを記憶装置内に関連づけて記憶するステップと、
（Ｂ）前記通信接続上の前記クライアントの、前記第一リクエストの後の第二リクエストに応答して、前記クライアント認証処理を留保するステップと、
（Ｃ）前記通信接続上のクライアントの、前記第二リクエストの後の第三リクエストに応答して、前記クライアント認証処理を実行するステップと、
を有し、
前記ステップ（Ｂ）は、
（Ｂ１）前記第二リクエストに含まれる第二接続識別子が、前記第一接続識別子と一致するか否かを決定するサブステップと、
（Ｂ２）一致するとの決定に応答して、前記クライアント認証処理を留保するサブステップとを有し、
前記ステップ（Ｃ）は、
（Ｃ１）前記第三リクエストに含まれる第三接続識別子が、前記第一接続識別子と一致するか否かを決定するサブステップと、
（Ｃ２）一致しないとの決定に応答して、前記クライアント認証処理を実行するサブステップとを有する
ことを特徴とするＳＩＰシグナリングを認証する方法。
（Ｄ）前記クライアントの認証の成功に応答して、前記リクエストに応ずるステップと、
（Ｅ）前記クライアントの認証の失敗に応答して、前記リクエストに応ずるのを留保するステップと、
を更に有する
ことを特徴とする請求項１記載の方法。
前記（Ｂ）ステップは、
（Ｂ３）前記第二接続識別子が前記第一接続識別子と一致するとの決定に応答して、
（ａ）前記クライアントのいずれかの識別子が、前記第一接続識別子から変化したか否か、又は（ｂ）前記クライアントの認証期間が経過したか否かを決定するサブステップと、
（Ｂ４）（ａ）前記クライアントの識別子が変化していないとの決定と（ｂ）前記クライアントの認証期間が経過していないとの決定の両方に応答して、前記クライアント認証処理を留保するサブステップと、
を有し、
本発明の方法は、
（Ｆ）（ａ）前記クライアントのいずれかの識別子が変化しているとの決定、又は（ｂ）前記クライアントの認証期間が経過していると決定に応答して、前記クライアント認証処理を実行するステップと
を更に有する
ことを特徴とする請求項１記載の方法。
前記（Ｂ）ステップは、前記第二接続識別子が前記第一接続識別子と一致しないとの決定に応答して、前記クライアント認証処理を実行するサブステップを有する
ことを特徴とする請求項１記載の方法。
前記（Ｃ）ステップは、
（Ｃ１）前記クライアントの第一リクエスト又は第三リクエストの個々の１つに応答して、認証機関にチャレンジのリクエストを送信するステップと、
（Ｃ２）前記クライアントからのチャレンジに対する応答を受信したことに応答して、前記リクエストが正規であるか否かを決定するステップと、
（Ｃ３）前記応答が正規であると決定したことに応じて、前記個々のリクエストに応じるステップと、
（Ｃ４）前記リクエストが正規ではないとの決定に応答して、前記個々のリクエストに応じることを留保するステップと、
を有する
ことを特徴とする請求項１記載の方法。
ＳＩＰシグナリングを認証する装置において、
（Ａ）インストラクションを記憶する記憶装置と、
（Ｂ）前記インストラクションを実行するプロセッサと、
を有し、前記記憶装置とプロセッサがサーバを構成し、
前記サーバは、
（Ａ）通信接続上のクライアントの音声の呼びを開始する第一リクエストに応答して、前記クライアントを認証するか否かのクライアント認証処理を実行し、前記認証されたクライアントと前記第一リクエストに含まれる第一接続識別子とを記憶装置内に関連づけて記憶し
（Ｂ）前記通信接続上のクライアントの、前記第一リクエストの後の第二リクエストに応答して、前記クライアント認証処理を留保し、これは、（Ｂ１）前記第二リクエストに含まれる第二接続識別子が、前記第一接続識別子と一致するか否かを決定し、（Ｂ２）一致するとの決定に応答して、前記クライアント認証処理を留保することにより行われ、
（Ｃ）前記通信接続上のクライアントの、前記第二リクエストの後の第三リクエストに応答して、前記クライアント認証処理を実行し、これは、（Ｃ１）前記第三リクエストに含まれる第三接続識別子が、前記第一接続識別子と一致するか否かを決定し、（Ｃ２）一致しないとの決定に応答して、前記クライアント認証処理を実行することにより行われる
ことを特徴とするＳＩＰシグナリングを認証する装置。
前記サーバは、
前記リクエストに応ずることにより、前記クライアントの認証の成功に応答し、
前記リクエストに応ずるのを留保することにより、前記クライアントの認証の失敗に応答する
ことを特徴とする請求項６記載の装置。
前記サーバは、前記第二接続識別子が前記第一接続識別子と一致するとの決定に応答して、前記クライアント認証処理を留保し、
（１）前記クライアントのいずれかの識別子が、前記第一接続識別子から変化したか否か、又は（２）前記クライアントの認証期間が経過したか否かを決定し、
（１）前記クライアントのいずれかの識別子が変化しているとの決定、又は（ｂ）前記クライアントの認証期間が経過しているとの決定に応答して、前記クライアント認証処理を実行する
ことを特徴とする請求項６記載の装置。
前記サーバは、
（ａ）前記クライアントの第一リクエスト又は第三リクエストの個々の１つに応答して、認証機関にチャレンジのリクエストを送信し、
（ｂ）前記クライアントからのチャレンジに対する応答を受信したことに応答して、前記リクエストが正規であるか否かを決定する為に、前記応答を認証機関に転送し、
前記サーバは、
前記個々のリクエストに応じることにより、前記応答が正規であるとの決定に応答し、
前記個々のリクエストに応じることを留保することにより、前記リクエストが正規ではないとの決定に応答する
ことを特徴とする請求項６記載の装置。