JP4294268B2 - クライアント・プロキシ認証のためにセッションイニシエーションプロトコルリクエストメッセージにセキュリティ機構を組み込むための方法およびシステム - Google Patents

クライアント・プロキシ認証のためにセッションイニシエーションプロトコルリクエストメッセージにセキュリティ機構を組み込むための方法およびシステム Download PDF

Info

Publication number
JP4294268B2
JP4294268B2 JP2002174951A JP2002174951A JP4294268B2 JP 4294268 B2 JP4294268 B2 JP 4294268B2 JP 2002174951 A JP2002174951 A JP 2002174951A JP 2002174951 A JP2002174951 A JP 2002174951A JP 4294268 B2 JP4294268 B2 JP 4294268B2
Authority
JP
Japan
Prior art keywords
sip
proxy
client
sip proxy
session key
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2002174951A
Other languages
English (en)
Other versions
JP2003108527A (ja
Inventor
デミアジス アン
ピー.ボブデ ニキル
ハン ムー
Original Assignee
マイクロソフト コーポレーション
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority to US29823901P priority Critical
Priority to US60/298,239 priority
Priority to US10/151,747 priority
Priority to US10/151,747 priority patent/US7243370B2/en
Application filed by マイクロソフト コーポレーション filed Critical マイクロソフト コーポレーション
Publication of JP2003108527A publication Critical patent/JP2003108527A/ja
Application granted granted Critical
Publication of JP4294268B2 publication Critical patent/JP4294268B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/12Applying verification of the received information
    • H04L63/123Applying verification of the received information received data contents, e.g. message integrity
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L29/00Arrangements, apparatus, circuits or systems, not covered by a single one of groups H04L1/00 - H04L27/00
    • H04L29/02Communication control; Communication processing
    • H04L29/06Communication control; Communication processing characterised by a protocol
    • H04L29/0602Protocols characterised by their application
    • H04L29/06027Protocols for multimedia communication
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/08Network architectures or network communication protocols for network security for supporting authentication of entities communicating through a packet data network
    • H04L63/0807Network architectures or network communication protocols for network security for supporting authentication of entities communicating through a packet data network using tickets, e.g. Kerberos
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/20Network architectures or network communication protocols for network security for managing network security; network security policies in general
    • H04L63/205Network architectures or network communication protocols for network security for managing network security; network security policies in general involving negotiation or determination of the one or more network security mechanisms to be used, e.g. by negotiation between the client and the server or between peers or by selection according to the capabilities of the entities involved
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements or protocols for real-time communications
    • H04L65/10Signalling, control or architecture
    • H04L65/1003Signalling or session protocols
    • H04L65/1006SIP
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/08Network architectures or network communication protocols for network security for supporting authentication of entities communicating through a packet data network
    • H04L63/0869Network architectures or network communication protocols for network security for supporting authentication of entities communicating through a packet data network for achieving mutual authentication

Description

【0001】
【発明の属する技術分野】
本発明は一般に、コンピュータネットワークを介した装置間通信に関し、詳細には、セキュリティ機構、例えばケルベロス認証プロトコルに基づくセキュリティ機構を、セッションイニシエーションプロトコル(SIP:Session Initiation Protocol)を通信セッションを確立するためのシグナリングプロトコルとして使用したネットワーク通信に組み込むことに関する。
【0002】
【従来の技術】
セッションイニシエーションプロトコル(SIP)は、コンピューティング装置が、自体がコンピュータネットワークを介して通信したいと欲している他の装置の位置を突き止め、その装置との間に通信セッションを確立するための機構を提供するシグナリングプロトコルである。SIPは汎用性のあるプロトコルであり、多くの異なるシナリオで通信セッションを確立するのに使用されてきた。SIPは例えば、インターネット会議、電話、プレゼンス(presence)、イベント通知およびインスタントメッセージングに使用されている。SIPの重要な強みは、位置独立の単一のアドレスの下にいる被呼者(ユーザ)に、たとえこの被呼者が別のコンピュータに移動していたとしてもたどり着くことができる、パーソナルモビリティ(personal mobility)をサポートしていることである。
【0003】
SIPに基づくセッション開始オペレーションの共通する1つのモードは「プロキシ(proxy)モード」である。例えば、SIPクライアント(「呼出し元」)は、意図された受信者(「呼出し先」)を電子メールアドレスに似たアドレスによって識別するINVITEメッセージなどのSIPリクエストメッセージを送ることができる。このリクエストメッセージは一般にまず、送信側SIPクライアントのアウトバウンド(outbound)SIPプロキシに送られる。次いでこのアウトバウンドSIPプロキシがこのリクエストメッセージを、しばしば他の中間SIPプロキシを介して、意図された受信側クライアントが登録されているSIPプロキシに転送し、次いでこのSIPプロキシが、INVITEメッセージを受信側クライアントに送る。受信側クライアントの受入れメッセージ(「200OK」)が、シグナリングチェーンを介して呼出し元クライアントに戻され、これによって、呼出し元クライアントは呼出し先クライアントと、一般にシグナリングチャネルとは別の媒体チャネルを通して通信できるようになる。他のSIPクライアントと通信する他に、SIPクライアントはさらに、REGISTERリクエストを送ることによってSIPレジストラ(registrar)に自体を登録するなどの目的で、SIPサーバと通信することができる。
【0004】
【発明が解決しようとする課題】
さまざまな応用に対して幅広く実装されてはいるが、SIPは、主としてシグナリングオペレーション用に設計されたものである。SIPは、通信セッションのセキュリティおよびプライバシーを保護するためのセキュリティ機構を明示的に提供せず、またはこれを必要としない。しかし多くのケースで、SIPクライアントが、SIPクライアントのユーザを認証するよう求めるリクエストをアウトバウンドSIPプロキシに送ることを要求し、アウトバウンドSIPプロキシが、SIPクライアントに対して自体を認証することを要求することが望ましい。さらに、SIPリクエストメッセージの完全性を保護することもしばしば必要である。クライアント・プロキシ認証およびメッセージの完全性はともに、信頼性の高いセキュリティ機構の使用を要求する。したがって、信頼性の高いセキュリティ機構をSIPシグナリングオペレーションと組み合わせて、SIPクライアントとアウトバウンドプロキシとの間の認証を可能にすることが求められている。しかし、所望のセキュリティ機構をSIPシグナリングフレームワークにどのようにはめ込んで、目的の異なるこれらの2つの機構を一緒に効果的に実行することができるようにするかということが技術上の課題である。
【0005】
【課題を解決するための手段】
以上のことを考慮して、本発明は、ケルベロス(Kerberos)プロトコル、NTLMプロトコルなどのセキュリティ機構を、SIPシグナリングオペレーションのメッセージフローに組み込んで、SIPクライアントとSIPプロキシが相互に認証できるようにするための方式を提供する。本発明によれば、SIPクライアントからSIPリクエストメッセージを受け取ると、プロキシはこれに応答して、予め選択されたセキュリティ機構に基づく認証が必要であることを指示するチャレンジメッセージを送る。これに応答してSIPクライアントは、前記セキュリティ機構に基づいてサーバに対してクライアントを認証するための認証データを含むproxy authorizationヘッダを有する前記リクエストメッセージの第2バージョンないし改訂バージョンを送る。ケルベロスセキュリティ機構を使用する場合には、proxy authorizationヘッダが、プロキシにアクセスするためにクライアントが取得したケルベロスサーバチケットを表すデータを含む。proxy authorizationヘッダのデータに基づくクライアントのユーザの認証に成功した場合、SIPプロキシは、SIPクライアントとリクエストメッセージの意図された受信者との間のSIPメッセージシグナリング経路に沿ってこのリクエストを転送する。SIPクライアントが相互認証を要求している場合、SIPプロキシは、クライアントに送る次のメッセージにproxy authentication information(プロキシ認証情報)ヘッダを追加する。このメッセージは例えば、INVITEリクエストに応答して呼出し先SIPクライアントが生成した「200OK」SIP応答、またはREGISTERメッセージに応答してSIPレジストラサーバが生成した「200OK」応答である。proxy authentication informationヘッダは、クライアントがSIPプロキシを認証するための認証データを含む。
【0006】
本発明の特徴は請求項に詳細に記述されているが、本発明、ならびに本発明の目的および利点は、添付図面を参照して以下の詳細な説明を読むことによって最もよく理解されよう。
【0007】
【発明の実施の形態】
図面を参照すると、適当なコンピューティング環境中に実現された本発明が示されている。図面中、同様の参照符号は同様の要素を指す。そうでなければならないというわけではないが、本発明は、パーソナルコンピュータによって実行される、プログラムモジュールなどのコンピュータ実行可能命令の一般的な文脈で説明される。プログラムモジュールには一般に、特定のタスクを実行し、または特定の抽象データ型を実装するルーチン、プログラム、オブジェクト、コンポーネント、データ構造などが含まれる。さらに、本発明を、ハンドヘルド装置、マルチプロセッサシステム、マイクロプロセッサベースの、またはプログラム可能な家庭用電子機器、ネットワークPC、ミニコンピュータ、メインフレームコンピュータなどを含む他のコンピュータシステム構成とともに実施できることを当業者は理解されたい。本発明は、通信ネットワークを介してリンクされた遠隔処理装置によってタスクが実行される分散コンピューティング環境で実施することができる。分散コンピューティング環境では、プログラムモジュールが、ローカルメモリ記憶装置と遠隔メモリ記憶装置の両方に位置することができる。
【0008】
以下の説明ではまず、本発明を実現するための例示的なシステム中で使用することができる汎用コンピューティング装置を説明し、次いで、図2〜9を参照して本発明をより詳細に説明する。図1を参照すると、処理ユニット21、システムメモリ22およびシステムバス23を含む従来のパーソナルコンピュータ20の形態の汎用コンピューティング装置が示されている。システムバス23は、システムメモリを含むさまざまなシステムコンポーネントを処理ユニット21に結合する。システムバス23は、さまざまなバスアーキテクチャのうちの任意のアーキテクチャを使用した、メモリバスまたはメモリコントローラ、周辺バスおよびローカルバスを含むいくつかのタイプのバス構造のうちの任意の構造とすることができる。システムメモリは、リードオンリーメモリ(ROM)24およびランダムアクセスメモリ(RAM)25を含む。ROM24には、起動時などにパーソナルコンピュータ20の内部要素間の情報転送を助ける基本ルーチンを含む基本入出力システム(BIOS)26が記憶されている。パーソナルコンピュータ20はさらに、ハードディスク60の読取り/書込み用のハードディスクドライブ27、リムーバブル磁気ディスク29の読取り/書込み用の磁気ディスクドライブ28、およびCD−ROMまたは他の光媒体などのリムーバブル光ディスク31の読取り/書込み用の光ディスクドライブ30を含む。
【0009】
ハードディスクドライブ27、磁気ディスクドライブ28および光ディスクドライブ30はそれぞれ、ハードディスクドライブインタフェース32、磁気ディスクドライブインタフェース33、および光ディスクドライブインタフェース34によってシステムバス23に接続されている。これらのドライブおよび関連コンピュータ可読媒体は、コンピュータ可読命令、データ構造、プログラムモジュール、およびパーソナルコンピュータ20のためのその他のデータを記憶する不揮発性記憶装置を提供する。ここに記載した例示的な環境では、ハードディスク60、リムーバブル磁気ディスク29およびリムーバブル光ディスク31が使用されているが、この例示的な動作環境では、磁気カセット、フラッシュメモリカード、ディジタルビデオディスク、ベルヌーイカートリッジ、ランダムアクセスメモリ、リードオンリーメモリ、ストレージエリアネットワークなど、コンピュータがアクセス可能なデータを記憶することができる他のタイプのコンピュータ可読媒体を使用することもできることを当業者は理解されたい。
【0010】
ハードディスク60、磁気ディスク29、光ディスク31、ROM24またはRAM25には、オペレーティングシステム35、1つまたは複数のアプリケーションプログラム36、他のプログラムモジュール37およびプログラムデータ38を含む、いくつかのプログラムモジュールを記憶することができる。ユーザは、キーボード40、ポインティングデバイス42などの入力装置を介して、コマンドおよび情報をパーソナルコンピュータ20に入力することができる。この他の入力装置(図示せず)には例えば、マイクロホン、ジョイスティック、ゲームパッド、衛星アンテナ、スキャナなどがある。これらの入力装置および他の入力装置はたいてい、システムバスに結合されたシリアルポートインタフェース46を介して処理ユニット21に接続されるが、パラレルポート、ゲームポート、ユニバーサルシリアルバス(USB)、ネットワークインタフェースカードなどの他のインタフェースによって接続することもできる。さらに、モニタ47または他のタイプのディスプレイ装置が、ビデオアダプタ48などのインタフェースを介してシステムバス23に接続されている。モニタの他に、パーソナルコンピュータは一般に、スピーカ、プリンタなどの周辺出力装置(図示せず)を含む。
【0011】
パーソナルコンピュータ20は、リモートコンピュータ49などの1台または数台のリモートコンピュータへの論理接続を使用したネットワーク化された環境で動作することができる。リモートコンピュータ49は、別のパーソナルコンピュータ、サーバ、ルータ、ネットワークPC、ピア装置または他の普通のネットワークノードとすることができる。図1にはメモリ記憶装置50だけしか示されていないが、リモートコンピュータ49は一般に、パーソナルコンピュータ20に関して先に説明した全ての要素または多くの要素を含む。図1に示した論理接続は、ローカルエリアネットワーク(LAN)51およびワイドエリアネットワーク(WAN)52を含む。このようなネットワーキング環境は、事業所、企業内コンピュータネットワーク、イントラネットおよびインターネットでごく普通に見られるものである。
【0012】
LANネットワーキング環境で使用するとき、パーソナルコンピュータ20は、ネットワークインタフェースまたはアダプタ53を介してローカルネットワーク51に接続される。WANネットワーキング環境で使用するとき、パーソナルコンピュータ20は一般にモデム54、またはWAN52を介した通信を確立するためのその他の手段を含む。モデム54は、内部モデムでもまたは外部モデムでもよく、シリアルポートインタフェース46を介してシステムバス23に接続される。ネットワーク化された環境では、パーソナルコンピュータ20に関して図示したプログラムモジュール、またはその一部分を、遠隔メモリ記憶装置に記憶することができる。示されたネットワーク接続は例示的なものであり、コンピュータ間に通信リンクを確立する他の手段を使用することができることを理解されたい。
【0013】
特に指示しない限り以下の説明では、1台または数台のコンピュータによって実行されるアクト(act)およびオペレーションの記号的表現を参照して、本発明を説明する。時にコンピュータ実行アクトまたはオペレーションと呼ばれるこのようなアクトおよびオペレーションは、コンピュータの処理ユニットによる、構造化された形態のデータを表す電気信号の操作を含むことを理解されたい。この操作では、データを変換し、またはコンピュータのメモリシステム中の位置にデータを維持する。これによって、コンピュータのオペレーションは当業者によってよく理解されている方法で再構成され、または別な方法で変更される。データが維持されるデータ構造は、データのフォーマットによって定義された特定の特性を有するメモリの物理的位置である。しかし、本発明は以上の文脈で説明されるが、これは限定を意味しない。当業者なら分かるとおり、以降に説明するさまざまなアクトおよびオペレーションはハードウェアとして実装することもできるからである。
【0014】
次に図2を参照する。本発明は、セキュリティ機構、特にケルベロス認証プロトコルを実装したセキュリティ機構を、セッションイニシエーションプロトコル(SIP)に基づくリクエストメッセージに組み込んで、SIPクライアント72とSIPプロキシサーバ74が相互に認証することができるようにし、かつシグナリングメッセージの完全性を保護するための方法を対象とする。SIPは、RFC(Request for Comments)2543に定義されている。この文書は、その全体が参照によって本明細書に組み込まれる。
【0015】
例えば、一般的なセッション開始オペレーションでは図2に示すように、別のユーザ80(例えば「ボブ(Bob)」)と話しをしたいSIPクライアント72(「呼出し元」)のユーザ76(例えば「アン(Ann)」)は、ボブがINVITEメッセージ82の意図された受信者であることを確認するINVITEメッセージを送る。このINVITEメッセージは、呼出し元SIPクライアントのドメインに対応するアウトバウンドプロキシサーバ74に送られる。図2に示すようにINVITEメッセージは、このシグナリングオペレーションに関与する複数のSIPプロキシを介して送られ、その後、ボブのコンピュータ88のSIPクライアント86(呼出し先)に到達する。好ましい実施形態では、シグナリング経路上のSIPプロキシ間で転送中のSIPシグナリングメッセージのセキュリティが、IPsecプロトコルの下で、またはSSL(SecuredSockets Layer)プロトコルの下でパイプを通してメッセージを送ることによって保護される。この例ではSIPリクエストがINVITEリクエストだが、以下で説明する認証方式は、REGISTER、MESSAGE、SUBSCRIBE、SERVICEなどの他のタイプのSIPリクエストに対しても使用することができることを理解されたい。
【0016】
シグナリングオペレーションのセキュリティおよびシグナリングメッセージの完全性を確保するため、アウトバウンドSIPプロキシサーバ74は、シグナリング経路90を介してINVITEメッセージ82を転送する前に、呼出し元SIPクライアント72のユーザ76の認証を求めることができる。次に図3を参照する。本発明によればプロキシサーバ74はINVITEメッセージに応答して、SIPクライアント72にチャレンジメッセージ96を送る。チャレンジメッセージ96は、まず最初にクライアント72がそのユーザをプロキシ74に対して認証しなければならないことを指示する、SIP仕様に定義されたステータスコード「407 Proxy Authentication Required(407プロキシ認証が必要)」を含む。SIP仕様によれば、チャレンジメッセージ96(以後「407メッセージ」と呼ぶ)は、認証のためにクライアントが使用しなければならないセキュリティ機構を指示するデータを含む「Proxy−Authenticate」ヘッダフィールド98を含む。Proxy−Authenticateヘッダの構文および内容ヘッダについては後に詳細に説明する。好ましい実施形態では、ケルベロスが好ましいセキュリティ機構だが、SIPフレームワークでは、NTLMプロトコルに基づくセキュリティ機構の使用も可能である。以下の説明では、特に指示しない限り、ケルベロスプロトコルに基づくセキュリティ機構を使用するものとする。
【0017】
さらに図3を参照する。INVITEメッセージ82に応答したプロキシサーバ74から407メッセージ96を受け取ると、Proxy−Authenticateヘッダ98からSIPクライアント72は、ケルベロス機構を使用したユーザの認証をプロキシサーバが求めていると判断する。サーバチケットをまだ取得していない場合、クライアント72は次いで、SIPプロキシサーバ74のケルベロス・キー・ディストリビューション(配布)・センター(KDC:Key Distribution Center)100からサーバチケット108を取得する。一実施態様では、KDC100が、プロキシサーバ74のドメインコントローラ102の一部である。サーバチケット108を取得した後、クライアント72は別のINVITEメッセージ110を送る。ただしこのときには、INVITEメッセージ110が、SIP仕様に基づくProxy−Authorization(プロキシ許可)ヘッダフィールド112を含んでいる。Proxy−Authorizationヘッダフィールド112は、プロキシサーバにアクセスするためのサーバチケット108を含む。サーバチケット108は、使用するセッションキー116を含んでいる。Proxy−Authorizationヘッダフィールドの構文および内容については後に詳細に説明する。任意選択で、Proxy−Authorizationヘッダにさらに、クライアント72に対して自体を認証するようプロキシサーバ74に求める、相互認証のためのリクエストを含めることもできる。
【0018】
SIPプロキシサーバ74は、ケルベロスサーバチケットが埋め込まれた再送INVITEメッセージ110を受け取ると、サーバチケットを抜き出し、チケットの有効性を、KDC100と共有しているその長期キーでチケットを解読することによって検証する。チケットが有効である場合、ユーザ76は認証され、SIPプロキシサーバ74は、シグナリング経路上の次のプロキシ120にINVITEメッセージ110を転送する。クライアント72が、INVITEメッセージ110のProxy−Authorizationヘッダ112の中で相互認証を要求してきた場合、プロキシサーバ74は、ケルベロスサーバチケットに関連付けられたセッションキーを使用して、自体からクライアントへの将来のパケットに署名する。このメッセージは、クライアント72がプロキシ74を認証することを可能にするプロキシ74の証明書(credential)を含むProxy−Authentication Informationヘッダ124を含む。
【0019】
最終的に、INVITEメッセージ110は呼出し先、すなわちボブのコンピュータ88のSIPクライアント86に届く。この呼勧誘を受け入れる場合、呼出し先は「200 OK」メッセージ126を返し、このメッセージは呼出し元へ送られる。呼接続が確立されると、呼出し元は、このシグナリング段階に関与したSIPプロキシを通すことなく、呼出し先と直接に通信することができる。
【0020】
次に図4を参照する。本発明によれば、SIPクライアント72とSIPプロキシサーバ74の間で認証セキュリティアソシエーション(SA:security association)を確立するオペレーションは、状態機械128として見ることができる。図4に示す実施形態では、好ましいセキュリティ機構がケルベロスであるが、任意選択でNTLMセキュリティ機構も使用することができ、この状態機械図は、この任意選択の包含を反映したものになっている。
【0021】
図4では、状態が円の中に、状態に関連して実行されるオペレーションが長方形のブロックの中に示されている。図4に示すように、状態機械の1つの状態が、セキュリティSAが確立されていない「SECURITY_STATE_NONE」状態132である。クライアント72が送ったINVITEメッセージに応答したプロキシ74から407チャレンジメッセージを受け取り、またはプロキシとプレ認証(pre−authentication)を実行すると決定すると、クライアント72は「SECURITY_STATE_ACQUIRING_SA」状態136に入り、認証に必要なセキュリティアソシエーションデータを獲得する。認証に必要なセキュリティアソシエーションデータは、選択したセキュリティ機構によって異なる。
【0022】
セキュリティアソシエーションは一般に、クライアントとSIPプロキシが共有の秘密を安全な方法で交換し、この秘密を使用して認証し、クライアントとプロキシによって交換される以降のメッセージの完全性を保護することができる状態と定義される。セキュリティ機構がケルベロスである場合、セキュリティアソシエーションは、プロキシに対するケルベロスサーバチケットおよびセッションキーを含む。ケルベロスの場合、取得されたSAは完全である。すなわち、これを使用して、SIPクライアントのユーザをプロキシが十分に認証することができる。クライアントは次いで、このSA関連情報(例えばサーバの秘密を用いて暗号化されたケルベロスセッションキー)をプロキシに送る(段階138)。プロキシが、署名された200OKメッセージを返した場合(段階140)、認証は成功であり、セキュリティアソシエーションは確立されている。すなわちクライアントはSA_Established状態142にある。しかし、プロキシが代わりに407チャレンジメッセージを返した場合(段階146)、クライアントは、プロキシが不良な状態にあり、そのためクライアントの正当な証明書を検証することができないでいるとみなす。次いでクライアントは「バックオフ」時間(例えば5分)のあいだ待機し(段階148)、その後再びSIPメッセージを送る。
【0023】
SA_Established状態142に入った後は、セキュリティアソシエーションが期限切れにならない限り、クライアントは再び認証を実行することなくプロキシに別のメッセージを送ることができる。しかしプロキシが407チャレンジメッセージを送った場合(段階150)、クライアントは、確立されたセキュリティアソシエーションをプロキシが何かの理由で取り下げたとみなす。その結果、クライアントは、SA_Dropped状態156に入り、SECURITY_STATE_ACQUIRING_SA状態136へ移って、プロキシとの認証を再び実施するための新しいSAを獲得する。
【0024】
先に述べたとおり、ユーザの認証に対して任意選択でNTLM機構を選択することができる。NTLMの状態移行はケルベロスの状態移行と概ね同じだが、NTLMは、始めに不完全なSAだけを獲得し(段階158)、不完全なSAを第1のメッセージに入れてプロキシに送るという違いがある。具体的には、NTLMの場合、SA関連情報を含むクライアントからの第1のリクエストは、クライアントのセキュリティ関連機能(例えばクライアントがサポートするプロトコルのバージョン、サポートする署名アルゴリズムなど)を伝える。これに応答してプロキシサーバは、そのNTLM関連機能および一般に「nonce」と呼ばれるランダムなバイト列を含む自体の認証データを含んだ第2の407チャレンジを送る(段階160)。これに応答してクライアントは、それ自体の名称およびプロキシによって送られた「nonce」値のハッシュにその証明書を使用して署名する。これは、NTLMインプリメンテーションによって内部的に処理される。プロキシサーバは、クライアントの認証データを検証し、ドメインコントローラの助けを借りてセッションキーを得る。SIPプロキシが意図された受信者でない場合、プロキシは、シグナリング経路上の次のホップにSIPリクエストを転送し、送信側SIPクライアントへの次のメッセージ(例えば受信者からの200OKメッセージ)に署名する(段階140)。
【0025】
SIPクライアントとSIPプロキシの間の認証目的のメッセージ交換に関与するさまざまなSIPヘッダの構文については後に説明する。
【0026】
(407応答)
先に述べたとおり、INVITEメッセージを送ったSIPクライアント(またはそのユーザ)の識別を要求したい場合、SIPプロキシサーバ74は、Proxy−Authenticateヘッダを含む407メッセージをクライアントに送る。認証のためにケルベロスセキュリティ機構の使用を必要とする好ましい実施形態のProxy−Authenticateヘッダの構文は以下のとおりである。
【0027】
【0028】
ここに記載したProxy−Authenticateヘッダの構文は、「HTTP Authentication:Basic and Digest Access Authenticaton」という表題のIETF RFC 2617に定義されている「WWW−Authenticate Response Header」と同様である。この文書はその全体が参照によって本明細書に組み込まれる。任意選択のパラメータ「algorithm」および「stale」は省かれている。ヘッダの「scheme」フィールドは、サーバに対して自体を認証するのに、サーバによって提案された認証機構のうちどの認証機構を使用したいかをクライアントが選択することを可能にする。クライアントがケルベロス機構をサポートしている場合には、クライアントはケルベロス機構を選択することが好ましく、サポートしていない場合にはNTLM認証機構を選択する。
【0029】
realmパラメータは、SIPプロキシが属し、クライアントがアクセスしようとしているSIPサービスプロバイダの固有の識別子である。認証のためにユーザが提供する必要がある正しい証明書セットをユーザが識別するのを助けるため、realm列はユーザに表示される。「targetname」パラメータは常に必要なパラメータであり、SIPプロキシのFQDNを伝達するのに使用される。このパラメータの実際の内容は、クライアントがSAを確立しているプロキシを追跡するのを助ける。それは、応答が自体に対するものなのか、または他のプロキシに対するものなのかをプロキシが判定するのを助ける。「opaque」パラメータは、サーバが、確立されている特定のSAに索引をつけるのに使用され、後に説明するように、クライアントがSAに対して生成する将来のProxy−Authorizationヘッダ中に反映されなければならない。
【0030】
この実施形態では、IETF RFC2078(その全体が参照によって本明細書に組み込まれる)に定義されたGSS−API(Generic Security Service Application ProgrammingInterface)が実装されており、通信しているアプリケーション間でメッセージを安全に交換するのに使用されるとみなす。GSS−APIは特に、通信アプリケーションが、別のアプリケーションに関連付けられたユーザを認証することを可能にする。Proxy−Authenticateヘッダおよび後述するProxy−Authorizationヘッダのgssapi−dataフィールドは、NTLMおよびケルベロスセキュリティパッケージを実装したセキュリティAPIによって、SAネゴシエーション段階の間に返されたデータを保持するためのものである。これらのAPIは、クライアントからプロキシへ、およびプロキシからクライアントへ送る必要があるgssapiデータを返す。gssapiデータは、SIPクライアント/プロキシインプリメンテーションにとって不透明であり、セキュリティAPIだけが解釈することができる。qopパラメータは、クライアントが従って欲しいとサーバが欲しているセキュリティのレベルをクライアントに教える。qopパラメータ値は常に、この機構によって提供されるセキュリティレベルがユーザの認証であることを指示する「auth」にセットされている。
【0031】
Proxy−Authenticateヘッダフィールドの一例を以下に示す。
【0032】
Proxy-Authenticate: Negotiate
realm = "Microsoft RTC Service provider",
opaque = "ABCDEF456789"
qop = "auth",
gssapi-data = "ABCD345678yuikjhlbcdfsaqwety"
【0033】
許可されたクライアントだけを許すとされ、クライアントから着信するSIPパケットが署名を含まない場合には一般に、SIPプロキシは、SIPクライアントの識別を要求するであろう。(リブートなどのため)SIPプロキシがこのSIP URIに対するセキュリティアソシエーションを失った場合にも、SIPプロキシはクライアントの認証を要求するであろう。クライアントが使用している許可パラメータとSIPプロキシが期待しているものの間にミスマッチがある場合、SIPプロキシは、クライアントが従って欲しいとSIPプロキシが欲している正確な許可パラメータを運んでいる407メッセージを使用して、クライアントの認証を要求するであろう。
【0034】
(407チャレンジに対するクライアントの応答)
407チャレンジに応答してSIPクライアントは、407チャレンジメッセージを介してSIPプロキシから送られた認証パラメータに従った署名を生成しようとする。SIPクライアントはCseq値を増分し、チャレンジの対象となった最初のSIPリクエストを、Proxy−Authorizationリクエストヘッダの中に入れられた許可情報とともに再送する。好ましい実施形態におけるProxy−Authorizationリクエストヘッダの構文は以下のとおりである。
【0035】
【0036】
ここに記載したProxy−Authorizationヘッダの構文は、IETF RFC 2617に定義されている「Authorization Request Header」と同様である。ただし、任意選択のパラメータ「algorithm」および「URI」は省かれている。Proxy−Authorizationヘッダは、リクエストURIおよびViaヘッダの後に追加される。署名は、セッションキーを使用して、以下のフィールドにわたって計算される。
【0037】
−FromヘッダURI
−ToヘッダURI
−Fromヘッダタグ
−Toヘッダタグ
−Proxy−Authorizationヘッダ中の「crand」パラメータ、またはProxy−Authentication−Infoヘッダ中の「srand」パラメータ
−SIPメッセージExpiresヘッダ中のExpires値
署名には、SIPメッセージのメッセージ本体は含まれていない。proxy−authorizationヘッダは、gasapi−dataパラメータまたはresponse(署名)パラメータを含む。
【0038】
以下に、407チャレンジに対するクライアントの応答におけるProxy−Authorizationヘッダの例を示す。
【0039】
Proxy-Authorization: Negotiate
realm = "Microsoft RTC Service Provider",
response = "ABCD87654cvx,
opaque = "ABCD1234",
crand = "1234"
qop = "auth"
targetname = "serverl.domainA.mjcrosoft.com"
または
Proxy-Authorization: Negotiate
realm = "Microsoft RTC Service Provider",
opaque= "ABCD1234",
gssapi-data = "ABCDEFl23456",
qop = "auth",
targetname = "serverl.domainA.microsoft.com"
【0040】
プロキシからの407チャレンジに応答するときの他に、クライアントは、自体を初めてSIPプロキシに登録するときにもこのヘッダを送る。SIPクライアントが自体をプロキシサーバに登録し、セッションのためにセキュリティアソシエーションを初期化するプロセスにあるとき、Proxy−Authorizationヘッダは、「gssapi−data」パラメータを含む。
【0041】
(相互認証)
ある種のシナリオでは、SIPプロキシとSIPクライアントの間で相互認証を確立することが必要である。クライアントは、特定のプロキシサーバに対してクライアントが有する準備プロファイルから、相互認証が必要か否かを判断する。相互認証が使用可能な場合、クライアントは、GSS APIの標準バージョンを使用して相互認証のためのセキュリティアソシエーションを初期化する。相互認証が使用可能な場合にはさらに、サーバが、SIPクライアントに送る全てのパケットに署名する必要がある。この署名は、Proxy−Authentication−Informationリクエストヘッダに入れて運ばれる。Proxy−Authenticate−Informationの構文は以下のとおりである。
【0042】
ProxyAuthenticationInfo = "Proxy-Authentication-Info" ":" auth-info
auth-info = 1# (message-qop | response-auth | srand)
response-auth = "rspauth" "=" response-digest
response-digest = <"> *LHEX <">
srand = "srand" "=" srand-value
srand-value = quoted-string
【0043】
Proxy−Authentication−Infoヘッダ中の「rspauth」パラメータは、この応答に対する(認証を求めているプロキシの)署名を運ぶ。「srand」パラメータは、SA確立段階後にサーバが、クライアントに送るメッセージに署名するのに使用される。このパラメータは、サーバによって生成されるランダムな文字列であり、生成されたメッセージのハッシュ/署名にランダム性の要素を導入するのに使用される。
【0044】
以下に、Proxy−Authentication−Informationヘッダの一例を示す。
【0045】
Proxy-Authentication-Info: Negotiate
realm = "Microsoft RTC Service Provider",
qop = "auth",
rspauth = "ABCD87564cvx",
srand = "9876543210",
targetuame = "serverl.domainA.microsoft.com"
【0046】
SIPフレームワークでは一般に、REGISTERリクエストを使用した登録プロセスの間に、SIPクライアントが、SIPプロキシとのセキュリティアソシエーションを確立することができる。登録によってSIPクライアントは、SIPプロキシからメッセージを受け取ることができるようになる。SIPクライアントが自体をSIPプロキシに登録するときには、SIPクライアントは同時に、ケルベロスチケットなどの認証データをREGISTERメッセージに入れて送ることによって、自体のユーザをSIPプロキシサーバに対して認証することができる。SIPクライアントがSIPプロキシにすでに登録されており、かつSIPプロキシに対して認証されている場合、INVITEなどのSIPリクエストをクライアントが送るときには、クライアントからのリクエストメッセージが、SA確立プロセスの間に交換されたケルベロスセッションキーを使用して署名される。
【0047】
とは言え、自体をサーバに登録しなくても、SIPクライアントはリクエストメッセージをSIPプロキシに送ることができる。呼出し元がプロキシに対して認証されていない場合には(たとえSIPクライアントがプロキシに登録されている場合であっても)、SIPプロキシはそのリクエストを次のホップに転送しない。その代わりにプロキシは、SIPクライアントにチャレンジを送る。
【0048】
このチャレンジは、クライアントがこのSIPサーバと、セキュリティアソシエーションを確立する必要があることを指示する。クライアントは、セキュリティアソシエーションデータを含むリクエストを再び送ることによってSAを確立することができ、あるいは、登録はすでにされているが、SAがまだ確立されていない場合には、このサーバへの自体の登録をリフレッシュすることによってSAを確立することができる。登録リフレッシュを使用してSAを確立し、次いで有効な署名を有するSIPリクエストを送ることには、登録が良好な状態にあることが保証されるという利点がある。
【0049】
さらに、SIPクライアントがSIPプロキシに対する登録を抹消するたびに、SIPクライアントとSIPプロキシの間のセキュリティアソシエーション(SA)は失われ、新しいセキュリティアソシエーションを再び交渉し直さなければならない。さらに、SIPクライアントの登録が失効すると、プロキシサーバは、対応するセキュリティコンテキストをSAのリストから削除する。登録をリフレッシュするたびに、SIPクライアントは、認証セキュリティアソシエーションもリフレッシュしなければならない。
【0050】
ケルベロスプロトコルに基づくセキュリティ機構を使用する好ましい実施形態では、送信側SIPクライアントのユーザの認証がSIPプロキシ/レジストラによって要求された場合に、SIPクライアントがSIPプロキシに登録するたびに、ケルベロスキーディストリビューションセンター(KDC)からのケルベロスチケットが要求される。ケルベロスチケットを受け取ると、SIPクライアントはこのチケットを解読する。解読されたチケットは、セッションキーおよびこのケルベロスセッションの他のいくつかの特性を含む。このチケットはさらに、サーバの証明書で暗号化されたセッションキーおよび他のセッション関連パラメータを含む。この部分は、gssapi−dataフィールドの、pOutputパラメータに入れて返され、re−INVITEリクエストに入れてプロキシに送られる。
【0051】
SIPフレームワーク内でのセキュリティ機構のオペレーションの明瞭な理解を容易にするため、クライアント・プロキシのケルベロス認証の具体的な例を図2を参照して説明する。この例では、SIPプロキシサーバ74が、ドメイン「domainA.Microsoft.com:S_server1」のKDC170との共有秘密鍵をすでに生成していると仮定する。この例では「server1」が、SIPプロキシ/レジストラのコード名として使用される。KDC170は、プロキシサーバ74がserver_ID=server1.domainB.microsoft.comであると知っている。プロキシサーバ74はさらに、証明書ハンドルを獲得して、クライアントから来る認証リクエストに応答する準備を整える。サーバ証明書は、サーバ認証または相互認証をサポートしているセキュリティプロトコルにおいてSIPクライアント74に対してプロキシサーバ74を認証するのに使用される。プロキシサーバ74は、このサーバを起動するのに使用されるサービスアカウントによって定義されるその証明書に対するハンドルを取得する。サーバはこのハンドルを、SSPI(Security Support Provider Interface)の関数AcquireCredentialsHandleを呼び出すことによって取得する。
【0052】
図2の例では、SIPクライアント72のユーザ76がアンである。アンは、NTドメインにアカウントを有し、一日の始まりに、以下の情報を使用して自分のアカウントにログオンする。
【0053】
UserID / principal name = ann@microsoft.com
Preferred_email = ann@microsoft.com
User_domain = domainA.Microsoft.com
Workstation = ann1.domainA.Microsoft.com
【0054】
ボブと通話したいとき、アンは、自分のワークステーション78上のSIPクライアント72を起動する(SIPクライアントはサービスとして自動的に起動することができる。ただしユーザのセキュリティコンテキストで走らなければならない)。SIPクライアント72は、DNSを使用してアウトバウンドプロキシサーバ74を見つける。この例で使用するアウトバウンドプロキシサーバ74は、Server1.domainB.Microsoft.comとして識別される。アンは、自分がbob@microsoft.comと通話したいことを指示する。アンのSIPクライアント72は次いで、Server1.domainB.Microsoft.comにINVITEメッセージ82を送る。INVITEメッセージは以下の情報を含む。
【0055】
INVITE bob@microsoft.com
From: ann@microsoft.com
To: bob@microsoft.com
【0056】
この例の説明を簡潔かつ明瞭に保つため、このINVITEメッセージまたはシグナリング処理で交換される他のメッセージに含まれる全てのデータを示すわけではない。SIPプロキシサーバ74は、Microsoft.comのユーザ名空間に対してなされた呼に対する全てのINVITEリクエストが認証されることを必要とするように構成されている。その結果、SIPプロキシサーバ74はINVITEリクエストに応答して、ケルベロスを使用してユーザ(アン)を認証するようSIPクライアント74に求める407メッセージ96を送る。407メッセージは以下のデータを含む。
【0057】
Proxy-Authenticate: Kerberos realm = domainB.microsoft.com
targetname = "serverl.domainA.Microsoft.com" opaque = "someopaquedata"
【0058】
opaque値は、この呼に対して使用するセキュリティコンテキストを識別するためにプロキシによって初期化される。そのために、プロキシサーバ74はこのとき、関数AcceptSecurityContextを呼び出し、pOutputをbase64でコード化した結果をopaqueに入れて返す。クライアントおよびサーバは、このopaque値を使用して、認証の継続、またはAuthorizationリクエストヘッダを使用した同じサーバへの以降のリクエストの再認証のため特定のサーバに対して使用するセキュリティコンテキストを識別する。
【0059】
アンのワークステーション上のSIPクライアント72は、認証が必要であることを指示する407メッセージ96を受け取ると、Server1.domainB.Microsoft.comと交信するための有効なセッションキーを持っているかどうかをチェックする。まだ所有していない場合には、このドメイン内のKDCと接触して、アウトバウンドSIPプロキシにアクセスするのためのセッションキーを取得する必要がある。この例では、407メッセージの中に指定されたrealmからクライアントは、自体のドメインとは異なるドメインにプロキシがあることを知る。
【0060】
プロキシサーバ74への安全な接続を確立するため、クライアント72は、認証リクエストをプロキシに送る前にアウトバウンド証明書ハンドルを獲得する。これは、関数SSPIを呼び出すことによって実行される。SSPIは、ネットワーク化されたアプリケーションが、いくつかあるうちの1つのセキュリティサポートプロバイダ(SSP)にコールして、認証済みの接続を確立し、確立された接続を介してデータを安全に交換する手段を提供する。認証セットアップに関与する2つのクライアント側SSPI関数がある。AcquireCredentialsHandle関数は、以前に取得したログオン証明書への参照を取得する。関数InitializeSecurityContextは、最初の認証リクエストセキュリティトークンを生成する。InitializeSecurityContextを呼び出すと、407メッセージから取得したopaque値がpInputに入れて渡される。クライアントは、この関数のtfContextReqパラメータをリクエストMUTUAL_AUTHにセットする。pfContextAttrポインタは、mutual−authが「リクエスト」されたことをケルベロスモジュール180がクライアントに知らせる方法である。この情報は、クライアントのケルベロスモジュール180によって生み出されるKERB_AS_REQの一部であり、クライアントが相互認証を求めていることをサーバ(ここではSIPプロキシ)に知らせるsecBuffer(pOutput)に入れて渡される。これはKERBリクエストの一部なので、SIP機構(ヘッダ/パラメータ)が相互認証を要求する必要はない。
【0061】
図2に示した例では、API関数InitializeSecurityContextを呼び出すことによって、以下のケルベロス論理が生じる。最初にクライアント72が、DomainB(ドメインB)のプロキシサーバ74へのサーバチケットをクライアント72に与えるよう、domainA.Microsoft.comドメインのKDC170に求める。domainA.Microsoft.comのKDC170はクライアント72に、corp.Microsoft.comのKDC172への照会チケットを送る。この照会チケットは、この2つのKDCによって共有されたドメイン間キーの中に暗号化されている。この照会チケットを使用して、クライアントは、DomainBにあるサーバへのサーバチケットをクライアントに与えるよう、corp.Microsoft.comのKDC172に求める。
【0062】
これに応答してKDC172は、DomainBのKDC176への照会チケットをクライアントに送る。このチケットは、KDC172がDomainBのKDC176と共有するドメイン間キーの中に暗号化されている。クライアントは次いで、DomainBにあるプロキシサーバ74へのチケットをクライアントに与えるよう、DomainBのKDC176に求める。KDC176は、プロキシサーバ74にアクセスするためのサーバチケット108をクライアントに送る。KDC176は、アンのログオンセッションキーを用いてこのセッションキーの1つのコピーを暗号化し、セッションキーの別のコピーをアンの許可データとともにサーバチケットに埋め込み、プロキシサーバの長期キーを用いてサーバチケットを暗号化する。KDC176は次いで、これらの証明書を、Kerberos Ticket−Granting Service Reply(KRB_TGS_REP)に入れてクライアント72に送る。
【0063】
このように、InitializeSecurityContextを呼び出すことによって、クライアントマシンのケルベロスモジュール180がKDCとのTGS交換を開始する。この交換によって返される値は、プロキシに送るメッセージに署名するためのセッションキーである。
【0064】
その後、SIPクライアント72は、SIPプロキシに送る新しいINVITEメッセージ110(「re−INVITE」メッセージとも呼ばれる)を生成する。この新しいINVITEメッセージ110は、クライアントがKDC176から受け取ったサーバチケットを含むGSS−APIデータをその中に含んだ、先に説明したproxy−authorizationヘッダを含む。セッションキーは、InitializeSecurityContext呼出しによって返されたpOutputバッファの中に入れて返された値である。したがって、新しいINVITEメッセージ110は以下のデータを含む。
【0065】
INVITE bob@microsoft.com
From: ann@microsoft com
To: bob@microsoft.com
Proxy-authorization: gss-scheme opaque gssapi -rdata
Opaque = someopaquedata
Gssapi-rdata = base64{pOutput} = session key to the proxy
【0066】
このINVITEメッセージは、プロキシサーバに対してKRB_AP_REQと等価の内容を実行する。
【0067】
メッセージの完全性を保護し、自体を認証する(すなわちメッセージの出処を証明する)ため、クライアントは、セッションキーを用いてINVITEメッセージ110に署名する。さもないと、第三者がこのINVITEメッセージをかぎつけ、OpaqueおよびGssapi−data値を手に入れ、偽のINVITEメッセージを同じサーバに送って、この第三者とそれが選択した任意の転送先との間で通話をおこなう可能性がある。このことは、サーバへのセッションキーが有効である間(デフォルトでは8時間)、クライアントの認証を「盗む」ことができることを意味する。INVITEメッセージに署名することで、第三者がOpaqueおよびGssapi−rdataを取り出すことを防ぐことはできないが、新しいINVITEメッセージを生成して好き勝手に通話することは防ぐことができる。この問題を回避するためには、サーバが、署名されたリクエストしか受け入れないように構成されていなければならない。
【0068】
クライアント72は、MakeSignature APIを使用し、これを呼び出して、(407メッセージのopaque中に識別された)この呼出しで使用されるセキュリティコンテキストにphContextをセットし、その内容を渡してpMessageに署名する。この呼出しの出力は、pMessageの中に返された署名されたメッセージである。クライアントは、この署名をINVITE110に追加する。再送されたINVITEメッセージ110を受け取ると、プロキシサーバ74は、Proxy−Authorizationヘッダの中のopaque値をチェックし、所与のphContext値(所与のセキュリティコンテキストへのハンドル)と相関させる。プロキシサーバ74は、gssapi−rdataを取り出し、AcceptSecurityContextAPI関数を呼び出し、proxy−authorizationヘッダから得たgssapi−rdata値をこのAPI関数のpInput成分の中に渡すことによって、これを自体のケルベロスモジュール182を渡す。ケルベロスモジュール182は、プロキシの長期キーを使用してサーバチケットを解読し、アンの許可データおよびセッションキーを抜き出す。ケルベロスモジュール182は、セッションキーを使用してアンのオーセンティケータ(authenticator)を解読し、次いで中のタイムスタンプを評価する。
【0069】
オーセンティケータがこのテストにパスした場合、ケルベロスモジュール182は、クライアントのリクエストの中の相互認証フラグを探す。フラグがセットされている場合、ケルベロスモジュール182はセッションキーを使用して、アンのオーセンティケータからの時刻を暗号化し、その結果を、KerberosApplication Reply(KRB_AP_REP)の中に返す。これによって、AcceptSecurityContextが呼び出され、SEC_E_OK戻り値が返され、オーセンティケータはpOutputバッファを使用してこのAPIを通過する。ユーザが認証されると、SIPプロキシ/レジストラはこのリクエストを処理し、INVITEメッセージを、SIPシグナリング経路上の次のホップに転送する。
【0070】
プロキシのSIPコンポーネントは次いで、SIPクライアントに転送する次のメッセージを使用してプロキシのオーセンティケータをクライアントに渡し、これによってクライアントがサーバを認証できるようにする。示された例では、このメッセージが「200OK」メッセージである。このメッセージは、SIPプロキシによって生成されたものではない。この200応答は、INVITEリクエストに応答して呼出し先が生成する。SIPプロキシは単に、呼出し元に転送する前にセッションキーを用いてこの応答に署名するだけである。
【0071】
先に説明したとおり、オーセンティケータは、Proxy−Authentication−Informationヘッダの中にある。このヘッダはさらに、クライアントが、この応答を正しいセキュリティコンテキストと一致させるためのopaque値を含む。
【0072】
アンのワークステーション上のSIPクライアント72は、「200OK」メッセージを受け取ると、Proxy−Authentication−Informationヘッダを抜き出し、InitializeSecurityContextを呼び出す。phContext値はopaqueの中の値にセットされ、pInputバッファはresponse−digestにセットされる。クライアント上のケルベロスモジュール180は、プロキシと共有するセッションキーを用いてプロキシのオーセンティケータを解読し、プロキシによって返された時刻を、クライアントのオリジナルのオーセンティケータの中の時刻と比較する。2つの時刻が一致した場合、このInitializeSecurityContextの呼出しはSEC_E_OKを返し、クライアントは、プロキシが本物であることを知る。一致しない場合にはクライアントはこの呼を取りやめなければならない。クライアントは、要求したことをサーバが実行すると信じることができないので、CANCELを送ってこの呼を強制終了せざるを得ない。
【0073】
上に説明した例では、認証が、まず最初にSIPクライアントが認証データを含まないINVITEを送り、次いで、認証が必要であることを指示するプロキシからの407メッセージに応答して認証データを別のINVITEに入れて送るシナリオで実施される。その代わりにクライアントは、プロキシに送る最初のINVITEに必要な認証データを含めることもできる。そのためにクライアント72は、SIPの下で通話するためにユーザが使用する前に、プロキシに対するサーバチケットをKDC176から取得する。次いで必要な認証データを、先に説明したProxy−Authorizationリクエストヘッダに入れる。こうすることによって、プロキシがクライアントに407チャレンジを送って認証データを要求する必要がなくなる。さらに、先に説明した認証オペレーションの例ではSIPプロキシが1つしか関与していないが、呼出し元と呼出し先の間のSIPシグナリング経路上には一般に複数のSIPプロキシがあり、2つ以上のSIPプロキシが、呼出し元クライアントの認証を要求する可能性がある。例えば、図5に示す単純化されたケースでは、SIPクライアントのアウトバウンドプロキシサーバ74の他に別のSIPプロキシサーバ120があり、両方のプロキシが、INVITEメッセージを転送する前にクライアントの認証を必要とする。この場合には、クライアント72がまず、図4に関して先に説明した同じプロセスを経て、アウトバウンドSIPサーバ74に対して自体を認証する。クライアントを認証した後、プロキシサーバ74は第2のプロキシ120にINVITEを送り、第2のプロキシ120は次いで、クライアントに407チャレンジ190を送る。これに応答してクライアントは、第2のプロキシサーバ120用のケルベロスサーバチケットを含んだProxy−Authorizationヘッダを有する別の新しいINVITE192を送る。クライアントを認証した後、第2のプロキシは呼出し先にINVITE192を渡す。
【0074】
以下の説明は、ケルベロスまたはNTLMセキュリティ機構に基づいて認証を実行するさまざまなメッセージフローのシナリオにおいて、Proxy Authenticate、Proxy AuthorizationおよびProxy−Authentication Informationヘッダをどのように使用するかを説明する追加の例を提供する。図6を参照する。このケースでは、SIPクライアント72が、体をプロキシサーバに登録するときにケルベロスベースのプレ認証を実行する。クライアントは、プロキシに対するケルベロスサーバチケットを含むProxy−Authorizationヘッダを含むREGISTERリクエスト200、および先に説明した相互認証のためのリクエストを送る。サーバチケットに基づいてクライアントを認証した後、プロキシは、クライアントが使用してプロキシを認証することができるプロキシ認証データを含むProxy−Authentication−Informationヘッダとともに、200OKメッセージ202を返す。REGISTERおよび200OKメッセージの内容の例を以下に示す。
【0075】
REGISTER sip: nickn@microsoft.com SIP/2.0
Via; SIP/2.0/UDP www.xxx.yyy.zzz:5060
From: "Nick North" <sip:nickn@microsoft.com>
To: "Mark Mars" <sip:markmmarkm@microsoft.com>
Call-ID: 123456789@microsoft.com
CSeq: 1 REGISTER
Contact: <sip:l23.45.67.89:5060>
Proxy-Authorization: Negotiate
realm = "Microsoft RTC Service Provider", qop = "auth", gssapidata = "34fcbaed78902QWERTY", targetname =
"serverl doaminA.microsoft.com"
User-Agent: Microsoft-RTC/l.0
Content-Length: 0
SIP/2.0 200 OK
Via: SIP/2.0/UDP www.xxx.yyy.zzz:5060
Proxy-Authentication-Info: Negotiate qop = auth, rspauth = "ABCD87564cvx",
srand = "9876543210" realm = "Microsoft RTC Service Provider" targetname
=
"serveral.doaminA.microsoft.com"
From: "Nick North" <sip:nickn@microsoft.com>
To: "Mark Mars" <sip:markm@microsoft.com>
Call-ID: l23456789@ms.com
CSeq: 1 REGISTER
Contact: "Nick north" <sip:@www.xxx.yyy.zzz>
User-Agent: Microsoft-RTC/1.0
Content-Length: 0
【0076】
図7に、ケルベロスベースのチャレンジド認証(challenged authentication)のシナリオを示す。この例では、クライアント72がまず、Proxy−Authorization情報を含まないINVITE206をプロキシ74に送る。プロキシはこれに応答して、認証が必要であることを指示するProxy−Authenticateヘッダを含む407メッセージ208を送る。この407メッセージに応答してクライアントは、必要なケルベロス認証データを含むProxy−Authorizationヘッダを有するREGISTERリクエスト210を送る。プロキシは、プロキシ自体についての認証情報を含むProxy Authentication Informationヘッダを有する「200OK」メッセージ212を返す。Proxy Authentication Informationヘッダの中のデータに基づいてプロキシを認証した後、クライアントは、Proxy−Authorizationヘッダを有する第2のINVITE214を送る。このプロセスの例示的なメッセージを以下に示す。
【0077】
SIP/2,0 407 Proxy Authorization Required
Via: SIP/2.0/UDP www.xxx.yyy.zzz:5060
From: "Nick North" <sip:nickn@microsoft.com>
To: "Mark Mars" <sip:markm@microsoft.com>
Call-ID: l2345600@PCl.ms.com
CSeq: 1 INVITE
Proxy-Authenticate: Negotiate realm = "Microsoft RTC Service Provider",
targetriame = "serverl.doaminA.microsoft.com", qop = "auth"
Contact: <sip:123.45.67.89:5060>
User-Agent: Microsoft-RTC/1.0
Content-Length: 0
REGISTER sip:nickn@microsoft.com SIP/2.0
Via: SIP/2.0/UDP www.xxx.yyy.zzz:5060
From: "Nick North"" <sip:nickn@microsoft.com>
To: "Mark Mars" <sip:markm@microsoft.com>
Call-ID: 123456789@microsoft.com>
CSeq: 1 REGISTER
Contact: <sip:123.45.67.89:5060>
Proxy-Authorization: Negotiate realm = "Microsoft RTC Service Provider",
opaque = "ABC01234", qop = "auth", gssapi-data = "34fcbaed78902QWERTY"
targetname = "serverl.domainA.microsoft.com"
User-Agent: Microsoft-RTC/1.0
Content-Length: 0
SIP/2.0 200 OK
Via: SIP/2.0/UDP www.xxx.yyy.zzz:5060
Proxy-Authentication-Info: Negotiate qop= "auth", rspauth =
"ABCD87564cvx", srand = "9876543210"
targetname = "serverl.doaminA.microsoft.com" realm = "Microsoft RTC Service
Provider",
From = "Nick North" <sip: nickn@microsoft.com>
To: "Mark Mars" <sip:markm@microsoft.com>
Call-ID: l23456789@ms.com
CSeq: 1 REGISTER
Contact: <sip:123.45.67.89:5060>
User-Agent: Microsoft-RTC/l.0
Content-Length: 0
【0078】
次に図8を参照する。先に述べたとおり、好ましい実施形態では任意選択で、クライアント・プロキシ認証にNTLMセキュリティ機構を使用することができる。この場合、クライアントがまず、認証データを含まないINVITEメッセージ220を送り、プロキシが407メッセージを返す。この407メッセージ222のProxy Authenticateヘッダは、認証に対してNTLMを使用しなければならないことを指示する。次いでクライアントが、NTLMプロトコルに基づくクライアントの認証データを含むProxy Authenticationヘッダを有するREGISTERメッセージ224を送る。
【0079】
図4の状態機械に関連して先に述べたとおり、クライアントによって送られた認証データによって、プロキシはクライアントを認証することができるが、この認証データに基づいてセキュリティアソシエーションは完全には確立されない。そのためプロキシは、Proxy Authenticateヘッダをやはり含む別の407チャレンジ226をクライアントに送る。クライアントは次いで、セキュリティアソシエーションを完成させるのに必要な認証データを含むProxy Authorizationヘッダを有する別のREGISTERリクエスト228を送る。プロキシサーバは、第2のREGISTERリクエストの中のデータに基づいてセキュリティアソシエーションを完成させ、プロキシについての認証データを含むProxy Authentication Informationヘッダを有する「200OK」メッセージ232を返す。「200OK」メッセージ232の中の認証データに基づいてクライアントはプロキシを認証し、次いで別のINVITEメッセージ236を送る。このプロセスの例示的なメッセージを以下に示す。
【0080】
SIP/2.0 407 Proxy Authorization Required
Via: SIP/2.0/UDP.www.xxx.yyy.zzz:5060
From: "Nick North" <sip:nickn@microsoft.com>
To: "Mark Mars" <sip:markm@microsoft.com>
Call-ID: 12345600@PCl.ms.com
CSeq: 1 INVITE
Proxy-Authenticate: NTLM rea1m = "Microsoft RTC service Provider",
targetname = "serverl.domainA.microsoft.com",
opaque = "ABCD1234", qop = "auth",
Contact: <sip:123.45.67.89:5060>
User-Agent: Microsoft-RTC/l.0
Content-Length: 0
REGISTER sip:nickn@microsoft.com SIP/2.0
Via: SIP/2.0/UDP www.xxx.yyy.zzz:5060
From: "Nick North" <sip:nickn@microsoft.com>
To: "Mark Mars" <sip:markm@microsoft.com>
Call-ID: 123456789@microsoft.com
CSeq : 1 REGISTER
Contact: <sip:123.45.67.89:5060>
Proxy-Authorization: NTLM realm = "Microsoft RTC Service Provider",
opaque = "ABCD1234", qop = "auth", gssapi-data = "34fcbaed78902QWERTY"
targetname = "serverl.domainA.microsoft.com"
User-Agent: Microsoft-RTC/1.0
Content-Length: 0
SIP/2.0 407 Proxy Authorization Required
Via: SIP/2.0/UDP www.xxx.yyy.zzz:5060
From: "Nick North" <sip:nickn@microsoft.com>
To: "Mark Mars" <sip:markm@microsoft.com>
Call-ID: 12345600@PCl.ms.com
CSeq: 1 INVITE
Proxy-Authenticate: NTLM realm = "Microsoft RTC Service Provider",
targetname = "serverl.domainA,microsoft.com", opaque="ABCDl234", qop = "auth",
gssapi-data = "QWERTY789564NMJHKLasdcfg"
Contact: <sip:123.45.67.89:5060>
User-Agent: Microsoft-RTC/1.0
Content-Length: 0
REGISTER sip:nickn@microsoft.com SIP/2.0
Via: SIP/2.0/UDP www.xxx.yyy.zzz:5060
From: "Nick North" <sip:nickn@microsoft.com>
To: "Mark Mars" <sip:markm@microsoft.com>
Call-ID: 123456789@microsoft.com
CSeq: 2 REGISTER
Contact: <sip:123.45.67.89:5060>
Proxy-Authorization: NTLM realm = "Microsoft RTC Service Provider",
gssapi-data = "qqertyuioKMNF009876" opaque = "ABCD1234", qop = "auth",
targetname = "serverl.domainA.microsoft.com"
User-Agent: Microsoft-RTC/l.0
Content-Length: 0
SIP/2.0 200 OK
Via: SIP/2.0/UDP www.xxx.yyy.zzz:5060
Proxy-Authentication-Info: NTLM realm = "Microsoft RTC Service Provider" qop = "auth",
rspauth = "ABCD87564cvx", srand = "9876543210"
targetname = "serverl.domainA.microsoft.com"
From: "Nick North" <sip:nickn@microsoft.com>
To: "Mark Mars" <sip:markm@microsoft.com>
Call-ID: 123456789@ms.com
CSeq: 2 REGISTER
Contact: <sip:123.45.67.89:5060>
User-Agent: Microsoft-RTC/1.0
Content-Length: 0
INVITE sip: markm@proxyl.wcom.com SIP/2.0
Via: SIP/2.0/UDP www.xxx.yyy.zzz:5060
Proxy-.Authorization: NTLM realm = "Microsoft RTC Service Provider",
crand = "913082051",
response = 12345ABCDEF78909BCADE56", opaque = "ABCD1234", qop =
"auth", targetmane = "serverl.domainA.microsoft.com"
From: "Nick North" <sip:nickn@microsoft.com>
To: "Mark Mars" <sip:markm@microsoft.com>
Call-ID: 12345601@PC1.ms.com
CSeq: 2 INVITE
Contact: "Nick North" <sip:nickn@microsoft.com>
User-Agent: Microsoft-RTC/1.0
Content-Type: application/sdp
Content-Length: xxx
【0081】
図9に、NTLMベースのプレ認証のシナリオを示す。このケースのメッセージフローは、ケルベロスベースのプレ認証のそれに似ているが、407チャレンジおよびREGISTERメッセージが追加されている点が異なる。具体的にはクライアントが、NTLMを使用することを指示し、NTLM認証データを含むProxy Authorizationヘッダを含むREGISTERメッセージ240および相互認証のためのリクエストを送る。プロキシは、受け取ったNTLM認証データに基づいてクライアントを認証し、Proxy Authenticateヘッダを有する407チャレンジ242を返す。クライアントは次いで、プロキシとのセキュリティアソシエーションを完成するためのNTLM認証データを含むProxy Authorizationヘッダを有する第2のREGISTERリクエスト244を送る。プロキシは次いで、Proxy Authentication Informationを有する「200OK」メッセージ246を返す。プロキシを認証した後、クライアントはプロキシに第2のINVITEメッセージ248を送る。このプロセスの例示的なメッセージを以下に示す。
【0082】
REGISTER sip:nickn@microsoft.com SIP/2.0
Via: SIP/2.O/UDP www.xxx.yyy.zzz:5060
From: "Nick North" <sip:nickn@microsoft.com>
To: "Mark Mars" <sip:markm@microsoft.com>
Call-ID: 123456789@microsoft.com
CSeq: 1 REGISTER
Contact: <sip:l23.45.67.89:5060>
Proxy-Authorization: NTLM realm = "Microsoft RTC Service Provider",
opaque = "ABCD1234", qop = "auth", gssapi-data = "34fcbaed78902QWERTY",
targetname = "serverl.dornainA.microsoft.com"
User-Agent: Microsoft-RTC/1.0
Content-Length: 0
SIP/2.0 407 Proxy Authorization Required
Via: SIP/2.0/UDP www.xxx.yyy.zzz:5060
From: "Nick North" <sip:nickn@microsoft.com>
To: "Mark Mars" <sip:markm@microsoft.com>
Call-ID: l2345600@PC1.ms.com
CSeq: 1 INVITE
Proxy-Authenticate: NTLM realrm = "Microsoft RTC Service Provider",
targetname = "serverl.domainA.microsoft.com", opaque = "ABCD1234",
qop = "auth",
gssapi-data = "QWERTY789564NMJHKLasdcfg",
targetname= "serverl.domainA.microsoft.com"
Contact: <sip:123.45.67.89:5060>
User-Agent: Microsoft-RTC/1.0
Content-Length: 0
REGISTER sip:nickn@microsoft.com SIP/2.0
Via: SIP/2.0/UDP www.xxx.yyy.zzz:5060
From: "Nick North" <sip:nickn@microsoft.com>
To: "Mark Mars" <sip:markm@microsoft.com.>
Call-ID: 123456789@microsoft.com
CSeq: 2 REGISTER
Contact: <sip:123.45.67.89:5060> Proxy-Authorization: NTLM realm = "Microsoft RTC Service Provider",
gssapi-data = "qqertyuioKMNFO09876" opaque = "ABCD1234", qop = "auth",
targetname = "serverl.domainA.microsoft.com"
User-Agent: Microsoft-RTC/1.0
Content-Length: 0
SIP/2.0 200 OK
Via: SIP/2.0/UDP www.xxx.yyy.zzz:5060
Proxy-Authentication-Info: NTLM qop = "auth",
rspauth = "AECD87564cvx", srand = "9876543210",
targetname = "serverl.domainA.microsoft.com"
From: "Nick North" <sip:nickn@microsoft.com>
To: "Mark Mars" <sip:markm@microsoft.com>
Call-ID: l23456789@ms.com
CSeq: 2 REGISTER
Contact: <sip:l23.45.67.89:5060>
User-Agent: Microsoft-RTC/1.0
Content-Length: 0
INVITE sip: markm@proxy1.wcom.com SIP/2.0
Via: SIP/2.0/UDP www.xxx.yyy.zzz:5060
Proxy-Authorization: NTLM realm = "Microsoft RTC Service Provider",
crand = "913082051",
response = "12345ABCDEF78909BCADE56", opaque = "ABCD1234", qop "auth" ta
rgetname = "serverl.domainA.microsoft.com"
From: "Nick North" <sip:nickn@microsoft.com>
To: "Mark Mars" <sip:markm@microsoft.com>
Call-ID: l234560l@PCl.ms.com
CSeq: 2 INVITE
Contact: "Nick North" <sip:nickn@microsoft.com>
User-Agent: Microsoft-RTC/l.0
Content-Type: application/sdp
Content-Length: xxx
【0083】
本発明の原理を適用することができる多くの可能な実施形態があることを考慮すれば、図面に関して本明細書に記載した実施形態は例示的なものであって、本発明の範囲を限定するものと解釈してはならないことが認識される。例えば、ソフトウェア(またはハードウェア)として示した記載の実施形態の要素をハードウェア(またはソフトウェア)として実装することができること、または本発明の趣旨から逸脱することなく記載の実施形態の配置および詳細を修正することができることを当業者は認識しよう。したがって本明細書に記載した発明は、前記請求項およびその等価物の範囲に含まれる全ての実施形態を企図する。
【0084】
【発明の効果】
ケルベロスプロトコル、NTLMプロトコルなどのセキュリティ機構を、SIPシグナリングオペレーションのメッセージフローに組み込んで、SIPクライアントとSIPプロキシが相互に認証できるようにするための方式が提供される。
【図面の簡単な説明】
【図1】本発明を実現することができる例示的なコンピュータシステムを概略的に示すブロック図である。
【図2】セッションシグナリング段階中に相互認証するSIPクライアントとSIPプロキシサーバを含むセッションイニシエーションプロトコル(SIP)システムを示す概略図である。
【図3】SIPクライアントとSIPプロキシサーバの間の認証目的のシグナリングメッセージ交換を示す概略図である。
【図4】SIPのフレームワークに組み込まれたセキュリティ機構のオペレーションを表す状態機械を示す概略図である。
【図5】SIPクライアントが複数のSIPプロキシと認証オペレーションを実行するためのシグナリングメッセージ交換を示す概略図である。
【図6】ケルベロスセキュリティ機構を使用したSIPクライアントとプロキシの間のプレ認証プロセスにおけるメッセージフローを示す概略図である。
【図7】ケルベロスセキュリティ機構を使用したSIPクライアントとプロキシの間のチャレンジド認証プロセスにおけるメッセージフローを示す概略図である。
【図8】NTLMセキュリティ機構を使用したSIPクライアントとプロキシの間のチャレンジド認証プロセスにおけるメッセージフローを示す概略図である。
【図9】NTLMセキュリティ機構を使用したSIPクライアントとプロキシの間のプレ認証プロセスにおけるメッセージフローを示す概略図である。
【符号の説明】
20 パーソナルコンピュータ
21 処理ユニット
22 システムメモリ
23 システムバス
24 ROM
25 RAM
27 ハードディスクドライブ
28 磁気ディスクドライブ
30 光ドライブ
32 ハードディスクドライブインタフェース
33 磁気ディスクドライブインタフェース
34 光ディスクドライブインタフェース
35 オペレーティングシステム
36 アプリケーションプログラム
37 その他のプログラムモジュール
38 プログラムデータ
40 キーボード
42 マウス
46 シリアルポートインタフェース
47 モニタ
48 ビデオアダプタ
49 リモートコンピュータ
50 メモリ記憶装置
51 ローカルエリアネットワーク
52 ワイドエリアネットワーク
53 ネットワークインタフェース
54 モデム
72 SIPクライアント
74 SIPプロキシサーバ
76、80 ユーザ
82 INVITEメッセージ
86 SIPクライアント
88 ワークステーション
90 シグナリング経路
96 407チャレンジメッセージ
102 ドメインコントローラ
108 サーバチケット
110 INVITEメッセージ
116 セッションキー
120 SIPプロキシサーバ
122 200OKメッセージ
170、172、176 KDC
180、182 ケルベロスモジュール

Claims (22)

  1. セッションイニシエーションプロトコル(SIP)プロキシを介してセッションを開始することに関連してSIPクライアントとSIPプロキシの間の相互認証をするための方法であって、
    前記SIPクライアントから前記SIPプロキシに第1のINVITEリクエストを送信するステップと、
    前記SIPプロキシが前記第1のINVITEリクエストを受信したことに応答して、SIPプロキシのセキュリティコンテキストを含むチャレンジメッセージを前記SIPクライアントに送信するステップと、
    前記SIPクライアントが前記チャレンジメッセージを受信したことに応答して、
    前記SIPクライアントのドメインコントローラーから前記SIPプロキシのセッションキーとサーバーチケットとを取得するステップであって、該セッションキーは前記SIPクライアントのキーで暗号化されており、該サーバーチケットはSIPプロキシの長期キーで暗号化されていてSIPクライアントの認証データを含んでいるステップと、
    前記SIPクライアントの前記キーに基づいて前記セッションキーを解読するステップと、
    前記セッションキーによって署名され、かつ前記サーバーチケット及びSIPプロキシのセキュリティコンテキストを含む第2のINVITEリクエストを前記SIPプロキシに送信するステップと、
    前記SIPプロキシが前記第2のINVITEリクエストを受信したことに応答して、
    前記SIPプロキシの前記長期キーに基づいて前記サーバーチケットを解読するステップと、
    前記サーバーチケット内のSIPクライアントの認証データが、前記SIPクライアントが信頼のおけるものであること、前記第2のINVITEリクエストに含まれるセキュリティコンテキストがSIPプロキシのセキュリティコンテキストに合致するものであること、及び前記第2のINVITEリクエストが前記セッションキーによって署名されていることを示す場合に、前記第2のINVITEリクエストに基づいてINVITEリクエストを所望のサーバーに送信するステップと、
    前記所望のサーバーから前記INVITEリクエストに対する応答を受信すると、前記セッションキーで前記応答に署名して、SIPクライアントがSIPプロキシを認証できるように前記署名された応答を前記SIPクライアントに送信するステップと
    を含むことを特徴とする方法。
  2. 前記SIPプロキシは、前記セッションキーを生成することを特徴とする請求項1に記載の方法。
  3. 前記SIPプロキシは、前記セッションキーを自身のドメインコントローラーに提供し、前記SIPプロキシの前記ドメインコントローラーは、前記SIPクライアントのドメインコントローラーに前記セッションキーを提供することを特徴とする請求項2に記載の方法。
  4. 前記サーバーチケットは、前記セッションキーを含むことを特徴とする請求項1に記載の方法。
  5. 前記SIPクライアントが前記署名された応答を受信すると、前記応答が前記セッションキーで署名されていることを確認するステップをさらに含むことを特徴とする請求項1に記載の方法。
  6. セッションイニシエーションプロトコル(SIP)プロキシを介してセッションを開始することに関連してSIPクライアントとSIPプロキシの間の相互認証を提供するコンピュータシステムを制御する命令を記憶したコンピュータ読み取り可能な記録媒体であって、
    前記命令は、
    前記SIPクライアントから第1のINVITEリクエストを受信するステップと、
    セッションキーを中継コンピュータに提供するステップと、
    前記第1のINVITEリクエストを受信したことに応答して、SIPプロキシのセキュリティコンテキストを含むチャレンジメッセージを前記SIPクライアントに送信するステップと、
    認証データを含む暗号化されたサーバーチケットとセキュリティコンテキストとを含む、セッションキーによって署名された第2のINVITEリクエストをSIPプロキシが受信するステップと、
    前記SIPプロキシの長期キーに基づいて前記サーバーチケットを解読するステップと、
    前記サーバーチケット内の認証データが、前記SIPクライアントが信頼のおけるものであること、前記第2のINVITEリクエストに含まれるセキュリティコンテキストがSIPプロキシのセキュリティコンテキストに合致するものであること、及び前記第2のINVITEリクエストが前記セッションキーによって署名されていることを示す場合に、INVITEリクエストを所望のサーバーに送信するステップと、
    前記所望のサーバーから前記INVITEリクエストに対する応答を受信すると、前記セッションキーで前記応答に署名して、SIPクライアントがSIPプロキシを認証できるように前記署名された応答を前記SIPクライアントに転送するステップと
    を含む方法を実行することによって前記コンピュータシステムを制御することを特徴とするコンピュータ読み取り可能な記録媒体。
  7. 前記サーバーチケットは、前記セッションキーを含むことを特徴とする請求項6に記載のコンピュータ読み取り可能な記録媒体。
  8. 前記中継コンピュータは、前記セッションキーをSIPクライアントに提供することを特徴とする請求項6に記載のコンピュータ読み取り可能な記録媒体。
  9. 前記中継コンピュータは、前記SIPプロキシのドメインコントローラーであり、前記SIPプロキシのドメインコントローラーは、前記セッションキーを前記SIPクライアントのドメインコントローラーに提供することを特徴とする請求項6に記載のコンピュータ読み取り可能な記録媒体。
  10. 前記チャレンジメッセージを受信したことに応答して、前記SIPクライアントが、
    前記中継コンピュータから前記SIPプロキシのセッションキーとサーバーチケットとを取得するステップであって、前記セッションキーは前記SIPクライアントのキーで暗号化されており、前記サーバーチケットはSIPプロキシの長期キーで暗号化されていてSIPクライアントの認証データを含んでいるステップと、
    前記SIPクライアントの前記キーに基づいて前記セッションキーを解読するステップと、
    前記セッションキーによって署名され、かつ前記サーバーチケット及びSIPプロキシのセキュリティコンテキストを含む第2のINVITEリクエストを前記SIPプロキシに送信するステップと
    を実行することを特徴とする請求項6に記載のコンピュータ読み取り可能な記録媒体。
  11. セッションイニシエーションプロトコル(SIP)プロキシを介してセッションを開始することに関連してSIPクライアントとSIPプロキシの間の相互認証を提供するコンピュータシステムを制御する命令を記憶したコンピュータ読み取り可能な記録媒体であって、
    前記命令は、
    前記SIPプロキシに第1のINVITEリクエストを送信するステップと、
    SIPプロキシのセキュリティコンテキストを含むチャレンジメッセージを前記SIPプロキシから受信するステップと、
    前記チャレンジメッセージを受信したことに応答して、SIPクライアントが、
    SIPクライアントの中継コンピュータからSIPプロキシのセッションキーとサーバーチケットとを取得するステップであって、前記サーバーチケットはSIPプロキシの長期キーで暗号化されており、SIPプロキシがSIPクライアントを認証できるようにSIPクライアントの認証データを含んでいるステップと、
    前記セッションキーによって署名され、サーバーチケットとSIPプロキシのセキュリティコンテキストとを含む第2のINVITEリクエストをSIPプロキシに送信するステップと、
    SIPプロキシから前記第2のINVITEリクエストに対する応答を受信するステップと、
    前記応答がSIPプロキシを認証するために前記セッションキーによって署名されていることを確認するステップと
    を含む方法を実行することによって前記コンピュータシステムを制御することを特徴とするコンピュータ読み取り可能な記録媒体。
  12. 前記サーバーチケットは、前記セッションキーを含むことを特徴とする請求項11に記載のコンピュータ読み取り可能な記録媒体。
  13. 前記SIPクライアントの中継コンピュータは、前記セッションキーを前記SIPプロキシの中継コンピュータから取得することを特徴とする請求項11に記載のコンピュータ読み取り可能な記録媒体。
  14. 前記SIPクライアントの中継コンピュータは、前記SIPクライアントのドメインコントローラーであり、前記SIPプロキシの中継コンピュータは、前記SIPプロキシのドメインコントローラーであることを特徴とする請求項13に記載のコンピュータ読み取り可能な記録媒体。
  15. 前記SIPクライアント及び前記SIPプロキシは、相異なるドメインに存在することを特徴とする請求項11に記載のコンピュータ読み取り可能な記録媒体。
  16. 前記SIPプロキシは、前記サーバーチケットの認証データに基づいて前記SIPクライアントを認証することを特徴とする請求項11に記載のコンピュータ読み取り可能な記録媒体。
  17. 前記第2のINVITEリクエストを受信すると、前記SIPプロキシが、
    前記SIPプロキシの長期キーに基づいて前記サーバーチケットを解読し、
    前記サーバーチケット内の認証データが、前記SIPクライアントが信頼のおけるものであること、前記第2のINVITEリクエストに含まれるセキュリティコンテキストがSIPプロキシのセキュリティコンテキストに合致するものであること、及び前記第2のINVITEリクエストが前記セッションキーによって署名されていることを示す場合に、INVITEリクエストを所望のサーバーに送信し、
    前記所望のサーバーから前記INVITEリクエストに対する応答を受信すると、前記セッションキーで前記応答に署名して、SIPクライアントがSIPプロキシを認証できるように前記署名された応答をSIPクライアントに転送する
    ことを特徴とする請求項11に記載のコンピュータ読み取り可能な記録媒体。
  18. 前記SIPプロキシは、前記第1のINVITEリクエストをSIPクライアントから受信し、前記セッションキーを前記中継コンピュータに提供し、SIPプロキシのセキュリティコンテキストを含むチャレンジメッセージをSIPクライアントに送信することを特徴とする請求項15に記載のコンピュータ読み取り可能な記録媒体。
  19. セッションイニシエーションプロトコル(SIP)プロキシを介してセッションを開始することに関連してSIPクライアントとSIPプロキシの間の相互認証をするための方法であって、
    前記SIPクライアントから前記SIPプロキシに第1のINVITEリクエストを送信するステップと、
    前記SIPプロキシが前記第1のINVITEリクエストを受信したことに応答して、SIPプロキシのセキュリティコンテキストを含むチャレンジメッセージを前記SIPクライアントに送信するステップと、
    前記SIPクライアントが前記チャレンジメッセージを受信したことに応答して、中継コンピュータ経由でSIPプロキシによって提供されたセッションキーによって署名され、かつサーバーチケット及びSIPプロキシのセキュリティコンテキストを含む第2のINVITEリクエストを前記SIPプロキシに送信するステップであって、該サーバーチケットはSIPクライアントの認証データを含んでいるステップと、
    前記SIPプロキシが前記第2のINVITEリクエストを受信すると、
    前記サーバーチケット内のSIPクライアントの認証データが、前記SIPクライアントが信頼のおけるものであること、前記第2のINVITEリクエストに含まれるセキュリティコンテキストがSIPプロキシのセキュリティコンテキストに合致するものであること、及び前記第2のINVITEリクエストが前記セッションキーによって署名されていることを示す場合に、前記第2のINVITEリクエストに基づいてINVITEリクエストを所望のサーバーに送信するステップと、
    前記所望のサーバーから前記INVITEリクエストに対する応答を受信すると、前記セッションキーで前記応答に署名して、前記署名された応答を前記SIPクライアントに転送するステップと
    前記応答をSIPクライアントが受信すると、前記応答がSIPプロキシを認証するために前記セッションキーで署名されていることを確認するステップと
    を含むことを特徴とする方法。
  20. 前記SIPクライアントは、SIPプロキシの長期キーで前記サーバーチケットを暗号化し、
    前記SIPプロキシは、前記SIPプロキシの長期キーに基づいて前記サーバーチケットを解読することを特徴とする請求項19に記載の方法。
  21. 前記SIPプロキシは、前記中継コンピュータに前記セッションキーを提供することを特徴とする請求項19に記載の方法。
  22. 前記SIPプロキシ及び前記SIPクライアントが相異なるドメインに存在する場合に、
    前記SIPプロキシは、SIPプロキシのドメインの中継コンピュータに前記セッションキーを提供し、
    前記SIPプロキシのドメインの中継コンピュータは、SIPクライアントのドメインの中継コンピュータに前記セッションキーを提供し、
    前記SIPクライアントのドメインの中継コンピュータは、SIPクライアントに前記セッションキーを提供することを特徴とする請求項19に記載の方法。
JP2002174951A 2001-06-14 2002-06-14 クライアント・プロキシ認証のためにセッションイニシエーションプロトコルリクエストメッセージにセキュリティ機構を組み込むための方法およびシステム Active JP4294268B2 (ja)

Priority Applications (4)

Application Number Priority Date Filing Date Title
US29823901P true 2001-06-14 2001-06-14
US60/298,239 2001-06-14
US10/151,747 2002-05-17
US10/151,747 US7243370B2 (en) 2001-06-14 2002-05-17 Method and system for integrating security mechanisms into session initiation protocol request messages for client-proxy authentication

Publications (2)

Publication Number Publication Date
JP2003108527A JP2003108527A (ja) 2003-04-11
JP4294268B2 true JP4294268B2 (ja) 2009-07-08

Family

ID=26848932

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2002174951A Active JP4294268B2 (ja) 2001-06-14 2002-06-14 クライアント・プロキシ認証のためにセッションイニシエーションプロトコルリクエストメッセージにセキュリティ機構を組み込むための方法およびシステム

Country Status (5)

Country Link
US (2) US7243370B2 (ja)
EP (1) EP1267548B1 (ja)
JP (1) JP4294268B2 (ja)
AT (1) AT398882T (ja)
DE (1) DE60227132D1 (ja)

Families Citing this family (148)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7801953B1 (en) * 2001-02-12 2010-09-21 Nortel Networks Limited Push-to-talk wireless telecommunications system utilizing an voice-over-IP network
US6839761B2 (en) * 2001-04-19 2005-01-04 Microsoft Corporation Methods and systems for authentication through multiple proxy servers that require different authentication data
US7010727B1 (en) * 2001-06-15 2006-03-07 Nortel Networks Limited Method and system for negotiating compression techniques to be utilized in packet data communications
US20030084171A1 (en) * 2001-10-29 2003-05-01 Sun Microsystems, Inc., A Delaware Corporation User access control to distributed resources on a data communications network
US20030084172A1 (en) * 2001-10-29 2003-05-01 Sun Microsystem, Inc., A Delaware Corporation Identification and privacy in the World Wide Web
US20030084302A1 (en) * 2001-10-29 2003-05-01 Sun Microsystems, Inc., A Delaware Corporation Portability and privacy with data communications network browsing
US7275260B2 (en) 2001-10-29 2007-09-25 Sun Microsystems, Inc. Enhanced privacy protection in identification in a data communications network
US7509425B1 (en) * 2002-01-15 2009-03-24 Dynamicsoft, Inc. Establishing and modifying network signaling protocols
US7240366B2 (en) 2002-05-17 2007-07-03 Microsoft Corporation End-to-end authentication of session initiation protocol messages using certificates
WO2004006501A1 (en) * 2002-07-03 2004-01-15 British Telecommunications Public Limited Company Trust establishment for multi-party communications
JP4777651B2 (ja) * 2002-08-23 2011-09-21 イグジット−キューブ,インク. コンピュータシステム及びデータ保存方法
US7343398B1 (en) * 2002-09-04 2008-03-11 Packeteer, Inc. Methods, apparatuses and systems for transparently intermediating network traffic over connection-based authentication protocols
US7900245B1 (en) * 2002-10-15 2011-03-01 Sprint Spectrum L.P. Method and system for non-repeating user identification in a communication system
US7475241B2 (en) * 2002-11-22 2009-01-06 Cisco Technology, Inc. Methods and apparatus for dynamic session key generation and rekeying in mobile IP
US7870389B1 (en) * 2002-12-24 2011-01-11 Cisco Technology, Inc. Methods and apparatus for authenticating mobility entities using kerberos
GB2398034B (en) * 2003-02-04 2005-08-10 Rolls Royce Plc Laser shock peening
GB0306864D0 (en) * 2003-03-25 2003-04-30 Nokia Corp Service provisioning in a communication system
US8473620B2 (en) * 2003-04-14 2013-06-25 Riverbed Technology, Inc. Interception of a cloud-based communication connection
WO2005008954A1 (ja) * 2003-06-19 2005-01-27 Nippon Telegraph And Telephone Corporation セッション制御サーバ及び通信システム
US7543061B2 (en) * 2003-06-26 2009-06-02 Microsoft Corporation Method and system for distributing load by redirecting traffic
US20050039002A1 (en) * 2003-07-29 2005-02-17 International Business Machines Corporation Method, system and program product for protecting a distributed application user
JP2011120242A (ja) * 2003-08-06 2011-06-16 Panasonic Corp 中継サーバ、中継サーバのサービス管理方法、サービス提供システム、およびプログラム
JP2005073236A (ja) * 2003-08-06 2005-03-17 Matsushita Electric Ind Co Ltd 中継サーバ、中継サーバのサービス管理方法、サービス提供システム、およびプログラム
US7417981B2 (en) * 2003-10-15 2008-08-26 Vonage Holdings Corp. Method and apparatus for enhanced Internet Telephony
GB0324364D0 (en) * 2003-10-17 2003-11-19 Nokia Corp Authentication of messages in a communication system
US9602275B2 (en) * 2003-10-28 2017-03-21 Intel Corporation Server pool kerberos authentication scheme
TWI270281B (en) * 2003-12-01 2007-01-01 Interdigital Tech Corp Session initiation protocol (SIP) based user initiated handoff device and method thereof
DE102004004048A1 (de) * 2004-01-27 2005-08-18 Siemens Ag Kommunikationssystem, Verfahren zum Anmelden einer Kommunikationsbeziehung und Netzwerkverbindungs-Rechner
US7665147B2 (en) * 2004-02-05 2010-02-16 At&T Mobility Ii Llc Authentication of HTTP applications
US7386111B2 (en) * 2004-02-10 2008-06-10 Vonage Network Inc. Method and apparatus for placing a long distance call based on a virtual phone number
CN1658547B (zh) * 2004-02-16 2010-08-18 华为技术有限公司 密钥分发方法
JP2005236537A (ja) 2004-02-18 2005-09-02 Nec Access Technica Ltd 無線LANを利用したVoIPワイヤレス電話システム及び方法
US7779036B2 (en) * 2004-02-19 2010-08-17 Oracle International Corporation Integration functionality for a test tool for application programming interfaces
EP1578080A1 (en) * 2004-03-18 2005-09-21 Hewlett-Packard Development Company, L.P. Improvements in or relating to session initiation protocol (SIP)
US7549048B2 (en) * 2004-03-19 2009-06-16 Microsoft Corporation Efficient and secure authentication of computing systems
JP4276568B2 (ja) 2004-03-26 2009-06-10 株式会社日立コミュニケーションテクノロジー ルータ及びsipサーバ
JP4028853B2 (ja) 2004-03-30 2007-12-26 株式会社日立製作所 情報サービス通信ネットワークシステムおよびセッション管理サーバ
US7535905B2 (en) 2004-03-31 2009-05-19 Microsoft Corporation Signing and validating session initiation protocol routing headers
US8024476B2 (en) * 2004-05-21 2011-09-20 Microsoft Corporation Efficient message routing when using server pools
CN1716953B (zh) * 2004-06-28 2010-09-15 华为技术有限公司 会话初始协议认证的方法
US7617501B2 (en) 2004-07-09 2009-11-10 Quest Software, Inc. Apparatus, system, and method for managing policies on a computer having a foreign operating system
JP4710267B2 (ja) * 2004-07-12 2011-06-29 株式会社日立製作所 ネットワークシステム、データ中継装置、セッションモニタシステム、およびパケットモニタ中継装置
SG156660A1 (en) * 2004-07-20 2009-11-26 Qualcomm Inc Handoff between a sip network and a cellular communication system
WO2006018647A1 (en) * 2004-08-20 2006-02-23 Rhoderick John Kennedy Pugh Server authentication
GB0419479D0 (en) * 2004-09-02 2004-10-06 Cryptomathic Ltd Data certification methods and apparatus
US7639802B2 (en) * 2004-09-27 2009-12-29 Cisco Technology, Inc. Methods and apparatus for bootstrapping Mobile-Foreign and Foreign-Home authentication keys in Mobile IP
JP2006100971A (ja) * 2004-09-28 2006-04-13 Nakayo Telecommun Inc グループ管理装置およびグループ呼び出し方法
US7502331B2 (en) * 2004-11-17 2009-03-10 Cisco Technology, Inc. Infrastructure-less bootstrapping: trustless bootstrapping to enable mobility for mobile devices
JP2006157572A (ja) * 2004-11-30 2006-06-15 Nec Corp インスタントメッセージによる同報配信方法及び装置
US7958347B1 (en) * 2005-02-04 2011-06-07 F5 Networks, Inc. Methods and apparatus for implementing authentication
US8219823B2 (en) 2005-03-04 2012-07-10 Carter Ernst B System for and method of managing access to a system using combinations of user information
US7555784B2 (en) * 2005-03-04 2009-06-30 Microsoft Corporation Method and system for safely disclosing identity over the internet
US20060210040A1 (en) * 2005-03-16 2006-09-21 Jeffrey Citron Transfer identification software enabling electronic communication system
US8683044B2 (en) * 2005-03-16 2014-03-25 Vonage Network Llc Third party call control application program interface
US20060210036A1 (en) * 2005-03-16 2006-09-21 Jeffrey Citron System for effecting a telephone call over a computer network without alphanumeric keypad operation
US8086853B2 (en) * 2005-03-18 2011-12-27 Microsoft Corporation Automatic centralized authentication challenge response generation
JP2008535427A (ja) * 2005-04-07 2008-08-28 フランス テレコム データ処理デバイスとセキュリティモジュールとの間のセキュア通信
US8996423B2 (en) * 2005-04-19 2015-03-31 Microsoft Corporation Authentication for a commercial transaction using a mobile module
JP4571006B2 (ja) * 2005-04-19 2010-10-27 エヌ・ティ・ティ・コミュニケーションズ株式会社 ネットワーク制御装置、ネットワークシステム、及びプログラム
CN1889562A (zh) * 2005-06-28 2007-01-03 华为技术有限公司 对接收初始会话协议请求消息的设备进行认证的方法
US7499405B2 (en) * 2005-06-28 2009-03-03 International Business Machines Corporation Method for testing branch execution and state transition logic in session initiation protocol application modular components
US8184641B2 (en) 2005-07-20 2012-05-22 Verizon Business Global Llc Method and system for providing secure communications between proxy servers in support of interdomain traversal
US8613071B2 (en) * 2005-08-10 2013-12-17 Riverbed Technology, Inc. Split termination for secure communication protocols
US8478986B2 (en) * 2005-08-10 2013-07-02 Riverbed Technology, Inc. Reducing latency of split-terminated secure communication protocol sessions
US8438628B2 (en) * 2005-08-10 2013-05-07 Riverbed Technology, Inc. Method and apparatus for split-terminating a secure network connection, with client authentication
CN100488139C (zh) * 2005-08-10 2009-05-13 华为技术有限公司 建立聊天室数据传输通道实现聊天消息传送的方法
US20090119504A1 (en) * 2005-08-10 2009-05-07 Riverbed Technology, Inc. Intercepting and split-terminating authenticated communication connections
US20070067638A1 (en) * 2005-09-22 2007-03-22 Roland Haibl Method of Session Consolidation
GB0519524D0 (en) * 2005-09-24 2005-11-02 Ibm Method and apparatus for verifying encryption of SIP signalling
EP1935154B1 (en) * 2005-10-13 2011-06-01 Vonage Holdings Corp. Method and system for detecting a change in device attachment
US7626963B2 (en) * 2005-10-25 2009-12-01 Cisco Technology, Inc. EAP/SIM authentication for mobile IP to leverage GSM/SIM authentication infrastructure
CA2633363A1 (en) 2005-11-09 2007-05-08 Vonage Holdings Corp. Method and system for customized caller identification
US7904949B2 (en) 2005-12-19 2011-03-08 Quest Software, Inc. Apparatus, systems and methods to provide authentication services to a legacy application
US7614080B2 (en) * 2005-12-28 2009-11-03 Panasonic Electric Works Co., Ltd. Systems and methods for providing secure access to embedded devices using a trust manager and a security broker
EP1985096A1 (en) * 2006-02-01 2008-10-29 Vonage Holdings Corp. Method and apparatus for communicating a status of a device in a packet-based communication network
US8087075B2 (en) * 2006-02-13 2011-12-27 Quest Software, Inc. Disconnected credential validation using pre-fetched service tickets
EP1989823B1 (en) * 2006-02-27 2012-11-07 Vonage Network LLC Method and system for bidirectional data transfer
US8528057B1 (en) * 2006-03-07 2013-09-03 Emc Corporation Method and apparatus for account virtualization
WO2007106620A2 (en) * 2006-03-10 2007-09-20 Motorola, Inc. Method for authenticating a mobile node in a communication network
US8782393B1 (en) 2006-03-23 2014-07-15 F5 Networks, Inc. Accessing SSL connection data by a third-party
WO2007131548A1 (en) * 2006-05-15 2007-11-22 Telefonaktiebolaget Lm Ericsson (Publ) Method and apparatuses for establishing a secure channel between a user terminal and a sip server
US7913084B2 (en) * 2006-05-26 2011-03-22 Microsoft Corporation Policy driven, credential delegation for single sign on and secure access to network resources
US8429712B2 (en) 2006-06-08 2013-04-23 Quest Software, Inc. Centralized user authentication system apparatus and method
CN101090314A (zh) * 2006-06-15 2007-12-19 松下电器产业株式会社 整合票证授予服务于通话起始协议的鉴别方法及其装置
US20080005785A1 (en) * 2006-06-16 2008-01-03 Nokia Corporation Usage of nonce-based authentication scheme in a session-based authentication application
JP2008033652A (ja) * 2006-07-28 2008-02-14 Nec Infrontia Corp クライアント・サーバ型分散システム、クライアント装置、サーバ装置及びそれらに用いる相互認証方法
US20080075064A1 (en) * 2006-08-30 2008-03-27 Microsoft Corporation Device to PC authentication for real time communications
US20080072303A1 (en) * 2006-09-14 2008-03-20 Schlumberger Technology Corporation Method and system for one time password based authentication and integrated remote access
US20080092226A1 (en) * 2006-10-12 2008-04-17 Motorola, Inc. Pre-registration secure and authenticatedsession layer path establishment
US7895332B2 (en) 2006-10-30 2011-02-22 Quest Software, Inc. Identity migration system apparatus and method
US8086710B2 (en) 2006-10-30 2011-12-27 Quest Software, Inc. Identity migration apparatus and method
US20080137643A1 (en) * 2006-12-08 2008-06-12 Microsoft Corporation Accessing call control functions from an associated device
US7827405B2 (en) 2007-01-19 2010-11-02 Microsoft Corporation Mechanism for utilizing kerberos features by an NTLM compliant entity
KR101336330B1 (ko) 2007-02-13 2013-12-03 삼성전자주식회사 키 확립 시스템 및 이를 이용한 방법
US8917717B2 (en) * 2007-02-13 2014-12-23 Vonage Network Llc Method and system for multi-modal communications
US8695074B2 (en) * 2007-04-26 2014-04-08 Microsoft Corporation Pre-authenticated calling for voice applications
US7591013B2 (en) * 2007-07-31 2009-09-15 Cisco Technology, Inc. System and method for client initiated authentication in a session initiation protocol environment
KR101412800B1 (ko) 2007-09-17 2014-06-30 삼성전자주식회사 통신 시스템에서 암호 통신 방법 및 장치
US8516566B2 (en) * 2007-10-25 2013-08-20 Apple Inc. Systems and methods for using external authentication service for Kerberos pre-authentication
US20090158299A1 (en) * 2007-10-31 2009-06-18 Carter Ernst B System for and method of uniform synchronization between multiple kernels running on single computer systems with multiple CPUs installed
US8347374B2 (en) * 2007-11-15 2013-01-01 Red Hat, Inc. Adding client authentication to networked communications
ES2589112T3 (es) * 2007-11-30 2016-11-10 Telefonaktiebolaget Lm Ericsson (Publ) Gestión de claves para comunicación segura
EP2245832B1 (de) 2008-01-07 2016-01-06 Unify GmbH & Co. KG Verfahren zum authentisieren einer schlüsselinformation zwischen endpunkten einer kommunikationsbeziehung
US7912969B2 (en) * 2008-01-09 2011-03-22 International Business Machines Corporation Methods and apparatus for randomization of periodic behavior in communication network
WO2009101235A1 (en) * 2008-02-14 2009-08-20 Nokia Corporation System and method for implementing a publication
US8132246B2 (en) * 2008-02-27 2012-03-06 Microsoft Corporation Kerberos ticket virtualization for network load balancers
CN101296085B (zh) * 2008-06-23 2011-07-13 中兴通讯股份有限公司 基于分叉的认证方法、系统以及分叉认证装置
US8477941B1 (en) * 2008-07-10 2013-07-02 Sprint Communications Company L.P. Maintaining secure communication while transitioning networks
US8990569B2 (en) * 2008-12-03 2015-03-24 Verizon Patent And Licensing Inc. Secure communication session setup
US20100166182A1 (en) * 2008-12-31 2010-07-01 Verizon Data Services, Llc Method and system for securing voice over internet protocol transmissions
US8462942B2 (en) * 2008-12-31 2013-06-11 Verizon Patent And Licensing Inc. Method and system for securing packetized voice transmissions
US9258696B2 (en) * 2009-02-11 2016-02-09 Alcatel-Lucent Method for secure network based route optimization in mobile networks
US8707043B2 (en) * 2009-03-03 2014-04-22 Riverbed Technology, Inc. Split termination of secure communication sessions with mutual certificate-based authentication
US8266680B2 (en) * 2009-03-31 2012-09-11 Microsoft Corporation Predictive HTTP authentication mode negotiation
US8347356B2 (en) * 2009-03-31 2013-01-01 Microsoft Corporation Adaptive HTTP authentication scheme selection
EP3086532B1 (en) 2009-04-13 2019-11-06 BlackBerry Limited System and method for determining trust for sip messages
US8255984B1 (en) 2009-07-01 2012-08-28 Quest Software, Inc. Single sign-on system for shared resource environments
US8700892B2 (en) 2010-03-19 2014-04-15 F5 Networks, Inc. Proxy SSL authentication in split SSL for client-side proxy agent resources with content insertion
EP2383952B1 (en) * 2010-04-27 2014-10-08 BlackBerry Limited Apparatus and method for resolving a race condition between two session initiation protocol (SIP) end points
US8650392B2 (en) * 2010-05-21 2014-02-11 Microsoft Corporation Ticket authorization
EP2466522A1 (en) * 2010-11-30 2012-06-20 Gemalto SA Method for providing a user with an authentificated remote access to a remote secure device
KR101981812B1 (ko) * 2011-02-28 2019-05-23 인터랙티브 소셜 인터네트웍스, 엘엘씨 네트워크 통신 시스템들 및 방법들
CN102868665B (zh) * 2011-07-05 2016-07-27 华为软件技术有限公司 数据传输的方法及装置
US8661253B2 (en) * 2011-07-18 2014-02-25 Motorola Solutions, Inc. Methods of providing an integrated and mutual authentication in a communication network
JP5085778B1 (ja) * 2011-09-30 2012-11-28 株式会社東芝 情報処理装置、起動制御方法およびプログラム
US8695069B1 (en) * 2012-01-31 2014-04-08 Intuit Inc. Session management between a web application and a CRM system
US8934383B1 (en) 2012-02-22 2015-01-13 West Corporation Internet SIP registration/proxy service for audio conferencing
US9137028B1 (en) 2012-02-22 2015-09-15 West Corporation Internet sip registration/proxy service for audio conferencing
CN103905785B (zh) * 2012-12-27 2018-03-13 中国电信股份有限公司 控制sip视频业务接续的方法、系统与sip网关
US9686284B2 (en) 2013-03-07 2017-06-20 T-Mobile Usa, Inc. Extending and re-using an IP multimedia subsystem (IMS)
US9992183B2 (en) * 2013-03-15 2018-06-05 T-Mobile Usa, Inc. Using an IP multimedia subsystem for HTTP session authentication
KR101730757B1 (ko) * 2013-04-12 2017-04-26 엔이씨 유럽 리미티드 사용자에 의해 디바이스에 액세스하기 위한 방법 및 시스템
CN105143954B (zh) * 2013-04-26 2018-06-19 浜松光子学株式会社 图像取得装置、取得试样的对准焦点信息的方法以及系统
US10348954B2 (en) * 2013-04-26 2019-07-09 Hamamatsu Photonics K.K. Image acquisition device and method and system for creating focus map for specimen
US9203906B2 (en) 2013-06-30 2015-12-01 Vonage Network, Llc Systems and methods for enabling data communications to a telephony device
US9203593B2 (en) 2013-06-30 2015-12-01 Vonage Network, Llc Systems and methods for enabling data communications to a telephony device
US8892748B1 (en) * 2013-06-30 2014-11-18 Vonage Network, Llc Systems and methods for enabling data communications to a telephony device
US9112846B2 (en) * 2013-10-11 2015-08-18 Centrify Corporation Method and apparatus for transmitting additional authorization data via GSSAPI
US20150172324A1 (en) * 2013-12-13 2015-06-18 Alcatel-Lucent Usa Inc. Authorized SIP Redirection
US9641504B2 (en) * 2014-12-15 2017-05-02 Sap Se HTTP header-based adaptable authentication mechanism
US10887314B2 (en) * 2015-09-29 2021-01-05 Verisign, Inc. Access control for named domain networking
US9832024B2 (en) * 2015-11-13 2017-11-28 Visa International Service Association Methods and systems for PKI-based authentication
KR20170104180A (ko) * 2016-03-07 2017-09-15 한국전자통신연구원 전자 장치 및 전자 장치 간의 인증 수행 방법
US10601595B2 (en) * 2016-05-04 2020-03-24 Avaya Inc. Secure application attachment
US10567492B1 (en) 2017-05-11 2020-02-18 F5 Networks, Inc. Methods for load balancing in a federated identity environment and devices thereof
JP6456451B1 (ja) * 2017-09-25 2019-01-23 エヌ・ティ・ティ・コミュニケーションズ株式会社 通信装置、通信方法、及びプログラム
US10833943B1 (en) 2018-03-01 2020-11-10 F5 Networks, Inc. Methods for service chaining and devices thereof
US10715996B1 (en) 2019-06-06 2020-07-14 T-Mobile Usa, Inc. Transparent provisioning of a third-party service for a user device on a telecommunications network

Family Cites Families (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5695949A (en) * 1995-04-07 1997-12-09 Lxn Corp. Combined assay for current glucose level and intermediate or long-term glycemic control
US6173173B1 (en) 1998-07-02 2001-01-09 Lucent Technologies, Inc. Invalid mobile telephone call terminating system and method
US6970930B1 (en) 1999-11-05 2005-11-29 Mci, Inc. Method and system of providing differentiated services
AU6422200A (en) * 2000-02-08 2001-08-20 Swisscom Mobile Ag Single sign-on process
US20020120760A1 (en) * 2000-05-26 2002-08-29 Gur Kimchi Communications protocol
US6870848B1 (en) * 2000-06-07 2005-03-22 Nortel Networks Limited Method and apparatus for call processing in response to a call request from an originating device
US20020078153A1 (en) * 2000-11-02 2002-06-20 Chit Chung Providing secure, instantaneous, directory-integrated, multiparty, communications services
US6904035B2 (en) * 2000-11-29 2005-06-07 Nokia Corporation Mobile system, terminal and interface, as well as methods for providing backward compatibility to first and second generation mobile systems
US6865681B2 (en) * 2000-12-29 2005-03-08 Nokia Mobile Phones Ltd. VoIP terminal security module, SIP stack with security manager, system and security methods
US7945592B2 (en) * 2001-03-20 2011-05-17 Verizon Business Global Llc XML based transaction detail records
US7529359B2 (en) * 2001-03-20 2009-05-05 Verizon Business Global Llc Caller treatment in a SIP network
US6996841B2 (en) 2001-04-19 2006-02-07 Microsoft Corporation Negotiating secure connections through a proxy server
US7103773B2 (en) * 2001-10-26 2006-09-05 Hewlett-Packard Development Company, L.P. Message exchange in an information technology network
US7039649B2 (en) 2002-05-17 2006-05-02 Sun Microsystems, Inc. Method and apparatus for maintaining data integrity

Also Published As

Publication number Publication date
DE60227132D1 (de) 2008-07-31
EP1267548B1 (en) 2008-06-18
JP2003108527A (ja) 2003-04-11
AT398882T (de) 2008-07-15
US7770007B2 (en) 2010-08-03
EP1267548A2 (en) 2002-12-18
US7243370B2 (en) 2007-07-10
EP1267548A3 (en) 2005-04-20
US20030005280A1 (en) 2003-01-02
US20080022383A1 (en) 2008-01-24

Similar Documents

Publication Publication Date Title
US10560485B2 (en) System and method for connecting a communication to a client
US9148482B2 (en) System and method for SIP user agent identification and efficient binding
KR102068367B1 (ko) 사물인터넷을 위한 데이터그램 전송에서 경량 인증을 위한 컴퓨터 구현 시스템 및 방법
JP5243593B2 (ja) 動的ネットワークにおけるセキュリティリンク管理
Aboba et al. Extensible authentication protocol (EAP)
US8627440B2 (en) PassThru for client authentication
EP2449744B1 (en) Restriction of communication in voip address discovery system
US9106648B2 (en) Method and apparatus for data transmission
US7386878B2 (en) Authenticating peer-to-peer connections
JP4959750B2 (ja) トランスコーディング・プロキシでの複数の起点サーバへの動的接続
US7562221B2 (en) Authentication method and apparatus utilizing proof-of-authentication module
US8028329B2 (en) Proxy authentication network
JP5651313B2 (ja) 連続する再認証を必要としないsipシグナリング
ES2389250T3 (es) Un método para autenticar un terminal de usuario en un subsistema multimedia IP
US7661131B1 (en) Authentication of tunneled connections
JP5496907B2 (ja) セキュアな通信のための鍵管理
US6938090B2 (en) Authentication and protection for IP application protocols based on 3GPP IMS procedures
KR101013427B1 (ko) 보이스-오버-ip시스템들에 대한 미디어 스트림 암호화키들의 종단 간 보호
US7024688B1 (en) Techniques for performing UMTS (universal mobile telecommunications system) authentication using SIP (session initiation protocol) messages
US9130935B2 (en) System and method for providing access credentials
EP2105819B1 (en) Efficient and secure authentication of computing systems
CA2467353C (en) Key management protocol and authentication system for secure internet protocol rights management architecture
US7882356B2 (en) UPnP authentication and authorization
Hardt The OAuth 2.0 authorization framework
US7313816B2 (en) Method and system for authenticating a user in a web-based environment

Legal Events

Date Code Title Description
RD04 Notification of resignation of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7424

Effective date: 20050613

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20050613

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20081111

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20090212

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20090310

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20090408

R150 Certificate of patent or registration of utility model

Ref document number: 4294268

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

Free format text: JAPANESE INTERMEDIATE CODE: R150

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20120417

Year of fee payment: 3

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20120417

Year of fee payment: 3

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20130417

Year of fee payment: 4

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20130417

Year of fee payment: 4

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20140417

Year of fee payment: 5

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

S111 Request for change of ownership or part of ownership

Free format text: JAPANESE INTERMEDIATE CODE: R313113

R350 Written notification of registration of transfer

Free format text: JAPANESE INTERMEDIATE CODE: R350

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250