JP4294268B2 - クライアント・プロキシ認証のためにセッションイニシエーションプロトコルリクエストメッセージにセキュリティ機構を組み込むための方法およびシステム - Google Patents
クライアント・プロキシ認証のためにセッションイニシエーションプロトコルリクエストメッセージにセキュリティ機構を組み込むための方法およびシステム Download PDFInfo
- 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.)
- Expired - Lifetime
Links
- 238000000034 method Methods 0.000 title claims abstract description 29
- 230000000977 initiatory effect Effects 0.000 title claims abstract description 15
- 230000007246 mechanism Effects 0.000 title abstract description 42
- 230000004044 response Effects 0.000 claims abstract description 53
- 230000007774 longterm Effects 0.000 claims description 11
- 238000013475 authorization Methods 0.000 abstract description 51
- 230000011664 signaling Effects 0.000 abstract description 28
- 239000003795 chemical substances by application Substances 0.000 description 16
- 230000006870 function Effects 0.000 description 12
- 230000008569 process Effects 0.000 description 12
- 238000004891 communication Methods 0.000 description 10
- 238000010586 diagram Methods 0.000 description 10
- 230000003287 optical effect Effects 0.000 description 9
- 239000008186 active pharmaceutical agent Substances 0.000 description 8
- 238000012545 processing Methods 0.000 description 6
- 230000005055 memory storage Effects 0.000 description 4
- 239000000284 extract Substances 0.000 description 3
- 230000006855 networking Effects 0.000 description 3
- 230000008901 benefit Effects 0.000 description 2
- 230000002093 peripheral effect Effects 0.000 description 2
- 230000007704 transition Effects 0.000 description 2
- 241000699670 Mus sp. Species 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 238000012360 testing method Methods 0.000 description 1
- 238000012546 transfer Methods 0.000 description 1
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/12—Applying verification of the received information
- H04L63/123—Applying verification of the received information received data contents, e.g. message integrity
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/0807—Network architectures or network communication protocols for network security for authentication of entities using tickets, e.g. Kerberos
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/20—Network architectures or network communication protocols for network security for managing network security; network security policies in general
- H04L63/205—Network 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
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/1066—Session management
- H04L65/1101—Session protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/1066—Session management
- H04L65/1101—Session protocols
- H04L65/1104—Session initiation protocol [SIP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/0869—Network architectures or network communication protocols for network security for authentication of entities for achieving mutual authentication
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Hardware Design (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Business, Economics & Management (AREA)
- General Business, Economics & Management (AREA)
- Multimedia (AREA)
- Telephonic Communication Services (AREA)
- Communication Control (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は一般に、コンピュータネットワークを介した装置間通信に関し、詳細には、セキュリティ機構、例えばケルベロス認証プロトコルに基づくセキュリティ機構を、セッションイニシエーションプロトコル（ＳＩＰ：Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）を通信セッションを確立するためのシグナリングプロトコルとして使用したネットワーク通信に組み込むことに関する。
【０００２】
【従来の技術】
セッションイニシエーションプロトコル（ＳＩＰ）は、コンピューティング装置が、自体がコンピュータネットワークを介して通信したいと欲している他の装置の位置を突き止め、その装置との間に通信セッションを確立するための機構を提供するシグナリングプロトコルである。ＳＩＰは汎用性のあるプロトコルであり、多くの異なるシナリオで通信セッションを確立するのに使用されてきた。ＳＩＰは例えば、インターネット会議、電話、プレゼンス（ｐｒｅｓｅｎｃｅ）、イベント通知およびインスタントメッセージングに使用されている。ＳＩＰの重要な強みは、位置独立の単一のアドレスの下にいる被呼者（ユーザ）に、たとえこの被呼者が別のコンピュータに移動していたとしてもたどり着くことができる、パーソナルモビリティ（ｐｅｒｓｏｎａｌ ｍｏｂｉｌｉｔｙ）をサポートしていることである。
【０００３】
ＳＩＰに基づくセッション開始オペレーションの共通する１つのモードは「プロキシ（ｐｒｏｘｙ）モード」である。例えば、ＳＩＰクライアント（「呼出し元」）は、意図された受信者（「呼出し先」）を電子メールアドレスに似たアドレスによって識別するＩＮＶＩＴＥメッセージなどのＳＩＰリクエストメッセージを送ることができる。このリクエストメッセージは一般にまず、送信側ＳＩＰクライアントのアウトバウンド（ｏｕｔｂｏｕｎｄ）ＳＩＰプロキシに送られる。次いでこのアウトバウンドＳＩＰプロキシがこのリクエストメッセージを、しばしば他の中間ＳＩＰプロキシを介して、意図された受信側クライアントが登録されているＳＩＰプロキシに転送し、次いでこのＳＩＰプロキシが、ＩＮＶＩＴＥメッセージを受信側クライアントに送る。受信側クライアントの受入れメッセージ（「２００ＯＫ」）が、シグナリングチェーンを介して呼出し元クライアントに戻され、これによって、呼出し元クライアントは呼出し先クライアントと、一般にシグナリングチャネルとは別の媒体チャネルを通して通信できるようになる。他のＳＩＰクライアントと通信する他に、ＳＩＰクライアントはさらに、ＲＥＧＩＳＴＥＲリクエストを送ることによってＳＩＰレジストラ（ｒｅｇｉｓｔｒａｒ）に自体を登録するなどの目的で、ＳＩＰサーバと通信することができる。
【０００４】
【発明が解決しようとする課題】
さまざまな応用に対して幅広く実装されてはいるが、ＳＩＰは、主としてシグナリングオペレーション用に設計されたものである。ＳＩＰは、通信セッションのセキュリティおよびプライバシーを保護するためのセキュリティ機構を明示的に提供せず、またはこれを必要としない。しかし多くのケースで、ＳＩＰクライアントが、ＳＩＰクライアントのユーザを認証するよう求めるリクエストをアウトバウンドＳＩＰプロキシに送ることを要求し、アウトバウンドＳＩＰプロキシが、ＳＩＰクライアントに対して自体を認証することを要求することが望ましい。さらに、ＳＩＰリクエストメッセージの完全性を保護することもしばしば必要である。クライアント・プロキシ認証およびメッセージの完全性はともに、信頼性の高いセキュリティ機構の使用を要求する。したがって、信頼性の高いセキュリティ機構をＳＩＰシグナリングオペレーションと組み合わせて、ＳＩＰクライアントとアウトバウンドプロキシとの間の認証を可能にすることが求められている。しかし、所望のセキュリティ機構をＳＩＰシグナリングフレームワークにどのようにはめ込んで、目的の異なるこれらの２つの機構を一緒に効果的に実行することができるようにするかということが技術上の課題である。
【０００５】
【課題を解決するための手段】
以上のことを考慮して、本発明は、ケルベロス（Ｋｅｒｂｅｒｏｓ）プロトコル、ＮＴＬＭプロトコルなどのセキュリティ機構を、ＳＩＰシグナリングオペレーションのメッセージフローに組み込んで、ＳＩＰクライアントとＳＩＰプロキシが相互に認証できるようにするための方式を提供する。本発明によれば、ＳＩＰクライアントからＳＩＰリクエストメッセージを受け取ると、プロキシはこれに応答して、予め選択されたセキュリティ機構に基づく認証が必要であることを指示するチャレンジメッセージを送る。これに応答してＳＩＰクライアントは、前記セキュリティ機構に基づいてサーバに対してクライアントを認証するための認証データを含むｐｒｏｘｙ ａｕｔｈｏｒｉｚａｔｉｏｎヘッダを有する前記リクエストメッセージの第２バージョンないし改訂バージョンを送る。ケルベロスセキュリティ機構を使用する場合には、ｐｒｏｘｙ ａｕｔｈｏｒｉｚａｔｉｏｎヘッダが、プロキシにアクセスするためにクライアントが取得したケルベロスサーバチケットを表すデータを含む。ｐｒｏｘｙ ａｕｔｈｏｒｉｚａｔｉｏｎヘッダのデータに基づくクライアントのユーザの認証に成功した場合、ＳＩＰプロキシは、ＳＩＰクライアントとリクエストメッセージの意図された受信者との間のＳＩＰメッセージシグナリング経路に沿ってこのリクエストを転送する。ＳＩＰクライアントが相互認証を要求している場合、ＳＩＰプロキシは、クライアントに送る次のメッセージにｐｒｏｘｙ ａｕｔｈｅｎｔｉｃａｔｉｏｎ ｉｎｆｏｒｍａｔｉｏｎ（プロキシ認証情報）ヘッダを追加する。このメッセージは例えば、ＩＮＶＩＴＥリクエストに応答して呼出し先ＳＩＰクライアントが生成した「２００ＯＫ」ＳＩＰ応答、またはＲＥＧＩＳＴＥＲメッセージに応答してＳＩＰレジストラサーバが生成した「２００ＯＫ」応答である。ｐｒｏｘｙ ａｕｔｈｅｎｔｉｃａｔｉｏｎ ｉｎｆｏｒｍａｔｉｏｎヘッダは、クライアントがＳＩＰプロキシを認証するための認証データを含む。
【０００６】
本発明の特徴は請求項に詳細に記述されているが、本発明、ならびに本発明の目的および利点は、添付図面を参照して以下の詳細な説明を読むことによって最もよく理解されよう。
【０００７】
【発明の実施の形態】
図面を参照すると、適当なコンピューティング環境中に実現された本発明が示されている。図面中、同様の参照符号は同様の要素を指す。そうでなければならないというわけではないが、本発明は、パーソナルコンピュータによって実行される、プログラムモジュールなどのコンピュータ実行可能命令の一般的な文脈で説明される。プログラムモジュールには一般に、特定のタスクを実行し、または特定の抽象データ型を実装するルーチン、プログラム、オブジェクト、コンポーネント、データ構造などが含まれる。さらに、本発明を、ハンドヘルド装置、マルチプロセッサシステム、マイクロプロセッサベースの、またはプログラム可能な家庭用電子機器、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータなどを含む他のコンピュータシステム構成とともに実施できることを当業者は理解されたい。本発明は、通信ネットワークを介してリンクされた遠隔処理装置によってタスクが実行される分散コンピューティング環境で実施することができる。分散コンピューティング環境では、プログラムモジュールが、ローカルメモリ記憶装置と遠隔メモリ記憶装置の両方に位置することができる。
【０００８】
以下の説明ではまず、本発明を実現するための例示的なシステム中で使用することができる汎用コンピューティング装置を説明し、次いで、図２〜９を参照して本発明をより詳細に説明する。図１を参照すると、処理ユニット２１、システムメモリ２２およびシステムバス２３を含む従来のパーソナルコンピュータ２０の形態の汎用コンピューティング装置が示されている。システムバス２３は、システムメモリを含むさまざまなシステムコンポーネントを処理ユニット２１に結合する。システムバス２３は、さまざまなバスアーキテクチャのうちの任意のアーキテクチャを使用した、メモリバスまたはメモリコントローラ、周辺バスおよびローカルバスを含むいくつかのタイプのバス構造のうちの任意の構造とすることができる。システムメモリは、リードオンリーメモリ（ＲＯＭ）２４およびランダムアクセスメモリ（ＲＡＭ）２５を含む。ＲＯＭ２４には、起動時などにパーソナルコンピュータ２０の内部要素間の情報転送を助ける基本ルーチンを含む基本入出力システム（ＢＩＯＳ）２６が記憶されている。パーソナルコンピュータ２０はさらに、ハードディスク６０の読取り／書込み用のハードディスクドライブ２７、リムーバブル磁気ディスク２９の読取り／書込み用の磁気ディスクドライブ２８、およびＣＤ−ＲＯＭまたは他の光媒体などのリムーバブル光ディスク３１の読取り／書込み用の光ディスクドライブ３０を含む。
【０００９】
ハードディスクドライブ２７、磁気ディスクドライブ２８および光ディスクドライブ３０はそれぞれ、ハードディスクドライブインタフェース３２、磁気ディスクドライブインタフェース３３、および光ディスクドライブインタフェース３４によってシステムバス２３に接続されている。これらのドライブおよび関連コンピュータ可読媒体は、コンピュータ可読命令、データ構造、プログラムモジュール、およびパーソナルコンピュータ２０のためのその他のデータを記憶する不揮発性記憶装置を提供する。ここに記載した例示的な環境では、ハードディスク６０、リムーバブル磁気ディスク２９およびリムーバブル光ディスク３１が使用されているが、この例示的な動作環境では、磁気カセット、フラッシュメモリカード、ディジタルビデオディスク、ベルヌーイカートリッジ、ランダムアクセスメモリ、リードオンリーメモリ、ストレージエリアネットワークなど、コンピュータがアクセス可能なデータを記憶することができる他のタイプのコンピュータ可読媒体を使用することもできることを当業者は理解されたい。
【００１０】
ハードディスク６０、磁気ディスク２９、光ディスク３１、ＲＯＭ２４またはＲＡＭ２５には、オペレーティングシステム３５、１つまたは複数のアプリケーションプログラム３６、他のプログラムモジュール３７およびプログラムデータ３８を含む、いくつかのプログラムモジュールを記憶することができる。ユーザは、キーボード４０、ポインティングデバイス４２などの入力装置を介して、コマンドおよび情報をパーソナルコンピュータ２０に入力することができる。この他の入力装置（図示せず）には例えば、マイクロホン、ジョイスティック、ゲームパッド、衛星アンテナ、スキャナなどがある。これらの入力装置および他の入力装置はたいてい、システムバスに結合されたシリアルポートインタフェース４６を介して処理ユニット２１に接続されるが、パラレルポート、ゲームポート、ユニバーサルシリアルバス（ＵＳＢ）、ネットワークインタフェースカードなどの他のインタフェースによって接続することもできる。さらに、モニタ４７または他のタイプのディスプレイ装置が、ビデオアダプタ４８などのインタフェースを介してシステムバス２３に接続されている。モニタの他に、パーソナルコンピュータは一般に、スピーカ、プリンタなどの周辺出力装置（図示せず）を含む。
【００１１】
パーソナルコンピュータ２０は、リモートコンピュータ４９などの１台または数台のリモートコンピュータへの論理接続を使用したネットワーク化された環境で動作することができる。リモートコンピュータ４９は、別のパーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ピア装置または他の普通のネットワークノードとすることができる。図１にはメモリ記憶装置５０だけしか示されていないが、リモートコンピュータ４９は一般に、パーソナルコンピュータ２０に関して先に説明した全ての要素または多くの要素を含む。図１に示した論理接続は、ローカルエリアネットワーク（ＬＡＮ）５１およびワイドエリアネットワーク（ＷＡＮ）５２を含む。このようなネットワーキング環境は、事業所、企業内コンピュータネットワーク、イントラネットおよびインターネットでごく普通に見られるものである。
【００１２】
ＬＡＮネットワーキング環境で使用するとき、パーソナルコンピュータ２０は、ネットワークインタフェースまたはアダプタ５３を介してローカルネットワーク５１に接続される。ＷＡＮネットワーキング環境で使用するとき、パーソナルコンピュータ２０は一般にモデム５４、またはＷＡＮ５２を介した通信を確立するためのその他の手段を含む。モデム５４は、内部モデムでもまたは外部モデムでもよく、シリアルポートインタフェース４６を介してシステムバス２３に接続される。ネットワーク化された環境では、パーソナルコンピュータ２０に関して図示したプログラムモジュール、またはその一部分を、遠隔メモリ記憶装置に記憶することができる。示されたネットワーク接続は例示的なものであり、コンピュータ間に通信リンクを確立する他の手段を使用することができることを理解されたい。
【００１３】
特に指示しない限り以下の説明では、１台または数台のコンピュータによって実行されるアクト（ａｃｔ）およびオペレーションの記号的表現を参照して、本発明を説明する。時にコンピュータ実行アクトまたはオペレーションと呼ばれるこのようなアクトおよびオペレーションは、コンピュータの処理ユニットによる、構造化された形態のデータを表す電気信号の操作を含むことを理解されたい。この操作では、データを変換し、またはコンピュータのメモリシステム中の位置にデータを維持する。これによって、コンピュータのオペレーションは当業者によってよく理解されている方法で再構成され、または別な方法で変更される。データが維持されるデータ構造は、データのフォーマットによって定義された特定の特性を有するメモリの物理的位置である。しかし、本発明は以上の文脈で説明されるが、これは限定を意味しない。当業者なら分かるとおり、以降に説明するさまざまなアクトおよびオペレーションはハードウェアとして実装することもできるからである。
【００１４】
次に図２を参照する。本発明は、セキュリティ機構、特にケルベロス認証プロトコルを実装したセキュリティ機構を、セッションイニシエーションプロトコル（ＳＩＰ）に基づくリクエストメッセージに組み込んで、ＳＩＰクライアント７２とＳＩＰプロキシサーバ７４が相互に認証することができるようにし、かつシグナリングメッセージの完全性を保護するための方法を対象とする。ＳＩＰは、ＲＦＣ（Ｒｅｑｕｅｓｔ ｆｏｒ Ｃｏｍｍｅｎｔｓ）２５４３に定義されている。この文書は、その全体が参照によって本明細書に組み込まれる。
【００１５】
例えば、一般的なセッション開始オペレーションでは図２に示すように、別のユーザ８０（例えば「ボブ（Ｂｏｂ）」）と話しをしたいＳＩＰクライアント７２（「呼出し元」）のユーザ７６（例えば「アン（Ａｎｎ）」）は、ボブがＩＮＶＩＴＥメッセージ８２の意図された受信者であることを確認するＩＮＶＩＴＥメッセージを送る。このＩＮＶＩＴＥメッセージは、呼出し元ＳＩＰクライアントのドメインに対応するアウトバウンドプロキシサーバ７４に送られる。図２に示すようにＩＮＶＩＴＥメッセージは、このシグナリングオペレーションに関与する複数のＳＩＰプロキシを介して送られ、その後、ボブのコンピュータ８８のＳＩＰクライアント８６（呼出し先）に到達する。好ましい実施形態では、シグナリング経路上のＳＩＰプロキシ間で転送中のＳＩＰシグナリングメッセージのセキュリティが、ＩＰｓｅｃプロトコルの下で、またはＳＳＬ（ＳｅｃｕｒｅｄＳｏｃｋｅｔｓ Ｌａｙｅｒ）プロトコルの下でパイプを通してメッセージを送ることによって保護される。この例ではＳＩＰリクエストがＩＮＶＩＴＥリクエストだが、以下で説明する認証方式は、ＲＥＧＩＳＴＥＲ、ＭＥＳＳＡＧＥ、ＳＵＢＳＣＲＩＢＥ、ＳＥＲＶＩＣＥなどの他のタイプのＳＩＰリクエストに対しても使用することができることを理解されたい。
【００１６】
シグナリングオペレーションのセキュリティおよびシグナリングメッセージの完全性を確保するため、アウトバウンドＳＩＰプロキシサーバ７４は、シグナリング経路９０を介してＩＮＶＩＴＥメッセージ８２を転送する前に、呼出し元ＳＩＰクライアント７２のユーザ７６の認証を求めることができる。次に図３を参照する。本発明によればプロキシサーバ７４はＩＮＶＩＴＥメッセージに応答して、ＳＩＰクライアント７２にチャレンジメッセージ９６を送る。チャレンジメッセージ９６は、まず最初にクライアント７２がそのユーザをプロキシ７４に対して認証しなければならないことを指示する、ＳＩＰ仕様に定義されたステータスコード「４０７ Ｐｒｏｘｙ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｒｅｑｕｉｒｅｄ（４０７プロキシ認証が必要）」を含む。ＳＩＰ仕様によれば、チャレンジメッセージ９６（以後「４０７メッセージ」と呼ぶ）は、認証のためにクライアントが使用しなければならないセキュリティ機構を指示するデータを含む「Ｐｒｏｘｙ−Ａｕｔｈｅｎｔｉｃａｔｅ」ヘッダフィールド９８を含む。Ｐｒｏｘｙ−Ａｕｔｈｅｎｔｉｃａｔｅヘッダの構文および内容ヘッダについては後に詳細に説明する。好ましい実施形態では、ケルベロスが好ましいセキュリティ機構だが、ＳＩＰフレームワークでは、ＮＴＬＭプロトコルに基づくセキュリティ機構の使用も可能である。以下の説明では、特に指示しない限り、ケルベロスプロトコルに基づくセキュリティ機構を使用するものとする。
【００１７】
さらに図３を参照する。ＩＮＶＩＴＥメッセージ８２に応答したプロキシサーバ７４から４０７メッセージ９６を受け取ると、Ｐｒｏｘｙ−Ａｕｔｈｅｎｔｉｃａｔｅヘッダ９８からＳＩＰクライアント７２は、ケルベロス機構を使用したユーザの認証をプロキシサーバが求めていると判断する。サーバチケットをまだ取得していない場合、クライアント７２は次いで、ＳＩＰプロキシサーバ７４のケルベロス・キー・ディストリビューション（配布）・センター（ＫＤＣ：Ｋｅｙ Ｄｉｓｔｒｉｂｕｔｉｏｎ Ｃｅｎｔｅｒ）１００からサーバチケット１０８を取得する。一実施態様では、ＫＤＣ１００が、プロキシサーバ７４のドメインコントローラ１０２の一部である。サーバチケット１０８を取得した後、クライアント７２は別のＩＮＶＩＴＥメッセージ１１０を送る。ただしこのときには、ＩＮＶＩＴＥメッセージ１１０が、ＳＩＰ仕様に基づくＰｒｏｘｙ−Ａｕｔｈｏｒｉｚａｔｉｏｎ（プロキシ許可）ヘッダフィールド１１２を含んでいる。Ｐｒｏｘｙ−Ａｕｔｈｏｒｉｚａｔｉｏｎヘッダフィールド１１２は、プロキシサーバにアクセスするためのサーバチケット１０８を含む。サーバチケット１０８は、使用するセッションキー１１６を含んでいる。Ｐｒｏｘｙ−Ａｕｔｈｏｒｉｚａｔｉｏｎヘッダフィールドの構文および内容については後に詳細に説明する。任意選択で、Ｐｒｏｘｙ−Ａｕｔｈｏｒｉｚａｔｉｏｎヘッダにさらに、クライアント７２に対して自体を認証するようプロキシサーバ７４に求める、相互認証のためのリクエストを含めることもできる。
【００１８】
ＳＩＰプロキシサーバ７４は、ケルベロスサーバチケットが埋め込まれた再送ＩＮＶＩＴＥメッセージ１１０を受け取ると、サーバチケットを抜き出し、チケットの有効性を、ＫＤＣ１００と共有しているその長期キーでチケットを解読することによって検証する。チケットが有効である場合、ユーザ７６は認証され、ＳＩＰプロキシサーバ７４は、シグナリング経路上の次のプロキシ１２０にＩＮＶＩＴＥメッセージ１１０を転送する。クライアント７２が、ＩＮＶＩＴＥメッセージ１１０のＰｒｏｘｙ−Ａｕｔｈｏｒｉｚａｔｉｏｎヘッダ１１２の中で相互認証を要求してきた場合、プロキシサーバ７４は、ケルベロスサーバチケットに関連付けられたセッションキーを使用して、自体からクライアントへの将来のパケットに署名する。このメッセージは、クライアント７２がプロキシ７４を認証することを可能にするプロキシ７４の証明書（ｃｒｅｄｅｎｔｉａｌ）を含むＰｒｏｘｙ−Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｉｎｆｏｒｍａｔｉｏｎヘッダ１２４を含む。
【００１９】
最終的に、ＩＮＶＩＴＥメッセージ１１０は呼出し先、すなわちボブのコンピュータ８８のＳＩＰクライアント８６に届く。この呼勧誘を受け入れる場合、呼出し先は「２００ ＯＫ」メッセージ１２６を返し、このメッセージは呼出し元へ送られる。呼接続が確立されると、呼出し元は、このシグナリング段階に関与したＳＩＰプロキシを通すことなく、呼出し先と直接に通信することができる。
【００２０】
次に図４を参照する。本発明によれば、ＳＩＰクライアント７２とＳＩＰプロキシサーバ７４の間で認証セキュリティアソシエーション（ＳＡ：ｓｅｃｕｒｉｔｙ ａｓｓｏｃｉａｔｉｏｎ）を確立するオペレーションは、状態機械１２８として見ることができる。図４に示す実施形態では、好ましいセキュリティ機構がケルベロスであるが、任意選択でＮＴＬＭセキュリティ機構も使用することができ、この状態機械図は、この任意選択の包含を反映したものになっている。
【００２１】
図４では、状態が円の中に、状態に関連して実行されるオペレーションが長方形のブロックの中に示されている。図４に示すように、状態機械の１つの状態が、セキュリティＳＡが確立されていない「ＳＥＣＵＲＩＴＹ＿ＳＴＡＴＥ＿ＮＯＮＥ」状態１３２である。クライアント７２が送ったＩＮＶＩＴＥメッセージに応答したプロキシ７４から４０７チャレンジメッセージを受け取り、またはプロキシとプレ認証（ｐｒｅ−ａｕｔｈｅｎｔｉｃａｔｉｏｎ）を実行すると決定すると、クライアント７２は「ＳＥＣＵＲＩＴＹ＿ＳＴＡＴＥ＿ＡＣＱＵＩＲＩＮＧ＿ＳＡ」状態１３６に入り、認証に必要なセキュリティアソシエーションデータを獲得する。認証に必要なセキュリティアソシエーションデータは、選択したセキュリティ機構によって異なる。
【００２２】
セキュリティアソシエーションは一般に、クライアントとＳＩＰプロキシが共有の秘密を安全な方法で交換し、この秘密を使用して認証し、クライアントとプロキシによって交換される以降のメッセージの完全性を保護することができる状態と定義される。セキュリティ機構がケルベロスである場合、セキュリティアソシエーションは、プロキシに対するケルベロスサーバチケットおよびセッションキーを含む。ケルベロスの場合、取得されたＳＡは完全である。すなわち、これを使用して、ＳＩＰクライアントのユーザをプロキシが十分に認証することができる。クライアントは次いで、このＳＡ関連情報（例えばサーバの秘密を用いて暗号化されたケルベロスセッションキー）をプロキシに送る（段階１３８）。プロキシが、署名された２００ＯＫメッセージを返した場合（段階１４０）、認証は成功であり、セキュリティアソシエーションは確立されている。すなわちクライアントはＳＡ＿Ｅｓｔａｂｌｉｓｈｅｄ状態１４２にある。しかし、プロキシが代わりに４０７チャレンジメッセージを返した場合（段階１４６）、クライアントは、プロキシが不良な状態にあり、そのためクライアントの正当な証明書を検証することができないでいるとみなす。次いでクライアントは「バックオフ」時間（例えば５分）のあいだ待機し（段階１４８）、その後再びＳＩＰメッセージを送る。
【００２３】
ＳＡ＿Ｅｓｔａｂｌｉｓｈｅｄ状態１４２に入った後は、セキュリティアソシエーションが期限切れにならない限り、クライアントは再び認証を実行することなくプロキシに別のメッセージを送ることができる。しかしプロキシが４０７チャレンジメッセージを送った場合（段階１５０）、クライアントは、確立されたセキュリティアソシエーションをプロキシが何かの理由で取り下げたとみなす。その結果、クライアントは、ＳＡ＿Ｄｒｏｐｐｅｄ状態１５６に入り、ＳＥＣＵＲＩＴＹ＿ＳＴＡＴＥ＿ＡＣＱＵＩＲＩＮＧ＿ＳＡ状態１３６へ移って、プロキシとの認証を再び実施するための新しいＳＡを獲得する。
【００２４】
先に述べたとおり、ユーザの認証に対して任意選択でＮＴＬＭ機構を選択することができる。ＮＴＬＭの状態移行はケルベロスの状態移行と概ね同じだが、ＮＴＬＭは、始めに不完全なＳＡだけを獲得し（段階１５８）、不完全なＳＡを第１のメッセージに入れてプロキシに送るという違いがある。具体的には、ＮＴＬＭの場合、ＳＡ関連情報を含むクライアントからの第１のリクエストは、クライアントのセキュリティ関連機能（例えばクライアントがサポートするプロトコルのバージョン、サポートする署名アルゴリズムなど）を伝える。これに応答してプロキシサーバは、そのＮＴＬＭ関連機能および一般に「ｎｏｎｃｅ」と呼ばれるランダムなバイト列を含む自体の認証データを含んだ第２の４０７チャレンジを送る（段階１６０）。これに応答してクライアントは、それ自体の名称およびプロキシによって送られた「ｎｏｎｃｅ」値のハッシュにその証明書を使用して署名する。これは、ＮＴＬＭインプリメンテーションによって内部的に処理される。プロキシサーバは、クライアントの認証データを検証し、ドメインコントローラの助けを借りてセッションキーを得る。ＳＩＰプロキシが意図された受信者でない場合、プロキシは、シグナリング経路上の次のホップにＳＩＰリクエストを転送し、送信側ＳＩＰクライアントへの次のメッセージ（例えば受信者からの２００ＯＫメッセージ）に署名する（段階１４０）。
【００２５】
ＳＩＰクライアントとＳＩＰプロキシの間の認証目的のメッセージ交換に関与するさまざまなＳＩＰヘッダの構文については後に説明する。
【００２６】
（４０７応答）
先に述べたとおり、ＩＮＶＩＴＥメッセージを送ったＳＩＰクライアント（またはそのユーザ）の識別を要求したい場合、ＳＩＰプロキシサーバ７４は、Ｐｒｏｘｙ−Ａｕｔｈｅｎｔｉｃａｔｅヘッダを含む４０７メッセージをクライアントに送る。認証のためにケルベロスセキュリティ機構の使用を必要とする好ましい実施形態のＰｒｏｘｙ−Ａｕｔｈｅｎｔｉｃａｔｅヘッダの構文は以下のとおりである。
【００２７】
【００２８】
ここに記載したＰｒｏｘｙ−Ａｕｔｈｅｎｔｉｃａｔｅヘッダの構文は、「ＨＴＴＰ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ：Ｂａｓｉｃ ａｎｄ Ｄｉｇｅｓｔ Ａｃｃｅｓｓ Ａｕｔｈｅｎｔｉｃａｔｏｎ」という表題のＩＥＴＦ ＲＦＣ ２６１７に定義されている「ＷＷＷ−Ａｕｔｈｅｎｔｉｃａｔｅ Ｒｅｓｐｏｎｓｅ Ｈｅａｄｅｒ」と同様である。この文書はその全体が参照によって本明細書に組み込まれる。任意選択のパラメータ「ａｌｇｏｒｉｔｈｍ」および「ｓｔａｌｅ」は省かれている。ヘッダの「ｓｃｈｅｍｅ」フィールドは、サーバに対して自体を認証するのに、サーバによって提案された認証機構のうちどの認証機構を使用したいかをクライアントが選択することを可能にする。クライアントがケルベロス機構をサポートしている場合には、クライアントはケルベロス機構を選択することが好ましく、サポートしていない場合にはＮＴＬＭ認証機構を選択する。
【００２９】
ｒｅａｌｍパラメータは、ＳＩＰプロキシが属し、クライアントがアクセスしようとしているＳＩＰサービスプロバイダの固有の識別子である。認証のためにユーザが提供する必要がある正しい証明書セットをユーザが識別するのを助けるため、ｒｅａｌｍ列はユーザに表示される。「ｔａｒｇｅｔｎａｍｅ」パラメータは常に必要なパラメータであり、ＳＩＰプロキシのＦＱＤＮを伝達するのに使用される。このパラメータの実際の内容は、クライアントがＳＡを確立しているプロキシを追跡するのを助ける。それは、応答が自体に対するものなのか、または他のプロキシに対するものなのかをプロキシが判定するのを助ける。「ｏｐａｑｕｅ」パラメータは、サーバが、確立されている特定のＳＡに索引をつけるのに使用され、後に説明するように、クライアントがＳＡに対して生成する将来のＰｒｏｘｙ−Ａｕｔｈｏｒｉｚａｔｉｏｎヘッダ中に反映されなければならない。
【００３０】
この実施形態では、ＩＥＴＦ ＲＦＣ２０７８（その全体が参照によって本明細書に組み込まれる）に定義されたＧＳＳ−ＡＰＩ（Ｇｅｎｅｒｉｃ Ｓｅｃｕｒｉｔｙ Ｓｅｒｖｉｃｅ Ａｐｐｌｉｃａｔｉｏｎ ＰｒｏｇｒａｍｍｉｎｇＩｎｔｅｒｆａｃｅ）が実装されており、通信しているアプリケーション間でメッセージを安全に交換するのに使用されるとみなす。ＧＳＳ−ＡＰＩは特に、通信アプリケーションが、別のアプリケーションに関連付けられたユーザを認証することを可能にする。Ｐｒｏｘｙ−Ａｕｔｈｅｎｔｉｃａｔｅヘッダおよび後述するＰｒｏｘｙ−Ａｕｔｈｏｒｉｚａｔｉｏｎヘッダのｇｓｓａｐｉ−ｄａｔａフィールドは、ＮＴＬＭおよびケルベロスセキュリティパッケージを実装したセキュリティＡＰＩによって、ＳＡネゴシエーション段階の間に返されたデータを保持するためのものである。これらのＡＰＩは、クライアントからプロキシへ、およびプロキシからクライアントへ送る必要があるｇｓｓａｐｉデータを返す。ｇｓｓａｐｉデータは、ＳＩＰクライアント／プロキシインプリメンテーションにとって不透明であり、セキュリティＡＰＩだけが解釈することができる。ｑｏｐパラメータは、クライアントが従って欲しいとサーバが欲しているセキュリティのレベルをクライアントに教える。ｑｏｐパラメータ値は常に、この機構によって提供されるセキュリティレベルがユーザの認証であることを指示する「ａｕｔｈ」にセットされている。
【００３１】
Ｐｒｏｘｙ−Ａｕｔｈｅｎｔｉｃａｔｅヘッダフィールドの一例を以下に示す。
【００３２】
Proxy-Authenticate: Negotiate
realm = "Microsoft RTC Service provider",
opaque = "ABCDEF456789"
qop = "auth",
gssapi-data = "ABCD345678yuikjhlbcdfsaqwety"
【００３３】
許可されたクライアントだけを許すとされ、クライアントから着信するＳＩＰパケットが署名を含まない場合には一般に、ＳＩＰプロキシは、ＳＩＰクライアントの識別を要求するであろう。（リブートなどのため）ＳＩＰプロキシがこのＳＩＰ ＵＲＩに対するセキュリティアソシエーションを失った場合にも、ＳＩＰプロキシはクライアントの認証を要求するであろう。クライアントが使用している許可パラメータとＳＩＰプロキシが期待しているものの間にミスマッチがある場合、ＳＩＰプロキシは、クライアントが従って欲しいとＳＩＰプロキシが欲している正確な許可パラメータを運んでいる４０７メッセージを使用して、クライアントの認証を要求するであろう。
【００３４】
（４０７チャレンジに対するクライアントの応答）
４０７チャレンジに応答してＳＩＰクライアントは、４０７チャレンジメッセージを介してＳＩＰプロキシから送られた認証パラメータに従った署名を生成しようとする。ＳＩＰクライアントはＣｓｅｑ値を増分し、チャレンジの対象となった最初のＳＩＰリクエストを、Ｐｒｏｘｙ−Ａｕｔｈｏｒｉｚａｔｉｏｎリクエストヘッダの中に入れられた許可情報とともに再送する。好ましい実施形態におけるＰｒｏｘｙ−Ａｕｔｈｏｒｉｚａｔｉｏｎリクエストヘッダの構文は以下のとおりである。
【００３５】
【００３６】
ここに記載したＰｒｏｘｙ−Ａｕｔｈｏｒｉｚａｔｉｏｎヘッダの構文は、ＩＥＴＦ ＲＦＣ ２６１７に定義されている「Ａｕｔｈｏｒｉｚａｔｉｏｎ Ｒｅｑｕｅｓｔ Ｈｅａｄｅｒ」と同様である。ただし、任意選択のパラメータ「ａｌｇｏｒｉｔｈｍ」および「ＵＲＩ」は省かれている。Ｐｒｏｘｙ−Ａｕｔｈｏｒｉｚａｔｉｏｎヘッダは、リクエストＵＲＩおよびＶｉａヘッダの後に追加される。署名は、セッションキーを使用して、以下のフィールドにわたって計算される。
【００３７】
−ＦｒｏｍヘッダＵＲＩ
−ＴｏヘッダＵＲＩ
−Ｆｒｏｍヘッダタグ
−Ｔｏヘッダタグ
−Ｐｒｏｘｙ−Ａｕｔｈｏｒｉｚａｔｉｏｎヘッダ中の「ｃｒａｎｄ」パラメータ、またはＰｒｏｘｙ−Ａｕｔｈｅｎｔｉｃａｔｉｏｎ−Ｉｎｆｏヘッダ中の「ｓｒａｎｄ」パラメータ
−ＳＩＰメッセージＥｘｐｉｒｅｓヘッダ中のＥｘｐｉｒｅｓ値
署名には、ＳＩＰメッセージのメッセージ本体は含まれていない。ｐｒｏｘｙ−ａｕｔｈｏｒｉｚａｔｉｏｎヘッダは、ｇａｓａｐｉ−ｄａｔａパラメータまたはｒｅｓｐｏｎｓｅ（署名）パラメータを含む。
【００３８】
以下に、４０７チャレンジに対するクライアントの応答におけるＰｒｏｘｙ−Ａｕｔｈｏｒｉｚａｔｉｏｎヘッダの例を示す。
【００３９】
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"
【００４０】
プロキシからの４０７チャレンジに応答するときの他に、クライアントは、自体を初めてＳＩＰプロキシに登録するときにもこのヘッダを送る。ＳＩＰクライアントが自体をプロキシサーバに登録し、セッションのためにセキュリティアソシエーションを初期化するプロセスにあるとき、Ｐｒｏｘｙ−Ａｕｔｈｏｒｉｚａｔｉｏｎヘッダは、「ｇｓｓａｐｉ−ｄａｔａ」パラメータを含む。
【００４１】
（相互認証）
ある種のシナリオでは、ＳＩＰプロキシとＳＩＰクライアントの間で相互認証を確立することが必要である。クライアントは、特定のプロキシサーバに対してクライアントが有する準備プロファイルから、相互認証が必要か否かを判断する。相互認証が使用可能な場合、クライアントは、ＧＳＳ ＡＰＩの標準バージョンを使用して相互認証のためのセキュリティアソシエーションを初期化する。相互認証が使用可能な場合にはさらに、サーバが、ＳＩＰクライアントに送る全てのパケットに署名する必要がある。この署名は、Ｐｒｏｘｙ−Ａｕｔｈｅｎｔｉｃａｔｉｏｎ−Ｉｎｆｏｒｍａｔｉｏｎリクエストヘッダに入れて運ばれる。Ｐｒｏｘｙ−Ａｕｔｈｅｎｔｉｃａｔｅ−Ｉｎｆｏｒｍａｔｉｏｎの構文は以下のとおりである。
【００４２】
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
【００４３】
Ｐｒｏｘｙ−Ａｕｔｈｅｎｔｉｃａｔｉｏｎ−Ｉｎｆｏヘッダ中の「ｒｓｐａｕｔｈ」パラメータは、この応答に対する（認証を求めているプロキシの）署名を運ぶ。「ｓｒａｎｄ」パラメータは、ＳＡ確立段階後にサーバが、クライアントに送るメッセージに署名するのに使用される。このパラメータは、サーバによって生成されるランダムな文字列であり、生成されたメッセージのハッシュ／署名にランダム性の要素を導入するのに使用される。
【００４４】
以下に、Ｐｒｏｘｙ−Ａｕｔｈｅｎｔｉｃａｔｉｏｎ−Ｉｎｆｏｒｍａｔｉｏｎヘッダの一例を示す。
【００４５】
Proxy-Authentication-Info: Negotiate
realm = "Microsoft RTC Service Provider",
qop = "auth",
rspauth = "ABCD87564cvx",
srand = "9876543210",
targetuame = "serverl.domainA.microsoft.com"
【００４６】
ＳＩＰフレームワークでは一般に、ＲＥＧＩＳＴＥＲリクエストを使用した登録プロセスの間に、ＳＩＰクライアントが、ＳＩＰプロキシとのセキュリティアソシエーションを確立することができる。登録によってＳＩＰクライアントは、ＳＩＰプロキシからメッセージを受け取ることができるようになる。ＳＩＰクライアントが自体をＳＩＰプロキシに登録するときには、ＳＩＰクライアントは同時に、ケルベロスチケットなどの認証データをＲＥＧＩＳＴＥＲメッセージに入れて送ることによって、自体のユーザをＳＩＰプロキシサーバに対して認証することができる。ＳＩＰクライアントがＳＩＰプロキシにすでに登録されており、かつＳＩＰプロキシに対して認証されている場合、ＩＮＶＩＴＥなどのＳＩＰリクエストをクライアントが送るときには、クライアントからのリクエストメッセージが、ＳＡ確立プロセスの間に交換されたケルベロスセッションキーを使用して署名される。
【００４７】
とは言え、自体をサーバに登録しなくても、ＳＩＰクライアントはリクエストメッセージをＳＩＰプロキシに送ることができる。呼出し元がプロキシに対して認証されていない場合には（たとえＳＩＰクライアントがプロキシに登録されている場合であっても）、ＳＩＰプロキシはそのリクエストを次のホップに転送しない。その代わりにプロキシは、ＳＩＰクライアントにチャレンジを送る。
【００４８】
このチャレンジは、クライアントがこのＳＩＰサーバと、セキュリティアソシエーションを確立する必要があることを指示する。クライアントは、セキュリティアソシエーションデータを含むリクエストを再び送ることによってＳＡを確立することができ、あるいは、登録はすでにされているが、ＳＡがまだ確立されていない場合には、このサーバへの自体の登録をリフレッシュすることによってＳＡを確立することができる。登録リフレッシュを使用してＳＡを確立し、次いで有効な署名を有するＳＩＰリクエストを送ることには、登録が良好な状態にあることが保証されるという利点がある。
【００４９】
さらに、ＳＩＰクライアントがＳＩＰプロキシに対する登録を抹消するたびに、ＳＩＰクライアントとＳＩＰプロキシの間のセキュリティアソシエーション（ＳＡ）は失われ、新しいセキュリティアソシエーションを再び交渉し直さなければならない。さらに、ＳＩＰクライアントの登録が失効すると、プロキシサーバは、対応するセキュリティコンテキストをＳＡのリストから削除する。登録をリフレッシュするたびに、ＳＩＰクライアントは、認証セキュリティアソシエーションもリフレッシュしなければならない。
【００５０】
ケルベロスプロトコルに基づくセキュリティ機構を使用する好ましい実施形態では、送信側ＳＩＰクライアントのユーザの認証がＳＩＰプロキシ／レジストラによって要求された場合に、ＳＩＰクライアントがＳＩＰプロキシに登録するたびに、ケルベロスキーディストリビューションセンター（ＫＤＣ）からのケルベロスチケットが要求される。ケルベロスチケットを受け取ると、ＳＩＰクライアントはこのチケットを解読する。解読されたチケットは、セッションキーおよびこのケルベロスセッションの他のいくつかの特性を含む。このチケットはさらに、サーバの証明書で暗号化されたセッションキーおよび他のセッション関連パラメータを含む。この部分は、ｇｓｓａｐｉ−ｄａｔａフィールドの、ｐＯｕｔｐｕｔパラメータに入れて返され、ｒｅ−ＩＮＶＩＴＥリクエストに入れてプロキシに送られる。
【００５１】
ＳＩＰフレームワーク内でのセキュリティ機構のオペレーションの明瞭な理解を容易にするため、クライアント・プロキシのケルベロス認証の具体的な例を図２を参照して説明する。この例では、ＳＩＰプロキシサーバ７４が、ドメイン「ｄｏｍａｉｎＡ．Ｍｉｃｒｏｓｏｆｔ．ｃｏｍ：Ｓ＿ｓｅｒｖｅｒ１」のＫＤＣ１７０との共有秘密鍵をすでに生成していると仮定する。この例では「ｓｅｒｖｅｒ１」が、ＳＩＰプロキシ／レジストラのコード名として使用される。ＫＤＣ１７０は、プロキシサーバ７４がｓｅｒｖｅｒ＿ＩＤ＝ｓｅｒｖｅｒ１．ｄｏｍａｉｎＢ．ｍｉｃｒｏｓｏｆｔ．ｃｏｍであると知っている。プロキシサーバ７４はさらに、証明書ハンドルを獲得して、クライアントから来る認証リクエストに応答する準備を整える。サーバ証明書は、サーバ認証または相互認証をサポートしているセキュリティプロトコルにおいてＳＩＰクライアント７４に対してプロキシサーバ７４を認証するのに使用される。プロキシサーバ７４は、このサーバを起動するのに使用されるサービスアカウントによって定義されるその証明書に対するハンドルを取得する。サーバはこのハンドルを、ＳＳＰＩ（Ｓｅｃｕｒｉｔｙ Ｓｕｐｐｏｒｔ Ｐｒｏｖｉｄｅｒ Ｉｎｔｅｒｆａｃｅ）の関数ＡｃｑｕｉｒｅＣｒｅｄｅｎｔｉａｌｓＨａｎｄｌｅを呼び出すことによって取得する。
【００５２】
図２の例では、ＳＩＰクライアント７２のユーザ７６がアンである。アンは、ＮＴドメインにアカウントを有し、一日の始まりに、以下の情報を使用して自分のアカウントにログオンする。
【００５３】
UserID / principal name = ann@microsoft.com
Preferred_email = ann@microsoft.com
User_domain = domainA.Microsoft.com
Workstation = ann1.domainA.Microsoft.com
【００５４】
ボブと通話したいとき、アンは、自分のワークステーション７８上のＳＩＰクライアント７２を起動する（ＳＩＰクライアントはサービスとして自動的に起動することができる。ただしユーザのセキュリティコンテキストで走らなければならない）。ＳＩＰクライアント７２は、ＤＮＳを使用してアウトバウンドプロキシサーバ７４を見つける。この例で使用するアウトバウンドプロキシサーバ７４は、Ｓｅｒｖｅｒ１．ｄｏｍａｉｎＢ．Ｍｉｃｒｏｓｏｆｔ．ｃｏｍとして識別される。アンは、自分がｂｏｂ＠ｍｉｃｒｏｓｏｆｔ．ｃｏｍと通話したいことを指示する。アンのＳＩＰクライアント７２は次いで、Ｓｅｒｖｅｒ１．ｄｏｍａｉｎＢ．Ｍｉｃｒｏｓｏｆｔ．ｃｏｍにＩＮＶＩＴＥメッセージ８２を送る。ＩＮＶＩＴＥメッセージは以下の情報を含む。
【００５５】
INVITE bob@microsoft.com
From: ann@microsoft.com
To: bob@microsoft.com
【００５６】
この例の説明を簡潔かつ明瞭に保つため、このＩＮＶＩＴＥメッセージまたはシグナリング処理で交換される他のメッセージに含まれる全てのデータを示すわけではない。ＳＩＰプロキシサーバ７４は、Ｍｉｃｒｏｓｏｆｔ．ｃｏｍのユーザ名空間に対してなされた呼に対する全てのＩＮＶＩＴＥリクエストが認証されることを必要とするように構成されている。その結果、ＳＩＰプロキシサーバ７４はＩＮＶＩＴＥリクエストに応答して、ケルベロスを使用してユーザ（アン）を認証するようＳＩＰクライアント７４に求める４０７メッセージ９６を送る。４０７メッセージは以下のデータを含む。
【００５７】
Proxy-Authenticate: Kerberos realm = domainB.microsoft.com
targetname = "serverl.domainA.Microsoft.com" opaque = "someopaquedata"
【００５８】
ｏｐａｑｕｅ値は、この呼に対して使用するセキュリティコンテキストを識別するためにプロキシによって初期化される。そのために、プロキシサーバ７４はこのとき、関数ＡｃｃｅｐｔＳｅｃｕｒｉｔｙＣｏｎｔｅｘｔを呼び出し、ｐＯｕｔｐｕｔをｂａｓｅ６４でコード化した結果をｏｐａｑｕｅに入れて返す。クライアントおよびサーバは、このｏｐａｑｕｅ値を使用して、認証の継続、またはＡｕｔｈｏｒｉｚａｔｉｏｎリクエストヘッダを使用した同じサーバへの以降のリクエストの再認証のため特定のサーバに対して使用するセキュリティコンテキストを識別する。
【００５９】
アンのワークステーション上のＳＩＰクライアント７２は、認証が必要であることを指示する４０７メッセージ９６を受け取ると、Ｓｅｒｖｅｒ１．ｄｏｍａｉｎＢ．Ｍｉｃｒｏｓｏｆｔ．ｃｏｍと交信するための有効なセッションキーを持っているかどうかをチェックする。まだ所有していない場合には、このドメイン内のＫＤＣと接触して、アウトバウンドＳＩＰプロキシにアクセスするのためのセッションキーを取得する必要がある。この例では、４０７メッセージの中に指定されたｒｅａｌｍからクライアントは、自体のドメインとは異なるドメインにプロキシがあることを知る。
【００６０】
プロキシサーバ７４への安全な接続を確立するため、クライアント７２は、認証リクエストをプロキシに送る前にアウトバウンド証明書ハンドルを獲得する。これは、関数ＳＳＰＩを呼び出すことによって実行される。ＳＳＰＩは、ネットワーク化されたアプリケーションが、いくつかあるうちの１つのセキュリティサポートプロバイダ（ＳＳＰ）にコールして、認証済みの接続を確立し、確立された接続を介してデータを安全に交換する手段を提供する。認証セットアップに関与する２つのクライアント側ＳＳＰＩ関数がある。ＡｃｑｕｉｒｅＣｒｅｄｅｎｔｉａｌｓＨａｎｄｌｅ関数は、以前に取得したログオン証明書への参照を取得する。関数ＩｎｉｔｉａｌｉｚｅＳｅｃｕｒｉｔｙＣｏｎｔｅｘｔは、最初の認証リクエストセキュリティトークンを生成する。ＩｎｉｔｉａｌｉｚｅＳｅｃｕｒｉｔｙＣｏｎｔｅｘｔを呼び出すと、４０７メッセージから取得したｏｐａｑｕｅ値がｐＩｎｐｕｔに入れて渡される。クライアントは、この関数のｔｆＣｏｎｔｅｘｔＲｅｑパラメータをリクエストＭＵＴＵＡＬ＿ＡＵＴＨにセットする。ｐｆＣｏｎｔｅｘｔＡｔｔｒポインタは、ｍｕｔｕａｌ−ａｕｔｈが「リクエスト」されたことをケルベロスモジュール１８０がクライアントに知らせる方法である。この情報は、クライアントのケルベロスモジュール１８０によって生み出されるＫＥＲＢ＿ＡＳ＿ＲＥＱの一部であり、クライアントが相互認証を求めていることをサーバ（ここではＳＩＰプロキシ）に知らせるｓｅｃＢｕｆｆｅｒ（ｐＯｕｔｐｕｔ）に入れて渡される。これはＫＥＲＢリクエストの一部なので、ＳＩＰ機構（ヘッダ／パラメータ）が相互認証を要求する必要はない。
【００６１】
図２に示した例では、ＡＰＩ関数ＩｎｉｔｉａｌｉｚｅＳｅｃｕｒｉｔｙＣｏｎｔｅｘｔを呼び出すことによって、以下のケルベロス論理が生じる。最初にクライアント７２が、ＤｏｍａｉｎＢ（ドメインＢ）のプロキシサーバ７４へのサーバチケットをクライアント７２に与えるよう、ｄｏｍａｉｎＡ．Ｍｉｃｒｏｓｏｆｔ．ｃｏｍドメインのＫＤＣ１７０に求める。ｄｏｍａｉｎＡ．Ｍｉｃｒｏｓｏｆｔ．ｃｏｍのＫＤＣ１７０はクライアント７２に、ｃｏｒｐ．Ｍｉｃｒｏｓｏｆｔ．ｃｏｍのＫＤＣ１７２への照会チケットを送る。この照会チケットは、この２つのＫＤＣによって共有されたドメイン間キーの中に暗号化されている。この照会チケットを使用して、クライアントは、ＤｏｍａｉｎＢにあるサーバへのサーバチケットをクライアントに与えるよう、ｃｏｒｐ．Ｍｉｃｒｏｓｏｆｔ．ｃｏｍのＫＤＣ１７２に求める。
【００６２】
これに応答してＫＤＣ１７２は、ＤｏｍａｉｎＢのＫＤＣ１７６への照会チケットをクライアントに送る。このチケットは、ＫＤＣ１７２がＤｏｍａｉｎＢのＫＤＣ１７６と共有するドメイン間キーの中に暗号化されている。クライアントは次いで、ＤｏｍａｉｎＢにあるプロキシサーバ７４へのチケットをクライアントに与えるよう、ＤｏｍａｉｎＢのＫＤＣ１７６に求める。ＫＤＣ１７６は、プロキシサーバ７４にアクセスするためのサーバチケット１０８をクライアントに送る。ＫＤＣ１７６は、アンのログオンセッションキーを用いてこのセッションキーの１つのコピーを暗号化し、セッションキーの別のコピーをアンの許可データとともにサーバチケットに埋め込み、プロキシサーバの長期キーを用いてサーバチケットを暗号化する。ＫＤＣ１７６は次いで、これらの証明書を、Ｋｅｒｂｅｒｏｓ Ｔｉｃｋｅｔ−Ｇｒａｎｔｉｎｇ Ｓｅｒｖｉｃｅ Ｒｅｐｌｙ（ＫＲＢ＿ＴＧＳ＿ＲＥＰ）に入れてクライアント７２に送る。
【００６３】
このように、ＩｎｉｔｉａｌｉｚｅＳｅｃｕｒｉｔｙＣｏｎｔｅｘｔを呼び出すことによって、クライアントマシンのケルベロスモジュール１８０がＫＤＣとのＴＧＳ交換を開始する。この交換によって返される値は、プロキシに送るメッセージに署名するためのセッションキーである。
【００６４】
その後、ＳＩＰクライアント７２は、ＳＩＰプロキシに送る新しいＩＮＶＩＴＥメッセージ１１０（「ｒｅ−ＩＮＶＩＴＥ」メッセージとも呼ばれる）を生成する。この新しいＩＮＶＩＴＥメッセージ１１０は、クライアントがＫＤＣ１７６から受け取ったサーバチケットを含むＧＳＳ−ＡＰＩデータをその中に含んだ、先に説明したｐｒｏｘｙ−ａｕｔｈｏｒｉｚａｔｉｏｎヘッダを含む。セッションキーは、ＩｎｉｔｉａｌｉｚｅＳｅｃｕｒｉｔｙＣｏｎｔｅｘｔ呼出しによって返されたｐＯｕｔｐｕｔバッファの中に入れて返された値である。したがって、新しいＩＮＶＩＴＥメッセージ１１０は以下のデータを含む。
【００６５】
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
【００６６】
このＩＮＶＩＴＥメッセージは、プロキシサーバに対してＫＲＢ＿ＡＰ＿ＲＥＱと等価の内容を実行する。
【００６７】
メッセージの完全性を保護し、自体を認証する（すなわちメッセージの出処を証明する）ため、クライアントは、セッションキーを用いてＩＮＶＩＴＥメッセージ１１０に署名する。さもないと、第三者がこのＩＮＶＩＴＥメッセージをかぎつけ、ＯｐａｑｕｅおよびＧｓｓａｐｉ−ｄａｔａ値を手に入れ、偽のＩＮＶＩＴＥメッセージを同じサーバに送って、この第三者とそれが選択した任意の転送先との間で通話をおこなう可能性がある。このことは、サーバへのセッションキーが有効である間（デフォルトでは８時間）、クライアントの認証を「盗む」ことができることを意味する。ＩＮＶＩＴＥメッセージに署名することで、第三者がＯｐａｑｕｅおよびＧｓｓａｐｉ−ｒｄａｔａを取り出すことを防ぐことはできないが、新しいＩＮＶＩＴＥメッセージを生成して好き勝手に通話することは防ぐことができる。この問題を回避するためには、サーバが、署名されたリクエストしか受け入れないように構成されていなければならない。
【００６８】
クライアント７２は、ＭａｋｅＳｉｇｎａｔｕｒｅ ＡＰＩを使用し、これを呼び出して、（４０７メッセージのｏｐａｑｕｅ中に識別された）この呼出しで使用されるセキュリティコンテキストにｐｈＣｏｎｔｅｘｔをセットし、その内容を渡してｐＭｅｓｓａｇｅに署名する。この呼出しの出力は、ｐＭｅｓｓａｇｅの中に返された署名されたメッセージである。クライアントは、この署名をＩＮＶＩＴＥ１１０に追加する。再送されたＩＮＶＩＴＥメッセージ１１０を受け取ると、プロキシサーバ７４は、Ｐｒｏｘｙ−Ａｕｔｈｏｒｉｚａｔｉｏｎヘッダの中のｏｐａｑｕｅ値をチェックし、所与のｐｈＣｏｎｔｅｘｔ値（所与のセキュリティコンテキストへのハンドル）と相関させる。プロキシサーバ７４は、ｇｓｓａｐｉ−ｒｄａｔａを取り出し、ＡｃｃｅｐｔＳｅｃｕｒｉｔｙＣｏｎｔｅｘｔＡＰＩ関数を呼び出し、ｐｒｏｘｙ−ａｕｔｈｏｒｉｚａｔｉｏｎヘッダから得たｇｓｓａｐｉ−ｒｄａｔａ値をこのＡＰＩ関数のｐＩｎｐｕｔ成分の中に渡すことによって、これを自体のケルベロスモジュール１８２を渡す。ケルベロスモジュール１８２は、プロキシの長期キーを使用してサーバチケットを解読し、アンの許可データおよびセッションキーを抜き出す。ケルベロスモジュール１８２は、セッションキーを使用してアンのオーセンティケータ（ａｕｔｈｅｎｔｉｃａｔｏｒ）を解読し、次いで中のタイムスタンプを評価する。
【００６９】
オーセンティケータがこのテストにパスした場合、ケルベロスモジュール１８２は、クライアントのリクエストの中の相互認証フラグを探す。フラグがセットされている場合、ケルベロスモジュール１８２はセッションキーを使用して、アンのオーセンティケータからの時刻を暗号化し、その結果を、ＫｅｒｂｅｒｏｓＡｐｐｌｉｃａｔｉｏｎ Ｒｅｐｌｙ（ＫＲＢ＿ＡＰ＿ＲＥＰ）の中に返す。これによって、ＡｃｃｅｐｔＳｅｃｕｒｉｔｙＣｏｎｔｅｘｔが呼び出され、ＳＥＣ＿Ｅ＿ＯＫ戻り値が返され、オーセンティケータはｐＯｕｔｐｕｔバッファを使用してこのＡＰＩを通過する。ユーザが認証されると、ＳＩＰプロキシ／レジストラはこのリクエストを処理し、ＩＮＶＩＴＥメッセージを、ＳＩＰシグナリング経路上の次のホップに転送する。
【００７０】
プロキシのＳＩＰコンポーネントは次いで、ＳＩＰクライアントに転送する次のメッセージを使用してプロキシのオーセンティケータをクライアントに渡し、これによってクライアントがサーバを認証できるようにする。示された例では、このメッセージが「２００ＯＫ」メッセージである。このメッセージは、ＳＩＰプロキシによって生成されたものではない。この２００応答は、ＩＮＶＩＴＥリクエストに応答して呼出し先が生成する。ＳＩＰプロキシは単に、呼出し元に転送する前にセッションキーを用いてこの応答に署名するだけである。
【００７１】
先に説明したとおり、オーセンティケータは、Ｐｒｏｘｙ−Ａｕｔｈｅｎｔｉｃａｔｉｏｎ−Ｉｎｆｏｒｍａｔｉｏｎヘッダの中にある。このヘッダはさらに、クライアントが、この応答を正しいセキュリティコンテキストと一致させるためのｏｐａｑｕｅ値を含む。
【００７２】
アンのワークステーション上のＳＩＰクライアント７２は、「２００ＯＫ」メッセージを受け取ると、Ｐｒｏｘｙ−Ａｕｔｈｅｎｔｉｃａｔｉｏｎ−Ｉｎｆｏｒｍａｔｉｏｎヘッダを抜き出し、ＩｎｉｔｉａｌｉｚｅＳｅｃｕｒｉｔｙＣｏｎｔｅｘｔを呼び出す。ｐｈＣｏｎｔｅｘｔ値はｏｐａｑｕｅの中の値にセットされ、ｐＩｎｐｕｔバッファはｒｅｓｐｏｎｓｅ−ｄｉｇｅｓｔにセットされる。クライアント上のケルベロスモジュール１８０は、プロキシと共有するセッションキーを用いてプロキシのオーセンティケータを解読し、プロキシによって返された時刻を、クライアントのオリジナルのオーセンティケータの中の時刻と比較する。２つの時刻が一致した場合、このＩｎｉｔｉａｌｉｚｅＳｅｃｕｒｉｔｙＣｏｎｔｅｘｔの呼出しはＳＥＣ＿Ｅ＿ＯＫを返し、クライアントは、プロキシが本物であることを知る。一致しない場合にはクライアントはこの呼を取りやめなければならない。クライアントは、要求したことをサーバが実行すると信じることができないので、ＣＡＮＣＥＬを送ってこの呼を強制終了せざるを得ない。
【００７３】
上に説明した例では、認証が、まず最初にＳＩＰクライアントが認証データを含まないＩＮＶＩＴＥを送り、次いで、認証が必要であることを指示するプロキシからの４０７メッセージに応答して認証データを別のＩＮＶＩＴＥに入れて送るシナリオで実施される。その代わりにクライアントは、プロキシに送る最初のＩＮＶＩＴＥに必要な認証データを含めることもできる。そのためにクライアント７２は、ＳＩＰの下で通話するためにユーザが使用する前に、プロキシに対するサーバチケットをＫＤＣ１７６から取得する。次いで必要な認証データを、先に説明したＰｒｏｘｙ−Ａｕｔｈｏｒｉｚａｔｉｏｎリクエストヘッダに入れる。こうすることによって、プロキシがクライアントに４０７チャレンジを送って認証データを要求する必要がなくなる。さらに、先に説明した認証オペレーションの例ではＳＩＰプロキシが１つしか関与していないが、呼出し元と呼出し先の間のＳＩＰシグナリング経路上には一般に複数のＳＩＰプロキシがあり、２つ以上のＳＩＰプロキシが、呼出し元クライアントの認証を要求する可能性がある。例えば、図５に示す単純化されたケースでは、ＳＩＰクライアントのアウトバウンドプロキシサーバ７４の他に別のＳＩＰプロキシサーバ１２０があり、両方のプロキシが、ＩＮＶＩＴＥメッセージを転送する前にクライアントの認証を必要とする。この場合には、クライアント７２がまず、図４に関して先に説明した同じプロセスを経て、アウトバウンドＳＩＰサーバ７４に対して自体を認証する。クライアントを認証した後、プロキシサーバ７４は第２のプロキシ１２０にＩＮＶＩＴＥを送り、第２のプロキシ１２０は次いで、クライアントに４０７チャレンジ１９０を送る。これに応答してクライアントは、第２のプロキシサーバ１２０用のケルベロスサーバチケットを含んだＰｒｏｘｙ−Ａｕｔｈｏｒｉｚａｔｉｏｎヘッダを有する別の新しいＩＮＶＩＴＥ１９２を送る。クライアントを認証した後、第２のプロキシは呼出し先にＩＮＶＩＴＥ１９２を渡す。
【００７４】
以下の説明は、ケルベロスまたはＮＴＬＭセキュリティ機構に基づいて認証を実行するさまざまなメッセージフローのシナリオにおいて、Ｐｒｏｘｙ Ａｕｔｈｅｎｔｉｃａｔｅ、Ｐｒｏｘｙ ＡｕｔｈｏｒｉｚａｔｉｏｎおよびＰｒｏｘｙ−Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｉｎｆｏｒｍａｔｉｏｎヘッダをどのように使用するかを説明する追加の例を提供する。図６を参照する。このケースでは、ＳＩＰクライアント７２が、体をプロキシサーバに登録するときにケルベロスベースのプレ認証を実行する。クライアントは、プロキシに対するケルベロスサーバチケットを含むＰｒｏｘｙ−Ａｕｔｈｏｒｉｚａｔｉｏｎヘッダを含むＲＥＧＩＳＴＥＲリクエスト２００、および先に説明した相互認証のためのリクエストを送る。サーバチケットに基づいてクライアントを認証した後、プロキシは、クライアントが使用してプロキシを認証することができるプロキシ認証データを含むＰｒｏｘｙ−Ａｕｔｈｅｎｔｉｃａｔｉｏｎ−Ｉｎｆｏｒｍａｔｉｏｎヘッダとともに、２００ＯＫメッセージ２０２を返す。ＲＥＧＩＳＴＥＲおよび２００ＯＫメッセージの内容の例を以下に示す。
【００７５】
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
【００７６】
図７に、ケルベロスベースのチャレンジド認証（ｃｈａｌｌｅｎｇｅｄ ａｕｔｈｅｎｔｉｃａｔｉｏｎ）のシナリオを示す。この例では、クライアント７２がまず、Ｐｒｏｘｙ−Ａｕｔｈｏｒｉｚａｔｉｏｎ情報を含まないＩＮＶＩＴＥ２０６をプロキシ７４に送る。プロキシはこれに応答して、認証が必要であることを指示するＰｒｏｘｙ−Ａｕｔｈｅｎｔｉｃａｔｅヘッダを含む４０７メッセージ２０８を送る。この４０７メッセージに応答してクライアントは、必要なケルベロス認証データを含むＰｒｏｘｙ−Ａｕｔｈｏｒｉｚａｔｉｏｎヘッダを有するＲＥＧＩＳＴＥＲリクエスト２１０を送る。プロキシは、プロキシ自体についての認証情報を含むＰｒｏｘｙ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｉｎｆｏｒｍａｔｉｏｎヘッダを有する「２００ＯＫ」メッセージ２１２を返す。Ｐｒｏｘｙ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｉｎｆｏｒｍａｔｉｏｎヘッダの中のデータに基づいてプロキシを認証した後、クライアントは、Ｐｒｏｘｙ−Ａｕｔｈｏｒｉｚａｔｉｏｎヘッダを有する第２のＩＮＶＩＴＥ２１４を送る。このプロセスの例示的なメッセージを以下に示す。
【００７７】
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
【００７８】
次に図８を参照する。先に述べたとおり、好ましい実施形態では任意選択で、クライアント・プロキシ認証にＮＴＬＭセキュリティ機構を使用することができる。この場合、クライアントがまず、認証データを含まないＩＮＶＩＴＥメッセージ２２０を送り、プロキシが４０７メッセージを返す。この４０７メッセージ２２２のＰｒｏｘｙ Ａｕｔｈｅｎｔｉｃａｔｅヘッダは、認証に対してＮＴＬＭを使用しなければならないことを指示する。次いでクライアントが、ＮＴＬＭプロトコルに基づくクライアントの認証データを含むＰｒｏｘｙ Ａｕｔｈｅｎｔｉｃａｔｉｏｎヘッダを有するＲＥＧＩＳＴＥＲメッセージ２２４を送る。
【００７９】
図４の状態機械に関連して先に述べたとおり、クライアントによって送られた認証データによって、プロキシはクライアントを認証することができるが、この認証データに基づいてセキュリティアソシエーションは完全には確立されない。そのためプロキシは、Ｐｒｏｘｙ Ａｕｔｈｅｎｔｉｃａｔｅヘッダをやはり含む別の４０７チャレンジ２２６をクライアントに送る。クライアントは次いで、セキュリティアソシエーションを完成させるのに必要な認証データを含むＰｒｏｘｙ Ａｕｔｈｏｒｉｚａｔｉｏｎヘッダを有する別のＲＥＧＩＳＴＥＲリクエスト２２８を送る。プロキシサーバは、第２のＲＥＧＩＳＴＥＲリクエストの中のデータに基づいてセキュリティアソシエーションを完成させ、プロキシについての認証データを含むＰｒｏｘｙ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｉｎｆｏｒｍａｔｉｏｎヘッダを有する「２００ＯＫ」メッセージ２３２を返す。「２００ＯＫ」メッセージ２３２の中の認証データに基づいてクライアントはプロキシを認証し、次いで別のＩＮＶＩＴＥメッセージ２３６を送る。このプロセスの例示的なメッセージを以下に示す。
【００８０】
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
【００８１】
図９に、ＮＴＬＭベースのプレ認証のシナリオを示す。このケースのメッセージフローは、ケルベロスベースのプレ認証のそれに似ているが、４０７チャレンジおよびＲＥＧＩＳＴＥＲメッセージが追加されている点が異なる。具体的にはクライアントが、ＮＴＬＭを使用することを指示し、ＮＴＬＭ認証データを含むＰｒｏｘｙ Ａｕｔｈｏｒｉｚａｔｉｏｎヘッダを含むＲＥＧＩＳＴＥＲメッセージ２４０および相互認証のためのリクエストを送る。プロキシは、受け取ったＮＴＬＭ認証データに基づいてクライアントを認証し、Ｐｒｏｘｙ Ａｕｔｈｅｎｔｉｃａｔｅヘッダを有する４０７チャレンジ２４２を返す。クライアントは次いで、プロキシとのセキュリティアソシエーションを完成するためのＮＴＬＭ認証データを含むＰｒｏｘｙ Ａｕｔｈｏｒｉｚａｔｉｏｎヘッダを有する第２のＲＥＧＩＳＴＥＲリクエスト２４４を送る。プロキシは次いで、Ｐｒｏｘｙ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｉｎｆｏｒｍａｔｉｏｎを有する「２００ＯＫ」メッセージ２４６を返す。プロキシを認証した後、クライアントはプロキシに第２のＩＮＶＩＴＥメッセージ２４８を送る。このプロセスの例示的なメッセージを以下に示す。
【００８２】
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
【００８３】
本発明の原理を適用することができる多くの可能な実施形態があることを考慮すれば、図面に関して本明細書に記載した実施形態は例示的なものであって、本発明の範囲を限定するものと解釈してはならないことが認識される。例えば、ソフトウェア（またはハードウェア）として示した記載の実施形態の要素をハードウェア（またはソフトウェア）として実装することができること、または本発明の趣旨から逸脱することなく記載の実施形態の配置および詳細を修正することができることを当業者は認識しよう。したがって本明細書に記載した発明は、前記請求項およびその等価物の範囲に含まれる全ての実施形態を企図する。
【００８４】
【発明の効果】
ケルベロスプロトコル、ＮＴＬＭプロトコルなどのセキュリティ機構を、ＳＩＰシグナリングオペレーションのメッセージフローに組み込んで、ＳＩＰクライアントとＳＩＰプロキシが相互に認証できるようにするための方式が提供される。
【図面の簡単な説明】
【図１】本発明を実現することができる例示的なコンピュータシステムを概略的に示すブロック図である。
【図２】セッションシグナリング段階中に相互認証するＳＩＰクライアントとＳＩＰプロキシサーバを含むセッションイニシエーションプロトコル（ＳＩＰ）システムを示す概略図である。
【図３】ＳＩＰクライアントとＳＩＰプロキシサーバの間の認証目的のシグナリングメッセージ交換を示す概略図である。
【図４】ＳＩＰのフレームワークに組み込まれたセキュリティ機構のオペレーションを表す状態機械を示す概略図である。
【図５】ＳＩＰクライアントが複数のＳＩＰプロキシと認証オペレーションを実行するためのシグナリングメッセージ交換を示す概略図である。
【図６】ケルベロスセキュリティ機構を使用したＳＩＰクライアントとプロキシの間のプレ認証プロセスにおけるメッセージフローを示す概略図である。
【図７】ケルベロスセキュリティ機構を使用したＳＩＰクライアントとプロキシの間のチャレンジド認証プロセスにおけるメッセージフローを示す概略図である。
【図８】ＮＴＬＭセキュリティ機構を使用したＳＩＰクライアントとプロキシの間のチャレンジド認証プロセスにおけるメッセージフローを示す概略図である。
【図９】ＮＴＬＭセキュリティ機構を使用したＳＩＰクライアントとプロキシの間のプレ認証プロセスにおけるメッセージフローを示す概略図である。
【符号の説明】
２０ パーソナルコンピュータ
２１ 処理ユニット
２２ システムメモリ
２３ システムバス
２４ ＲＯＭ
２５ ＲＡＭ
２７ ハードディスクドライブ
２８ 磁気ディスクドライブ
３０ 光ドライブ
３２ ハードディスクドライブインタフェース
３３ 磁気ディスクドライブインタフェース
３４ 光ディスクドライブインタフェース
３５ オペレーティングシステム
３６ アプリケーションプログラム
３７ その他のプログラムモジュール
３８ プログラムデータ
４０ キーボード
４２ マウス
４６ シリアルポートインタフェース
４７ モニタ
４８ ビデオアダプタ
４９ リモートコンピュータ
５０ メモリ記憶装置
５１ ローカルエリアネットワーク
５２ ワイドエリアネットワーク
５３ ネットワークインタフェース
５４ モデム
７２ ＳＩＰクライアント
７４ ＳＩＰプロキシサーバ
７６、８０ ユーザ
８２ ＩＮＶＩＴＥメッセージ
８６ ＳＩＰクライアント
８８ ワークステーション
９０ シグナリング経路
９６ ４０７チャレンジメッセージ
１０２ ドメインコントローラ
１０８ サーバチケット
１１０ ＩＮＶＩＴＥメッセージ
１１６ セッションキー
１２０ ＳＩＰプロキシサーバ
１２２ ２００ＯＫメッセージ
１７０、１７２、１７６ ＫＤＣ
１８０、１８２ ケルベロスモジュール
【発明の属する技術分野】
本発明は一般に、コンピュータネットワークを介した装置間通信に関し、詳細には、セキュリティ機構、例えばケルベロス認証プロトコルに基づくセキュリティ機構を、セッションイニシエーションプロトコル（ＳＩＰ：Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）を通信セッションを確立するためのシグナリングプロトコルとして使用したネットワーク通信に組み込むことに関する。
【０００２】
【従来の技術】
セッションイニシエーションプロトコル（ＳＩＰ）は、コンピューティング装置が、自体がコンピュータネットワークを介して通信したいと欲している他の装置の位置を突き止め、その装置との間に通信セッションを確立するための機構を提供するシグナリングプロトコルである。ＳＩＰは汎用性のあるプロトコルであり、多くの異なるシナリオで通信セッションを確立するのに使用されてきた。ＳＩＰは例えば、インターネット会議、電話、プレゼンス（ｐｒｅｓｅｎｃｅ）、イベント通知およびインスタントメッセージングに使用されている。ＳＩＰの重要な強みは、位置独立の単一のアドレスの下にいる被呼者（ユーザ）に、たとえこの被呼者が別のコンピュータに移動していたとしてもたどり着くことができる、パーソナルモビリティ（ｐｅｒｓｏｎａｌ ｍｏｂｉｌｉｔｙ）をサポートしていることである。
【０００３】
ＳＩＰに基づくセッション開始オペレーションの共通する１つのモードは「プロキシ（ｐｒｏｘｙ）モード」である。例えば、ＳＩＰクライアント（「呼出し元」）は、意図された受信者（「呼出し先」）を電子メールアドレスに似たアドレスによって識別するＩＮＶＩＴＥメッセージなどのＳＩＰリクエストメッセージを送ることができる。このリクエストメッセージは一般にまず、送信側ＳＩＰクライアントのアウトバウンド（ｏｕｔｂｏｕｎｄ）ＳＩＰプロキシに送られる。次いでこのアウトバウンドＳＩＰプロキシがこのリクエストメッセージを、しばしば他の中間ＳＩＰプロキシを介して、意図された受信側クライアントが登録されているＳＩＰプロキシに転送し、次いでこのＳＩＰプロキシが、ＩＮＶＩＴＥメッセージを受信側クライアントに送る。受信側クライアントの受入れメッセージ（「２００ＯＫ」）が、シグナリングチェーンを介して呼出し元クライアントに戻され、これによって、呼出し元クライアントは呼出し先クライアントと、一般にシグナリングチャネルとは別の媒体チャネルを通して通信できるようになる。他のＳＩＰクライアントと通信する他に、ＳＩＰクライアントはさらに、ＲＥＧＩＳＴＥＲリクエストを送ることによってＳＩＰレジストラ（ｒｅｇｉｓｔｒａｒ）に自体を登録するなどの目的で、ＳＩＰサーバと通信することができる。
【０００４】
【発明が解決しようとする課題】
さまざまな応用に対して幅広く実装されてはいるが、ＳＩＰは、主としてシグナリングオペレーション用に設計されたものである。ＳＩＰは、通信セッションのセキュリティおよびプライバシーを保護するためのセキュリティ機構を明示的に提供せず、またはこれを必要としない。しかし多くのケースで、ＳＩＰクライアントが、ＳＩＰクライアントのユーザを認証するよう求めるリクエストをアウトバウンドＳＩＰプロキシに送ることを要求し、アウトバウンドＳＩＰプロキシが、ＳＩＰクライアントに対して自体を認証することを要求することが望ましい。さらに、ＳＩＰリクエストメッセージの完全性を保護することもしばしば必要である。クライアント・プロキシ認証およびメッセージの完全性はともに、信頼性の高いセキュリティ機構の使用を要求する。したがって、信頼性の高いセキュリティ機構をＳＩＰシグナリングオペレーションと組み合わせて、ＳＩＰクライアントとアウトバウンドプロキシとの間の認証を可能にすることが求められている。しかし、所望のセキュリティ機構をＳＩＰシグナリングフレームワークにどのようにはめ込んで、目的の異なるこれらの２つの機構を一緒に効果的に実行することができるようにするかということが技術上の課題である。
【０００５】
【課題を解決するための手段】
以上のことを考慮して、本発明は、ケルベロス（Ｋｅｒｂｅｒｏｓ）プロトコル、ＮＴＬＭプロトコルなどのセキュリティ機構を、ＳＩＰシグナリングオペレーションのメッセージフローに組み込んで、ＳＩＰクライアントとＳＩＰプロキシが相互に認証できるようにするための方式を提供する。本発明によれば、ＳＩＰクライアントからＳＩＰリクエストメッセージを受け取ると、プロキシはこれに応答して、予め選択されたセキュリティ機構に基づく認証が必要であることを指示するチャレンジメッセージを送る。これに応答してＳＩＰクライアントは、前記セキュリティ機構に基づいてサーバに対してクライアントを認証するための認証データを含むｐｒｏｘｙ ａｕｔｈｏｒｉｚａｔｉｏｎヘッダを有する前記リクエストメッセージの第２バージョンないし改訂バージョンを送る。ケルベロスセキュリティ機構を使用する場合には、ｐｒｏｘｙ ａｕｔｈｏｒｉｚａｔｉｏｎヘッダが、プロキシにアクセスするためにクライアントが取得したケルベロスサーバチケットを表すデータを含む。ｐｒｏｘｙ ａｕｔｈｏｒｉｚａｔｉｏｎヘッダのデータに基づくクライアントのユーザの認証に成功した場合、ＳＩＰプロキシは、ＳＩＰクライアントとリクエストメッセージの意図された受信者との間のＳＩＰメッセージシグナリング経路に沿ってこのリクエストを転送する。ＳＩＰクライアントが相互認証を要求している場合、ＳＩＰプロキシは、クライアントに送る次のメッセージにｐｒｏｘｙ ａｕｔｈｅｎｔｉｃａｔｉｏｎ ｉｎｆｏｒｍａｔｉｏｎ（プロキシ認証情報）ヘッダを追加する。このメッセージは例えば、ＩＮＶＩＴＥリクエストに応答して呼出し先ＳＩＰクライアントが生成した「２００ＯＫ」ＳＩＰ応答、またはＲＥＧＩＳＴＥＲメッセージに応答してＳＩＰレジストラサーバが生成した「２００ＯＫ」応答である。ｐｒｏｘｙ ａｕｔｈｅｎｔｉｃａｔｉｏｎ ｉｎｆｏｒｍａｔｉｏｎヘッダは、クライアントがＳＩＰプロキシを認証するための認証データを含む。
【０００６】
本発明の特徴は請求項に詳細に記述されているが、本発明、ならびに本発明の目的および利点は、添付図面を参照して以下の詳細な説明を読むことによって最もよく理解されよう。
【０００７】
【発明の実施の形態】
図面を参照すると、適当なコンピューティング環境中に実現された本発明が示されている。図面中、同様の参照符号は同様の要素を指す。そうでなければならないというわけではないが、本発明は、パーソナルコンピュータによって実行される、プログラムモジュールなどのコンピュータ実行可能命令の一般的な文脈で説明される。プログラムモジュールには一般に、特定のタスクを実行し、または特定の抽象データ型を実装するルーチン、プログラム、オブジェクト、コンポーネント、データ構造などが含まれる。さらに、本発明を、ハンドヘルド装置、マルチプロセッサシステム、マイクロプロセッサベースの、またはプログラム可能な家庭用電子機器、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータなどを含む他のコンピュータシステム構成とともに実施できることを当業者は理解されたい。本発明は、通信ネットワークを介してリンクされた遠隔処理装置によってタスクが実行される分散コンピューティング環境で実施することができる。分散コンピューティング環境では、プログラムモジュールが、ローカルメモリ記憶装置と遠隔メモリ記憶装置の両方に位置することができる。
【０００８】
以下の説明ではまず、本発明を実現するための例示的なシステム中で使用することができる汎用コンピューティング装置を説明し、次いで、図２〜９を参照して本発明をより詳細に説明する。図１を参照すると、処理ユニット２１、システムメモリ２２およびシステムバス２３を含む従来のパーソナルコンピュータ２０の形態の汎用コンピューティング装置が示されている。システムバス２３は、システムメモリを含むさまざまなシステムコンポーネントを処理ユニット２１に結合する。システムバス２３は、さまざまなバスアーキテクチャのうちの任意のアーキテクチャを使用した、メモリバスまたはメモリコントローラ、周辺バスおよびローカルバスを含むいくつかのタイプのバス構造のうちの任意の構造とすることができる。システムメモリは、リードオンリーメモリ（ＲＯＭ）２４およびランダムアクセスメモリ（ＲＡＭ）２５を含む。ＲＯＭ２４には、起動時などにパーソナルコンピュータ２０の内部要素間の情報転送を助ける基本ルーチンを含む基本入出力システム（ＢＩＯＳ）２６が記憶されている。パーソナルコンピュータ２０はさらに、ハードディスク６０の読取り／書込み用のハードディスクドライブ２７、リムーバブル磁気ディスク２９の読取り／書込み用の磁気ディスクドライブ２８、およびＣＤ−ＲＯＭまたは他の光媒体などのリムーバブル光ディスク３１の読取り／書込み用の光ディスクドライブ３０を含む。
【０００９】
ハードディスクドライブ２７、磁気ディスクドライブ２８および光ディスクドライブ３０はそれぞれ、ハードディスクドライブインタフェース３２、磁気ディスクドライブインタフェース３３、および光ディスクドライブインタフェース３４によってシステムバス２３に接続されている。これらのドライブおよび関連コンピュータ可読媒体は、コンピュータ可読命令、データ構造、プログラムモジュール、およびパーソナルコンピュータ２０のためのその他のデータを記憶する不揮発性記憶装置を提供する。ここに記載した例示的な環境では、ハードディスク６０、リムーバブル磁気ディスク２９およびリムーバブル光ディスク３１が使用されているが、この例示的な動作環境では、磁気カセット、フラッシュメモリカード、ディジタルビデオディスク、ベルヌーイカートリッジ、ランダムアクセスメモリ、リードオンリーメモリ、ストレージエリアネットワークなど、コンピュータがアクセス可能なデータを記憶することができる他のタイプのコンピュータ可読媒体を使用することもできることを当業者は理解されたい。
【００１０】
ハードディスク６０、磁気ディスク２９、光ディスク３１、ＲＯＭ２４またはＲＡＭ２５には、オペレーティングシステム３５、１つまたは複数のアプリケーションプログラム３６、他のプログラムモジュール３７およびプログラムデータ３８を含む、いくつかのプログラムモジュールを記憶することができる。ユーザは、キーボード４０、ポインティングデバイス４２などの入力装置を介して、コマンドおよび情報をパーソナルコンピュータ２０に入力することができる。この他の入力装置（図示せず）には例えば、マイクロホン、ジョイスティック、ゲームパッド、衛星アンテナ、スキャナなどがある。これらの入力装置および他の入力装置はたいてい、システムバスに結合されたシリアルポートインタフェース４６を介して処理ユニット２１に接続されるが、パラレルポート、ゲームポート、ユニバーサルシリアルバス（ＵＳＢ）、ネットワークインタフェースカードなどの他のインタフェースによって接続することもできる。さらに、モニタ４７または他のタイプのディスプレイ装置が、ビデオアダプタ４８などのインタフェースを介してシステムバス２３に接続されている。モニタの他に、パーソナルコンピュータは一般に、スピーカ、プリンタなどの周辺出力装置（図示せず）を含む。
【００１１】
パーソナルコンピュータ２０は、リモートコンピュータ４９などの１台または数台のリモートコンピュータへの論理接続を使用したネットワーク化された環境で動作することができる。リモートコンピュータ４９は、別のパーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ピア装置または他の普通のネットワークノードとすることができる。図１にはメモリ記憶装置５０だけしか示されていないが、リモートコンピュータ４９は一般に、パーソナルコンピュータ２０に関して先に説明した全ての要素または多くの要素を含む。図１に示した論理接続は、ローカルエリアネットワーク（ＬＡＮ）５１およびワイドエリアネットワーク（ＷＡＮ）５２を含む。このようなネットワーキング環境は、事業所、企業内コンピュータネットワーク、イントラネットおよびインターネットでごく普通に見られるものである。
【００１２】
ＬＡＮネットワーキング環境で使用するとき、パーソナルコンピュータ２０は、ネットワークインタフェースまたはアダプタ５３を介してローカルネットワーク５１に接続される。ＷＡＮネットワーキング環境で使用するとき、パーソナルコンピュータ２０は一般にモデム５４、またはＷＡＮ５２を介した通信を確立するためのその他の手段を含む。モデム５４は、内部モデムでもまたは外部モデムでもよく、シリアルポートインタフェース４６を介してシステムバス２３に接続される。ネットワーク化された環境では、パーソナルコンピュータ２０に関して図示したプログラムモジュール、またはその一部分を、遠隔メモリ記憶装置に記憶することができる。示されたネットワーク接続は例示的なものであり、コンピュータ間に通信リンクを確立する他の手段を使用することができることを理解されたい。
【００１３】
特に指示しない限り以下の説明では、１台または数台のコンピュータによって実行されるアクト（ａｃｔ）およびオペレーションの記号的表現を参照して、本発明を説明する。時にコンピュータ実行アクトまたはオペレーションと呼ばれるこのようなアクトおよびオペレーションは、コンピュータの処理ユニットによる、構造化された形態のデータを表す電気信号の操作を含むことを理解されたい。この操作では、データを変換し、またはコンピュータのメモリシステム中の位置にデータを維持する。これによって、コンピュータのオペレーションは当業者によってよく理解されている方法で再構成され、または別な方法で変更される。データが維持されるデータ構造は、データのフォーマットによって定義された特定の特性を有するメモリの物理的位置である。しかし、本発明は以上の文脈で説明されるが、これは限定を意味しない。当業者なら分かるとおり、以降に説明するさまざまなアクトおよびオペレーションはハードウェアとして実装することもできるからである。
【００１４】
次に図２を参照する。本発明は、セキュリティ機構、特にケルベロス認証プロトコルを実装したセキュリティ機構を、セッションイニシエーションプロトコル（ＳＩＰ）に基づくリクエストメッセージに組み込んで、ＳＩＰクライアント７２とＳＩＰプロキシサーバ７４が相互に認証することができるようにし、かつシグナリングメッセージの完全性を保護するための方法を対象とする。ＳＩＰは、ＲＦＣ（Ｒｅｑｕｅｓｔ ｆｏｒ Ｃｏｍｍｅｎｔｓ）２５４３に定義されている。この文書は、その全体が参照によって本明細書に組み込まれる。
【００１５】
例えば、一般的なセッション開始オペレーションでは図２に示すように、別のユーザ８０（例えば「ボブ（Ｂｏｂ）」）と話しをしたいＳＩＰクライアント７２（「呼出し元」）のユーザ７６（例えば「アン（Ａｎｎ）」）は、ボブがＩＮＶＩＴＥメッセージ８２の意図された受信者であることを確認するＩＮＶＩＴＥメッセージを送る。このＩＮＶＩＴＥメッセージは、呼出し元ＳＩＰクライアントのドメインに対応するアウトバウンドプロキシサーバ７４に送られる。図２に示すようにＩＮＶＩＴＥメッセージは、このシグナリングオペレーションに関与する複数のＳＩＰプロキシを介して送られ、その後、ボブのコンピュータ８８のＳＩＰクライアント８６（呼出し先）に到達する。好ましい実施形態では、シグナリング経路上のＳＩＰプロキシ間で転送中のＳＩＰシグナリングメッセージのセキュリティが、ＩＰｓｅｃプロトコルの下で、またはＳＳＬ（ＳｅｃｕｒｅｄＳｏｃｋｅｔｓ Ｌａｙｅｒ）プロトコルの下でパイプを通してメッセージを送ることによって保護される。この例ではＳＩＰリクエストがＩＮＶＩＴＥリクエストだが、以下で説明する認証方式は、ＲＥＧＩＳＴＥＲ、ＭＥＳＳＡＧＥ、ＳＵＢＳＣＲＩＢＥ、ＳＥＲＶＩＣＥなどの他のタイプのＳＩＰリクエストに対しても使用することができることを理解されたい。
【００１６】
シグナリングオペレーションのセキュリティおよびシグナリングメッセージの完全性を確保するため、アウトバウンドＳＩＰプロキシサーバ７４は、シグナリング経路９０を介してＩＮＶＩＴＥメッセージ８２を転送する前に、呼出し元ＳＩＰクライアント７２のユーザ７６の認証を求めることができる。次に図３を参照する。本発明によればプロキシサーバ７４はＩＮＶＩＴＥメッセージに応答して、ＳＩＰクライアント７２にチャレンジメッセージ９６を送る。チャレンジメッセージ９６は、まず最初にクライアント７２がそのユーザをプロキシ７４に対して認証しなければならないことを指示する、ＳＩＰ仕様に定義されたステータスコード「４０７ Ｐｒｏｘｙ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｒｅｑｕｉｒｅｄ（４０７プロキシ認証が必要）」を含む。ＳＩＰ仕様によれば、チャレンジメッセージ９６（以後「４０７メッセージ」と呼ぶ）は、認証のためにクライアントが使用しなければならないセキュリティ機構を指示するデータを含む「Ｐｒｏｘｙ−Ａｕｔｈｅｎｔｉｃａｔｅ」ヘッダフィールド９８を含む。Ｐｒｏｘｙ−Ａｕｔｈｅｎｔｉｃａｔｅヘッダの構文および内容ヘッダについては後に詳細に説明する。好ましい実施形態では、ケルベロスが好ましいセキュリティ機構だが、ＳＩＰフレームワークでは、ＮＴＬＭプロトコルに基づくセキュリティ機構の使用も可能である。以下の説明では、特に指示しない限り、ケルベロスプロトコルに基づくセキュリティ機構を使用するものとする。
【００１７】
さらに図３を参照する。ＩＮＶＩＴＥメッセージ８２に応答したプロキシサーバ７４から４０７メッセージ９６を受け取ると、Ｐｒｏｘｙ−Ａｕｔｈｅｎｔｉｃａｔｅヘッダ９８からＳＩＰクライアント７２は、ケルベロス機構を使用したユーザの認証をプロキシサーバが求めていると判断する。サーバチケットをまだ取得していない場合、クライアント７２は次いで、ＳＩＰプロキシサーバ７４のケルベロス・キー・ディストリビューション（配布）・センター（ＫＤＣ：Ｋｅｙ Ｄｉｓｔｒｉｂｕｔｉｏｎ Ｃｅｎｔｅｒ）１００からサーバチケット１０８を取得する。一実施態様では、ＫＤＣ１００が、プロキシサーバ７４のドメインコントローラ１０２の一部である。サーバチケット１０８を取得した後、クライアント７２は別のＩＮＶＩＴＥメッセージ１１０を送る。ただしこのときには、ＩＮＶＩＴＥメッセージ１１０が、ＳＩＰ仕様に基づくＰｒｏｘｙ−Ａｕｔｈｏｒｉｚａｔｉｏｎ（プロキシ許可）ヘッダフィールド１１２を含んでいる。Ｐｒｏｘｙ−Ａｕｔｈｏｒｉｚａｔｉｏｎヘッダフィールド１１２は、プロキシサーバにアクセスするためのサーバチケット１０８を含む。サーバチケット１０８は、使用するセッションキー１１６を含んでいる。Ｐｒｏｘｙ−Ａｕｔｈｏｒｉｚａｔｉｏｎヘッダフィールドの構文および内容については後に詳細に説明する。任意選択で、Ｐｒｏｘｙ−Ａｕｔｈｏｒｉｚａｔｉｏｎヘッダにさらに、クライアント７２に対して自体を認証するようプロキシサーバ７４に求める、相互認証のためのリクエストを含めることもできる。
【００１８】
ＳＩＰプロキシサーバ７４は、ケルベロスサーバチケットが埋め込まれた再送ＩＮＶＩＴＥメッセージ１１０を受け取ると、サーバチケットを抜き出し、チケットの有効性を、ＫＤＣ１００と共有しているその長期キーでチケットを解読することによって検証する。チケットが有効である場合、ユーザ７６は認証され、ＳＩＰプロキシサーバ７４は、シグナリング経路上の次のプロキシ１２０にＩＮＶＩＴＥメッセージ１１０を転送する。クライアント７２が、ＩＮＶＩＴＥメッセージ１１０のＰｒｏｘｙ−Ａｕｔｈｏｒｉｚａｔｉｏｎヘッダ１１２の中で相互認証を要求してきた場合、プロキシサーバ７４は、ケルベロスサーバチケットに関連付けられたセッションキーを使用して、自体からクライアントへの将来のパケットに署名する。このメッセージは、クライアント７２がプロキシ７４を認証することを可能にするプロキシ７４の証明書（ｃｒｅｄｅｎｔｉａｌ）を含むＰｒｏｘｙ−Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｉｎｆｏｒｍａｔｉｏｎヘッダ１２４を含む。
【００１９】
最終的に、ＩＮＶＩＴＥメッセージ１１０は呼出し先、すなわちボブのコンピュータ８８のＳＩＰクライアント８６に届く。この呼勧誘を受け入れる場合、呼出し先は「２００ ＯＫ」メッセージ１２６を返し、このメッセージは呼出し元へ送られる。呼接続が確立されると、呼出し元は、このシグナリング段階に関与したＳＩＰプロキシを通すことなく、呼出し先と直接に通信することができる。
【００２０】
次に図４を参照する。本発明によれば、ＳＩＰクライアント７２とＳＩＰプロキシサーバ７４の間で認証セキュリティアソシエーション（ＳＡ：ｓｅｃｕｒｉｔｙ ａｓｓｏｃｉａｔｉｏｎ）を確立するオペレーションは、状態機械１２８として見ることができる。図４に示す実施形態では、好ましいセキュリティ機構がケルベロスであるが、任意選択でＮＴＬＭセキュリティ機構も使用することができ、この状態機械図は、この任意選択の包含を反映したものになっている。
【００２１】
図４では、状態が円の中に、状態に関連して実行されるオペレーションが長方形のブロックの中に示されている。図４に示すように、状態機械の１つの状態が、セキュリティＳＡが確立されていない「ＳＥＣＵＲＩＴＹ＿ＳＴＡＴＥ＿ＮＯＮＥ」状態１３２である。クライアント７２が送ったＩＮＶＩＴＥメッセージに応答したプロキシ７４から４０７チャレンジメッセージを受け取り、またはプロキシとプレ認証（ｐｒｅ−ａｕｔｈｅｎｔｉｃａｔｉｏｎ）を実行すると決定すると、クライアント７２は「ＳＥＣＵＲＩＴＹ＿ＳＴＡＴＥ＿ＡＣＱＵＩＲＩＮＧ＿ＳＡ」状態１３６に入り、認証に必要なセキュリティアソシエーションデータを獲得する。認証に必要なセキュリティアソシエーションデータは、選択したセキュリティ機構によって異なる。
【００２２】
セキュリティアソシエーションは一般に、クライアントとＳＩＰプロキシが共有の秘密を安全な方法で交換し、この秘密を使用して認証し、クライアントとプロキシによって交換される以降のメッセージの完全性を保護することができる状態と定義される。セキュリティ機構がケルベロスである場合、セキュリティアソシエーションは、プロキシに対するケルベロスサーバチケットおよびセッションキーを含む。ケルベロスの場合、取得されたＳＡは完全である。すなわち、これを使用して、ＳＩＰクライアントのユーザをプロキシが十分に認証することができる。クライアントは次いで、このＳＡ関連情報（例えばサーバの秘密を用いて暗号化されたケルベロスセッションキー）をプロキシに送る（段階１３８）。プロキシが、署名された２００ＯＫメッセージを返した場合（段階１４０）、認証は成功であり、セキュリティアソシエーションは確立されている。すなわちクライアントはＳＡ＿Ｅｓｔａｂｌｉｓｈｅｄ状態１４２にある。しかし、プロキシが代わりに４０７チャレンジメッセージを返した場合（段階１４６）、クライアントは、プロキシが不良な状態にあり、そのためクライアントの正当な証明書を検証することができないでいるとみなす。次いでクライアントは「バックオフ」時間（例えば５分）のあいだ待機し（段階１４８）、その後再びＳＩＰメッセージを送る。
【００２３】
ＳＡ＿Ｅｓｔａｂｌｉｓｈｅｄ状態１４２に入った後は、セキュリティアソシエーションが期限切れにならない限り、クライアントは再び認証を実行することなくプロキシに別のメッセージを送ることができる。しかしプロキシが４０７チャレンジメッセージを送った場合（段階１５０）、クライアントは、確立されたセキュリティアソシエーションをプロキシが何かの理由で取り下げたとみなす。その結果、クライアントは、ＳＡ＿Ｄｒｏｐｐｅｄ状態１５６に入り、ＳＥＣＵＲＩＴＹ＿ＳＴＡＴＥ＿ＡＣＱＵＩＲＩＮＧ＿ＳＡ状態１３６へ移って、プロキシとの認証を再び実施するための新しいＳＡを獲得する。
【００２４】
先に述べたとおり、ユーザの認証に対して任意選択でＮＴＬＭ機構を選択することができる。ＮＴＬＭの状態移行はケルベロスの状態移行と概ね同じだが、ＮＴＬＭは、始めに不完全なＳＡだけを獲得し（段階１５８）、不完全なＳＡを第１のメッセージに入れてプロキシに送るという違いがある。具体的には、ＮＴＬＭの場合、ＳＡ関連情報を含むクライアントからの第１のリクエストは、クライアントのセキュリティ関連機能（例えばクライアントがサポートするプロトコルのバージョン、サポートする署名アルゴリズムなど）を伝える。これに応答してプロキシサーバは、そのＮＴＬＭ関連機能および一般に「ｎｏｎｃｅ」と呼ばれるランダムなバイト列を含む自体の認証データを含んだ第２の４０７チャレンジを送る（段階１６０）。これに応答してクライアントは、それ自体の名称およびプロキシによって送られた「ｎｏｎｃｅ」値のハッシュにその証明書を使用して署名する。これは、ＮＴＬＭインプリメンテーションによって内部的に処理される。プロキシサーバは、クライアントの認証データを検証し、ドメインコントローラの助けを借りてセッションキーを得る。ＳＩＰプロキシが意図された受信者でない場合、プロキシは、シグナリング経路上の次のホップにＳＩＰリクエストを転送し、送信側ＳＩＰクライアントへの次のメッセージ（例えば受信者からの２００ＯＫメッセージ）に署名する（段階１４０）。
【００２５】
ＳＩＰクライアントとＳＩＰプロキシの間の認証目的のメッセージ交換に関与するさまざまなＳＩＰヘッダの構文については後に説明する。
【００２６】
（４０７応答）
先に述べたとおり、ＩＮＶＩＴＥメッセージを送ったＳＩＰクライアント（またはそのユーザ）の識別を要求したい場合、ＳＩＰプロキシサーバ７４は、Ｐｒｏｘｙ−Ａｕｔｈｅｎｔｉｃａｔｅヘッダを含む４０７メッセージをクライアントに送る。認証のためにケルベロスセキュリティ機構の使用を必要とする好ましい実施形態のＰｒｏｘｙ−Ａｕｔｈｅｎｔｉｃａｔｅヘッダの構文は以下のとおりである。
【００２７】
ここに記載したＰｒｏｘｙ−Ａｕｔｈｅｎｔｉｃａｔｅヘッダの構文は、「ＨＴＴＰ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ：Ｂａｓｉｃ ａｎｄ Ｄｉｇｅｓｔ Ａｃｃｅｓｓ Ａｕｔｈｅｎｔｉｃａｔｏｎ」という表題のＩＥＴＦ ＲＦＣ ２６１７に定義されている「ＷＷＷ−Ａｕｔｈｅｎｔｉｃａｔｅ Ｒｅｓｐｏｎｓｅ Ｈｅａｄｅｒ」と同様である。この文書はその全体が参照によって本明細書に組み込まれる。任意選択のパラメータ「ａｌｇｏｒｉｔｈｍ」および「ｓｔａｌｅ」は省かれている。ヘッダの「ｓｃｈｅｍｅ」フィールドは、サーバに対して自体を認証するのに、サーバによって提案された認証機構のうちどの認証機構を使用したいかをクライアントが選択することを可能にする。クライアントがケルベロス機構をサポートしている場合には、クライアントはケルベロス機構を選択することが好ましく、サポートしていない場合にはＮＴＬＭ認証機構を選択する。
【００２９】
ｒｅａｌｍパラメータは、ＳＩＰプロキシが属し、クライアントがアクセスしようとしているＳＩＰサービスプロバイダの固有の識別子である。認証のためにユーザが提供する必要がある正しい証明書セットをユーザが識別するのを助けるため、ｒｅａｌｍ列はユーザに表示される。「ｔａｒｇｅｔｎａｍｅ」パラメータは常に必要なパラメータであり、ＳＩＰプロキシのＦＱＤＮを伝達するのに使用される。このパラメータの実際の内容は、クライアントがＳＡを確立しているプロキシを追跡するのを助ける。それは、応答が自体に対するものなのか、または他のプロキシに対するものなのかをプロキシが判定するのを助ける。「ｏｐａｑｕｅ」パラメータは、サーバが、確立されている特定のＳＡに索引をつけるのに使用され、後に説明するように、クライアントがＳＡに対して生成する将来のＰｒｏｘｙ−Ａｕｔｈｏｒｉｚａｔｉｏｎヘッダ中に反映されなければならない。
【００３０】
この実施形態では、ＩＥＴＦ ＲＦＣ２０７８（その全体が参照によって本明細書に組み込まれる）に定義されたＧＳＳ−ＡＰＩ（Ｇｅｎｅｒｉｃ Ｓｅｃｕｒｉｔｙ Ｓｅｒｖｉｃｅ Ａｐｐｌｉｃａｔｉｏｎ ＰｒｏｇｒａｍｍｉｎｇＩｎｔｅｒｆａｃｅ）が実装されており、通信しているアプリケーション間でメッセージを安全に交換するのに使用されるとみなす。ＧＳＳ−ＡＰＩは特に、通信アプリケーションが、別のアプリケーションに関連付けられたユーザを認証することを可能にする。Ｐｒｏｘｙ−Ａｕｔｈｅｎｔｉｃａｔｅヘッダおよび後述するＰｒｏｘｙ−Ａｕｔｈｏｒｉｚａｔｉｏｎヘッダのｇｓｓａｐｉ−ｄａｔａフィールドは、ＮＴＬＭおよびケルベロスセキュリティパッケージを実装したセキュリティＡＰＩによって、ＳＡネゴシエーション段階の間に返されたデータを保持するためのものである。これらのＡＰＩは、クライアントからプロキシへ、およびプロキシからクライアントへ送る必要があるｇｓｓａｐｉデータを返す。ｇｓｓａｐｉデータは、ＳＩＰクライアント／プロキシインプリメンテーションにとって不透明であり、セキュリティＡＰＩだけが解釈することができる。ｑｏｐパラメータは、クライアントが従って欲しいとサーバが欲しているセキュリティのレベルをクライアントに教える。ｑｏｐパラメータ値は常に、この機構によって提供されるセキュリティレベルがユーザの認証であることを指示する「ａｕｔｈ」にセットされている。
【００３１】
Ｐｒｏｘｙ−Ａｕｔｈｅｎｔｉｃａｔｅヘッダフィールドの一例を以下に示す。
【００３２】
Proxy-Authenticate: Negotiate
realm = "Microsoft RTC Service provider",
opaque = "ABCDEF456789"
qop = "auth",
gssapi-data = "ABCD345678yuikjhlbcdfsaqwety"
【００３３】
許可されたクライアントだけを許すとされ、クライアントから着信するＳＩＰパケットが署名を含まない場合には一般に、ＳＩＰプロキシは、ＳＩＰクライアントの識別を要求するであろう。（リブートなどのため）ＳＩＰプロキシがこのＳＩＰ ＵＲＩに対するセキュリティアソシエーションを失った場合にも、ＳＩＰプロキシはクライアントの認証を要求するであろう。クライアントが使用している許可パラメータとＳＩＰプロキシが期待しているものの間にミスマッチがある場合、ＳＩＰプロキシは、クライアントが従って欲しいとＳＩＰプロキシが欲している正確な許可パラメータを運んでいる４０７メッセージを使用して、クライアントの認証を要求するであろう。
【００３４】
（４０７チャレンジに対するクライアントの応答）
４０７チャレンジに応答してＳＩＰクライアントは、４０７チャレンジメッセージを介してＳＩＰプロキシから送られた認証パラメータに従った署名を生成しようとする。ＳＩＰクライアントはＣｓｅｑ値を増分し、チャレンジの対象となった最初のＳＩＰリクエストを、Ｐｒｏｘｙ−Ａｕｔｈｏｒｉｚａｔｉｏｎリクエストヘッダの中に入れられた許可情報とともに再送する。好ましい実施形態におけるＰｒｏｘｙ−Ａｕｔｈｏｒｉｚａｔｉｏｎリクエストヘッダの構文は以下のとおりである。
【００３５】
ここに記載したＰｒｏｘｙ−Ａｕｔｈｏｒｉｚａｔｉｏｎヘッダの構文は、ＩＥＴＦ ＲＦＣ ２６１７に定義されている「Ａｕｔｈｏｒｉｚａｔｉｏｎ Ｒｅｑｕｅｓｔ Ｈｅａｄｅｒ」と同様である。ただし、任意選択のパラメータ「ａｌｇｏｒｉｔｈｍ」および「ＵＲＩ」は省かれている。Ｐｒｏｘｙ−Ａｕｔｈｏｒｉｚａｔｉｏｎヘッダは、リクエストＵＲＩおよびＶｉａヘッダの後に追加される。署名は、セッションキーを使用して、以下のフィールドにわたって計算される。
【００３７】
−ＦｒｏｍヘッダＵＲＩ
−ＴｏヘッダＵＲＩ
−Ｆｒｏｍヘッダタグ
−Ｔｏヘッダタグ
−Ｐｒｏｘｙ−Ａｕｔｈｏｒｉｚａｔｉｏｎヘッダ中の「ｃｒａｎｄ」パラメータ、またはＰｒｏｘｙ−Ａｕｔｈｅｎｔｉｃａｔｉｏｎ−Ｉｎｆｏヘッダ中の「ｓｒａｎｄ」パラメータ
−ＳＩＰメッセージＥｘｐｉｒｅｓヘッダ中のＥｘｐｉｒｅｓ値
署名には、ＳＩＰメッセージのメッセージ本体は含まれていない。ｐｒｏｘｙ−ａｕｔｈｏｒｉｚａｔｉｏｎヘッダは、ｇａｓａｐｉ−ｄａｔａパラメータまたはｒｅｓｐｏｎｓｅ（署名）パラメータを含む。
【００３８】
以下に、４０７チャレンジに対するクライアントの応答におけるＰｒｏｘｙ−Ａｕｔｈｏｒｉｚａｔｉｏｎヘッダの例を示す。
【００３９】
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"
【００４０】
プロキシからの４０７チャレンジに応答するときの他に、クライアントは、自体を初めてＳＩＰプロキシに登録するときにもこのヘッダを送る。ＳＩＰクライアントが自体をプロキシサーバに登録し、セッションのためにセキュリティアソシエーションを初期化するプロセスにあるとき、Ｐｒｏｘｙ−Ａｕｔｈｏｒｉｚａｔｉｏｎヘッダは、「ｇｓｓａｐｉ−ｄａｔａ」パラメータを含む。
【００４１】
（相互認証）
ある種のシナリオでは、ＳＩＰプロキシとＳＩＰクライアントの間で相互認証を確立することが必要である。クライアントは、特定のプロキシサーバに対してクライアントが有する準備プロファイルから、相互認証が必要か否かを判断する。相互認証が使用可能な場合、クライアントは、ＧＳＳ ＡＰＩの標準バージョンを使用して相互認証のためのセキュリティアソシエーションを初期化する。相互認証が使用可能な場合にはさらに、サーバが、ＳＩＰクライアントに送る全てのパケットに署名する必要がある。この署名は、Ｐｒｏｘｙ−Ａｕｔｈｅｎｔｉｃａｔｉｏｎ−Ｉｎｆｏｒｍａｔｉｏｎリクエストヘッダに入れて運ばれる。Ｐｒｏｘｙ−Ａｕｔｈｅｎｔｉｃａｔｅ−Ｉｎｆｏｒｍａｔｉｏｎの構文は以下のとおりである。
【００４２】
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
【００４３】
Ｐｒｏｘｙ−Ａｕｔｈｅｎｔｉｃａｔｉｏｎ−Ｉｎｆｏヘッダ中の「ｒｓｐａｕｔｈ」パラメータは、この応答に対する（認証を求めているプロキシの）署名を運ぶ。「ｓｒａｎｄ」パラメータは、ＳＡ確立段階後にサーバが、クライアントに送るメッセージに署名するのに使用される。このパラメータは、サーバによって生成されるランダムな文字列であり、生成されたメッセージのハッシュ／署名にランダム性の要素を導入するのに使用される。
【００４４】
以下に、Ｐｒｏｘｙ−Ａｕｔｈｅｎｔｉｃａｔｉｏｎ−Ｉｎｆｏｒｍａｔｉｏｎヘッダの一例を示す。
【００４５】
Proxy-Authentication-Info: Negotiate
realm = "Microsoft RTC Service Provider",
qop = "auth",
rspauth = "ABCD87564cvx",
srand = "9876543210",
targetuame = "serverl.domainA.microsoft.com"
【００４６】
ＳＩＰフレームワークでは一般に、ＲＥＧＩＳＴＥＲリクエストを使用した登録プロセスの間に、ＳＩＰクライアントが、ＳＩＰプロキシとのセキュリティアソシエーションを確立することができる。登録によってＳＩＰクライアントは、ＳＩＰプロキシからメッセージを受け取ることができるようになる。ＳＩＰクライアントが自体をＳＩＰプロキシに登録するときには、ＳＩＰクライアントは同時に、ケルベロスチケットなどの認証データをＲＥＧＩＳＴＥＲメッセージに入れて送ることによって、自体のユーザをＳＩＰプロキシサーバに対して認証することができる。ＳＩＰクライアントがＳＩＰプロキシにすでに登録されており、かつＳＩＰプロキシに対して認証されている場合、ＩＮＶＩＴＥなどのＳＩＰリクエストをクライアントが送るときには、クライアントからのリクエストメッセージが、ＳＡ確立プロセスの間に交換されたケルベロスセッションキーを使用して署名される。
【００４７】
とは言え、自体をサーバに登録しなくても、ＳＩＰクライアントはリクエストメッセージをＳＩＰプロキシに送ることができる。呼出し元がプロキシに対して認証されていない場合には（たとえＳＩＰクライアントがプロキシに登録されている場合であっても）、ＳＩＰプロキシはそのリクエストを次のホップに転送しない。その代わりにプロキシは、ＳＩＰクライアントにチャレンジを送る。
【００４８】
このチャレンジは、クライアントがこのＳＩＰサーバと、セキュリティアソシエーションを確立する必要があることを指示する。クライアントは、セキュリティアソシエーションデータを含むリクエストを再び送ることによってＳＡを確立することができ、あるいは、登録はすでにされているが、ＳＡがまだ確立されていない場合には、このサーバへの自体の登録をリフレッシュすることによってＳＡを確立することができる。登録リフレッシュを使用してＳＡを確立し、次いで有効な署名を有するＳＩＰリクエストを送ることには、登録が良好な状態にあることが保証されるという利点がある。
【００４９】
さらに、ＳＩＰクライアントがＳＩＰプロキシに対する登録を抹消するたびに、ＳＩＰクライアントとＳＩＰプロキシの間のセキュリティアソシエーション（ＳＡ）は失われ、新しいセキュリティアソシエーションを再び交渉し直さなければならない。さらに、ＳＩＰクライアントの登録が失効すると、プロキシサーバは、対応するセキュリティコンテキストをＳＡのリストから削除する。登録をリフレッシュするたびに、ＳＩＰクライアントは、認証セキュリティアソシエーションもリフレッシュしなければならない。
【００５０】
ケルベロスプロトコルに基づくセキュリティ機構を使用する好ましい実施形態では、送信側ＳＩＰクライアントのユーザの認証がＳＩＰプロキシ／レジストラによって要求された場合に、ＳＩＰクライアントがＳＩＰプロキシに登録するたびに、ケルベロスキーディストリビューションセンター（ＫＤＣ）からのケルベロスチケットが要求される。ケルベロスチケットを受け取ると、ＳＩＰクライアントはこのチケットを解読する。解読されたチケットは、セッションキーおよびこのケルベロスセッションの他のいくつかの特性を含む。このチケットはさらに、サーバの証明書で暗号化されたセッションキーおよび他のセッション関連パラメータを含む。この部分は、ｇｓｓａｐｉ−ｄａｔａフィールドの、ｐＯｕｔｐｕｔパラメータに入れて返され、ｒｅ−ＩＮＶＩＴＥリクエストに入れてプロキシに送られる。
【００５１】
ＳＩＰフレームワーク内でのセキュリティ機構のオペレーションの明瞭な理解を容易にするため、クライアント・プロキシのケルベロス認証の具体的な例を図２を参照して説明する。この例では、ＳＩＰプロキシサーバ７４が、ドメイン「ｄｏｍａｉｎＡ．Ｍｉｃｒｏｓｏｆｔ．ｃｏｍ：Ｓ＿ｓｅｒｖｅｒ１」のＫＤＣ１７０との共有秘密鍵をすでに生成していると仮定する。この例では「ｓｅｒｖｅｒ１」が、ＳＩＰプロキシ／レジストラのコード名として使用される。ＫＤＣ１７０は、プロキシサーバ７４がｓｅｒｖｅｒ＿ＩＤ＝ｓｅｒｖｅｒ１．ｄｏｍａｉｎＢ．ｍｉｃｒｏｓｏｆｔ．ｃｏｍであると知っている。プロキシサーバ７４はさらに、証明書ハンドルを獲得して、クライアントから来る認証リクエストに応答する準備を整える。サーバ証明書は、サーバ認証または相互認証をサポートしているセキュリティプロトコルにおいてＳＩＰクライアント７４に対してプロキシサーバ７４を認証するのに使用される。プロキシサーバ７４は、このサーバを起動するのに使用されるサービスアカウントによって定義されるその証明書に対するハンドルを取得する。サーバはこのハンドルを、ＳＳＰＩ（Ｓｅｃｕｒｉｔｙ Ｓｕｐｐｏｒｔ Ｐｒｏｖｉｄｅｒ Ｉｎｔｅｒｆａｃｅ）の関数ＡｃｑｕｉｒｅＣｒｅｄｅｎｔｉａｌｓＨａｎｄｌｅを呼び出すことによって取得する。
【００５２】
図２の例では、ＳＩＰクライアント７２のユーザ７６がアンである。アンは、ＮＴドメインにアカウントを有し、一日の始まりに、以下の情報を使用して自分のアカウントにログオンする。
【００５３】
UserID / principal name = ann@microsoft.com
Preferred_email = ann@microsoft.com
User_domain = domainA.Microsoft.com
Workstation = ann1.domainA.Microsoft.com
【００５４】
ボブと通話したいとき、アンは、自分のワークステーション７８上のＳＩＰクライアント７２を起動する（ＳＩＰクライアントはサービスとして自動的に起動することができる。ただしユーザのセキュリティコンテキストで走らなければならない）。ＳＩＰクライアント７２は、ＤＮＳを使用してアウトバウンドプロキシサーバ７４を見つける。この例で使用するアウトバウンドプロキシサーバ７４は、Ｓｅｒｖｅｒ１．ｄｏｍａｉｎＢ．Ｍｉｃｒｏｓｏｆｔ．ｃｏｍとして識別される。アンは、自分がｂｏｂ＠ｍｉｃｒｏｓｏｆｔ．ｃｏｍと通話したいことを指示する。アンのＳＩＰクライアント７２は次いで、Ｓｅｒｖｅｒ１．ｄｏｍａｉｎＢ．Ｍｉｃｒｏｓｏｆｔ．ｃｏｍにＩＮＶＩＴＥメッセージ８２を送る。ＩＮＶＩＴＥメッセージは以下の情報を含む。
【００５５】
INVITE bob@microsoft.com
From: ann@microsoft.com
To: bob@microsoft.com
【００５６】
この例の説明を簡潔かつ明瞭に保つため、このＩＮＶＩＴＥメッセージまたはシグナリング処理で交換される他のメッセージに含まれる全てのデータを示すわけではない。ＳＩＰプロキシサーバ７４は、Ｍｉｃｒｏｓｏｆｔ．ｃｏｍのユーザ名空間に対してなされた呼に対する全てのＩＮＶＩＴＥリクエストが認証されることを必要とするように構成されている。その結果、ＳＩＰプロキシサーバ７４はＩＮＶＩＴＥリクエストに応答して、ケルベロスを使用してユーザ（アン）を認証するようＳＩＰクライアント７４に求める４０７メッセージ９６を送る。４０７メッセージは以下のデータを含む。
【００５７】
Proxy-Authenticate: Kerberos realm = domainB.microsoft.com
targetname = "serverl.domainA.Microsoft.com" opaque = "someopaquedata"
【００５８】
ｏｐａｑｕｅ値は、この呼に対して使用するセキュリティコンテキストを識別するためにプロキシによって初期化される。そのために、プロキシサーバ７４はこのとき、関数ＡｃｃｅｐｔＳｅｃｕｒｉｔｙＣｏｎｔｅｘｔを呼び出し、ｐＯｕｔｐｕｔをｂａｓｅ６４でコード化した結果をｏｐａｑｕｅに入れて返す。クライアントおよびサーバは、このｏｐａｑｕｅ値を使用して、認証の継続、またはＡｕｔｈｏｒｉｚａｔｉｏｎリクエストヘッダを使用した同じサーバへの以降のリクエストの再認証のため特定のサーバに対して使用するセキュリティコンテキストを識別する。
【００５９】
アンのワークステーション上のＳＩＰクライアント７２は、認証が必要であることを指示する４０７メッセージ９６を受け取ると、Ｓｅｒｖｅｒ１．ｄｏｍａｉｎＢ．Ｍｉｃｒｏｓｏｆｔ．ｃｏｍと交信するための有効なセッションキーを持っているかどうかをチェックする。まだ所有していない場合には、このドメイン内のＫＤＣと接触して、アウトバウンドＳＩＰプロキシにアクセスするのためのセッションキーを取得する必要がある。この例では、４０７メッセージの中に指定されたｒｅａｌｍからクライアントは、自体のドメインとは異なるドメインにプロキシがあることを知る。
【００６０】
プロキシサーバ７４への安全な接続を確立するため、クライアント７２は、認証リクエストをプロキシに送る前にアウトバウンド証明書ハンドルを獲得する。これは、関数ＳＳＰＩを呼び出すことによって実行される。ＳＳＰＩは、ネットワーク化されたアプリケーションが、いくつかあるうちの１つのセキュリティサポートプロバイダ（ＳＳＰ）にコールして、認証済みの接続を確立し、確立された接続を介してデータを安全に交換する手段を提供する。認証セットアップに関与する２つのクライアント側ＳＳＰＩ関数がある。ＡｃｑｕｉｒｅＣｒｅｄｅｎｔｉａｌｓＨａｎｄｌｅ関数は、以前に取得したログオン証明書への参照を取得する。関数ＩｎｉｔｉａｌｉｚｅＳｅｃｕｒｉｔｙＣｏｎｔｅｘｔは、最初の認証リクエストセキュリティトークンを生成する。ＩｎｉｔｉａｌｉｚｅＳｅｃｕｒｉｔｙＣｏｎｔｅｘｔを呼び出すと、４０７メッセージから取得したｏｐａｑｕｅ値がｐＩｎｐｕｔに入れて渡される。クライアントは、この関数のｔｆＣｏｎｔｅｘｔＲｅｑパラメータをリクエストＭＵＴＵＡＬ＿ＡＵＴＨにセットする。ｐｆＣｏｎｔｅｘｔＡｔｔｒポインタは、ｍｕｔｕａｌ−ａｕｔｈが「リクエスト」されたことをケルベロスモジュール１８０がクライアントに知らせる方法である。この情報は、クライアントのケルベロスモジュール１８０によって生み出されるＫＥＲＢ＿ＡＳ＿ＲＥＱの一部であり、クライアントが相互認証を求めていることをサーバ（ここではＳＩＰプロキシ）に知らせるｓｅｃＢｕｆｆｅｒ（ｐＯｕｔｐｕｔ）に入れて渡される。これはＫＥＲＢリクエストの一部なので、ＳＩＰ機構（ヘッダ／パラメータ）が相互認証を要求する必要はない。
【００６１】
図２に示した例では、ＡＰＩ関数ＩｎｉｔｉａｌｉｚｅＳｅｃｕｒｉｔｙＣｏｎｔｅｘｔを呼び出すことによって、以下のケルベロス論理が生じる。最初にクライアント７２が、ＤｏｍａｉｎＢ（ドメインＢ）のプロキシサーバ７４へのサーバチケットをクライアント７２に与えるよう、ｄｏｍａｉｎＡ．Ｍｉｃｒｏｓｏｆｔ．ｃｏｍドメインのＫＤＣ１７０に求める。ｄｏｍａｉｎＡ．Ｍｉｃｒｏｓｏｆｔ．ｃｏｍのＫＤＣ１７０はクライアント７２に、ｃｏｒｐ．Ｍｉｃｒｏｓｏｆｔ．ｃｏｍのＫＤＣ１７２への照会チケットを送る。この照会チケットは、この２つのＫＤＣによって共有されたドメイン間キーの中に暗号化されている。この照会チケットを使用して、クライアントは、ＤｏｍａｉｎＢにあるサーバへのサーバチケットをクライアントに与えるよう、ｃｏｒｐ．Ｍｉｃｒｏｓｏｆｔ．ｃｏｍのＫＤＣ１７２に求める。
【００６２】
これに応答してＫＤＣ１７２は、ＤｏｍａｉｎＢのＫＤＣ１７６への照会チケットをクライアントに送る。このチケットは、ＫＤＣ１７２がＤｏｍａｉｎＢのＫＤＣ１７６と共有するドメイン間キーの中に暗号化されている。クライアントは次いで、ＤｏｍａｉｎＢにあるプロキシサーバ７４へのチケットをクライアントに与えるよう、ＤｏｍａｉｎＢのＫＤＣ１７６に求める。ＫＤＣ１７６は、プロキシサーバ７４にアクセスするためのサーバチケット１０８をクライアントに送る。ＫＤＣ１７６は、アンのログオンセッションキーを用いてこのセッションキーの１つのコピーを暗号化し、セッションキーの別のコピーをアンの許可データとともにサーバチケットに埋め込み、プロキシサーバの長期キーを用いてサーバチケットを暗号化する。ＫＤＣ１７６は次いで、これらの証明書を、Ｋｅｒｂｅｒｏｓ Ｔｉｃｋｅｔ−Ｇｒａｎｔｉｎｇ Ｓｅｒｖｉｃｅ Ｒｅｐｌｙ（ＫＲＢ＿ＴＧＳ＿ＲＥＰ）に入れてクライアント７２に送る。
【００６３】
このように、ＩｎｉｔｉａｌｉｚｅＳｅｃｕｒｉｔｙＣｏｎｔｅｘｔを呼び出すことによって、クライアントマシンのケルベロスモジュール１８０がＫＤＣとのＴＧＳ交換を開始する。この交換によって返される値は、プロキシに送るメッセージに署名するためのセッションキーである。
【００６４】
その後、ＳＩＰクライアント７２は、ＳＩＰプロキシに送る新しいＩＮＶＩＴＥメッセージ１１０（「ｒｅ−ＩＮＶＩＴＥ」メッセージとも呼ばれる）を生成する。この新しいＩＮＶＩＴＥメッセージ１１０は、クライアントがＫＤＣ１７６から受け取ったサーバチケットを含むＧＳＳ−ＡＰＩデータをその中に含んだ、先に説明したｐｒｏｘｙ−ａｕｔｈｏｒｉｚａｔｉｏｎヘッダを含む。セッションキーは、ＩｎｉｔｉａｌｉｚｅＳｅｃｕｒｉｔｙＣｏｎｔｅｘｔ呼出しによって返されたｐＯｕｔｐｕｔバッファの中に入れて返された値である。したがって、新しいＩＮＶＩＴＥメッセージ１１０は以下のデータを含む。
【００６５】
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
【００６６】
このＩＮＶＩＴＥメッセージは、プロキシサーバに対してＫＲＢ＿ＡＰ＿ＲＥＱと等価の内容を実行する。
【００６７】
メッセージの完全性を保護し、自体を認証する（すなわちメッセージの出処を証明する）ため、クライアントは、セッションキーを用いてＩＮＶＩＴＥメッセージ１１０に署名する。さもないと、第三者がこのＩＮＶＩＴＥメッセージをかぎつけ、ＯｐａｑｕｅおよびＧｓｓａｐｉ−ｄａｔａ値を手に入れ、偽のＩＮＶＩＴＥメッセージを同じサーバに送って、この第三者とそれが選択した任意の転送先との間で通話をおこなう可能性がある。このことは、サーバへのセッションキーが有効である間（デフォルトでは８時間）、クライアントの認証を「盗む」ことができることを意味する。ＩＮＶＩＴＥメッセージに署名することで、第三者がＯｐａｑｕｅおよびＧｓｓａｐｉ−ｒｄａｔａを取り出すことを防ぐことはできないが、新しいＩＮＶＩＴＥメッセージを生成して好き勝手に通話することは防ぐことができる。この問題を回避するためには、サーバが、署名されたリクエストしか受け入れないように構成されていなければならない。
【００６８】
クライアント７２は、ＭａｋｅＳｉｇｎａｔｕｒｅ ＡＰＩを使用し、これを呼び出して、（４０７メッセージのｏｐａｑｕｅ中に識別された）この呼出しで使用されるセキュリティコンテキストにｐｈＣｏｎｔｅｘｔをセットし、その内容を渡してｐＭｅｓｓａｇｅに署名する。この呼出しの出力は、ｐＭｅｓｓａｇｅの中に返された署名されたメッセージである。クライアントは、この署名をＩＮＶＩＴＥ１１０に追加する。再送されたＩＮＶＩＴＥメッセージ１１０を受け取ると、プロキシサーバ７４は、Ｐｒｏｘｙ−Ａｕｔｈｏｒｉｚａｔｉｏｎヘッダの中のｏｐａｑｕｅ値をチェックし、所与のｐｈＣｏｎｔｅｘｔ値（所与のセキュリティコンテキストへのハンドル）と相関させる。プロキシサーバ７４は、ｇｓｓａｐｉ−ｒｄａｔａを取り出し、ＡｃｃｅｐｔＳｅｃｕｒｉｔｙＣｏｎｔｅｘｔＡＰＩ関数を呼び出し、ｐｒｏｘｙ−ａｕｔｈｏｒｉｚａｔｉｏｎヘッダから得たｇｓｓａｐｉ−ｒｄａｔａ値をこのＡＰＩ関数のｐＩｎｐｕｔ成分の中に渡すことによって、これを自体のケルベロスモジュール１８２を渡す。ケルベロスモジュール１８２は、プロキシの長期キーを使用してサーバチケットを解読し、アンの許可データおよびセッションキーを抜き出す。ケルベロスモジュール１８２は、セッションキーを使用してアンのオーセンティケータ（ａｕｔｈｅｎｔｉｃａｔｏｒ）を解読し、次いで中のタイムスタンプを評価する。
【００６９】
オーセンティケータがこのテストにパスした場合、ケルベロスモジュール１８２は、クライアントのリクエストの中の相互認証フラグを探す。フラグがセットされている場合、ケルベロスモジュール１８２はセッションキーを使用して、アンのオーセンティケータからの時刻を暗号化し、その結果を、ＫｅｒｂｅｒｏｓＡｐｐｌｉｃａｔｉｏｎ Ｒｅｐｌｙ（ＫＲＢ＿ＡＰ＿ＲＥＰ）の中に返す。これによって、ＡｃｃｅｐｔＳｅｃｕｒｉｔｙＣｏｎｔｅｘｔが呼び出され、ＳＥＣ＿Ｅ＿ＯＫ戻り値が返され、オーセンティケータはｐＯｕｔｐｕｔバッファを使用してこのＡＰＩを通過する。ユーザが認証されると、ＳＩＰプロキシ／レジストラはこのリクエストを処理し、ＩＮＶＩＴＥメッセージを、ＳＩＰシグナリング経路上の次のホップに転送する。
【００７０】
プロキシのＳＩＰコンポーネントは次いで、ＳＩＰクライアントに転送する次のメッセージを使用してプロキシのオーセンティケータをクライアントに渡し、これによってクライアントがサーバを認証できるようにする。示された例では、このメッセージが「２００ＯＫ」メッセージである。このメッセージは、ＳＩＰプロキシによって生成されたものではない。この２００応答は、ＩＮＶＩＴＥリクエストに応答して呼出し先が生成する。ＳＩＰプロキシは単に、呼出し元に転送する前にセッションキーを用いてこの応答に署名するだけである。
【００７１】
先に説明したとおり、オーセンティケータは、Ｐｒｏｘｙ−Ａｕｔｈｅｎｔｉｃａｔｉｏｎ−Ｉｎｆｏｒｍａｔｉｏｎヘッダの中にある。このヘッダはさらに、クライアントが、この応答を正しいセキュリティコンテキストと一致させるためのｏｐａｑｕｅ値を含む。
【００７２】
アンのワークステーション上のＳＩＰクライアント７２は、「２００ＯＫ」メッセージを受け取ると、Ｐｒｏｘｙ−Ａｕｔｈｅｎｔｉｃａｔｉｏｎ−Ｉｎｆｏｒｍａｔｉｏｎヘッダを抜き出し、ＩｎｉｔｉａｌｉｚｅＳｅｃｕｒｉｔｙＣｏｎｔｅｘｔを呼び出す。ｐｈＣｏｎｔｅｘｔ値はｏｐａｑｕｅの中の値にセットされ、ｐＩｎｐｕｔバッファはｒｅｓｐｏｎｓｅ−ｄｉｇｅｓｔにセットされる。クライアント上のケルベロスモジュール１８０は、プロキシと共有するセッションキーを用いてプロキシのオーセンティケータを解読し、プロキシによって返された時刻を、クライアントのオリジナルのオーセンティケータの中の時刻と比較する。２つの時刻が一致した場合、このＩｎｉｔｉａｌｉｚｅＳｅｃｕｒｉｔｙＣｏｎｔｅｘｔの呼出しはＳＥＣ＿Ｅ＿ＯＫを返し、クライアントは、プロキシが本物であることを知る。一致しない場合にはクライアントはこの呼を取りやめなければならない。クライアントは、要求したことをサーバが実行すると信じることができないので、ＣＡＮＣＥＬを送ってこの呼を強制終了せざるを得ない。
【００７３】
上に説明した例では、認証が、まず最初にＳＩＰクライアントが認証データを含まないＩＮＶＩＴＥを送り、次いで、認証が必要であることを指示するプロキシからの４０７メッセージに応答して認証データを別のＩＮＶＩＴＥに入れて送るシナリオで実施される。その代わりにクライアントは、プロキシに送る最初のＩＮＶＩＴＥに必要な認証データを含めることもできる。そのためにクライアント７２は、ＳＩＰの下で通話するためにユーザが使用する前に、プロキシに対するサーバチケットをＫＤＣ１７６から取得する。次いで必要な認証データを、先に説明したＰｒｏｘｙ−Ａｕｔｈｏｒｉｚａｔｉｏｎリクエストヘッダに入れる。こうすることによって、プロキシがクライアントに４０７チャレンジを送って認証データを要求する必要がなくなる。さらに、先に説明した認証オペレーションの例ではＳＩＰプロキシが１つしか関与していないが、呼出し元と呼出し先の間のＳＩＰシグナリング経路上には一般に複数のＳＩＰプロキシがあり、２つ以上のＳＩＰプロキシが、呼出し元クライアントの認証を要求する可能性がある。例えば、図５に示す単純化されたケースでは、ＳＩＰクライアントのアウトバウンドプロキシサーバ７４の他に別のＳＩＰプロキシサーバ１２０があり、両方のプロキシが、ＩＮＶＩＴＥメッセージを転送する前にクライアントの認証を必要とする。この場合には、クライアント７２がまず、図４に関して先に説明した同じプロセスを経て、アウトバウンドＳＩＰサーバ７４に対して自体を認証する。クライアントを認証した後、プロキシサーバ７４は第２のプロキシ１２０にＩＮＶＩＴＥを送り、第２のプロキシ１２０は次いで、クライアントに４０７チャレンジ１９０を送る。これに応答してクライアントは、第２のプロキシサーバ１２０用のケルベロスサーバチケットを含んだＰｒｏｘｙ−Ａｕｔｈｏｒｉｚａｔｉｏｎヘッダを有する別の新しいＩＮＶＩＴＥ１９２を送る。クライアントを認証した後、第２のプロキシは呼出し先にＩＮＶＩＴＥ１９２を渡す。
【００７４】
以下の説明は、ケルベロスまたはＮＴＬＭセキュリティ機構に基づいて認証を実行するさまざまなメッセージフローのシナリオにおいて、Ｐｒｏｘｙ Ａｕｔｈｅｎｔｉｃａｔｅ、Ｐｒｏｘｙ ＡｕｔｈｏｒｉｚａｔｉｏｎおよびＰｒｏｘｙ−Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｉｎｆｏｒｍａｔｉｏｎヘッダをどのように使用するかを説明する追加の例を提供する。図６を参照する。このケースでは、ＳＩＰクライアント７２が、体をプロキシサーバに登録するときにケルベロスベースのプレ認証を実行する。クライアントは、プロキシに対するケルベロスサーバチケットを含むＰｒｏｘｙ−Ａｕｔｈｏｒｉｚａｔｉｏｎヘッダを含むＲＥＧＩＳＴＥＲリクエスト２００、および先に説明した相互認証のためのリクエストを送る。サーバチケットに基づいてクライアントを認証した後、プロキシは、クライアントが使用してプロキシを認証することができるプロキシ認証データを含むＰｒｏｘｙ−Ａｕｔｈｅｎｔｉｃａｔｉｏｎ−Ｉｎｆｏｒｍａｔｉｏｎヘッダとともに、２００ＯＫメッセージ２０２を返す。ＲＥＧＩＳＴＥＲおよび２００ＯＫメッセージの内容の例を以下に示す。
【００７５】
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
【００７６】
図７に、ケルベロスベースのチャレンジド認証（ｃｈａｌｌｅｎｇｅｄ ａｕｔｈｅｎｔｉｃａｔｉｏｎ）のシナリオを示す。この例では、クライアント７２がまず、Ｐｒｏｘｙ−Ａｕｔｈｏｒｉｚａｔｉｏｎ情報を含まないＩＮＶＩＴＥ２０６をプロキシ７４に送る。プロキシはこれに応答して、認証が必要であることを指示するＰｒｏｘｙ−Ａｕｔｈｅｎｔｉｃａｔｅヘッダを含む４０７メッセージ２０８を送る。この４０７メッセージに応答してクライアントは、必要なケルベロス認証データを含むＰｒｏｘｙ−Ａｕｔｈｏｒｉｚａｔｉｏｎヘッダを有するＲＥＧＩＳＴＥＲリクエスト２１０を送る。プロキシは、プロキシ自体についての認証情報を含むＰｒｏｘｙ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｉｎｆｏｒｍａｔｉｏｎヘッダを有する「２００ＯＫ」メッセージ２１２を返す。Ｐｒｏｘｙ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｉｎｆｏｒｍａｔｉｏｎヘッダの中のデータに基づいてプロキシを認証した後、クライアントは、Ｐｒｏｘｙ−Ａｕｔｈｏｒｉｚａｔｉｏｎヘッダを有する第２のＩＮＶＩＴＥ２１４を送る。このプロセスの例示的なメッセージを以下に示す。
【００７７】
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
【００７８】
次に図８を参照する。先に述べたとおり、好ましい実施形態では任意選択で、クライアント・プロキシ認証にＮＴＬＭセキュリティ機構を使用することができる。この場合、クライアントがまず、認証データを含まないＩＮＶＩＴＥメッセージ２２０を送り、プロキシが４０７メッセージを返す。この４０７メッセージ２２２のＰｒｏｘｙ Ａｕｔｈｅｎｔｉｃａｔｅヘッダは、認証に対してＮＴＬＭを使用しなければならないことを指示する。次いでクライアントが、ＮＴＬＭプロトコルに基づくクライアントの認証データを含むＰｒｏｘｙ Ａｕｔｈｅｎｔｉｃａｔｉｏｎヘッダを有するＲＥＧＩＳＴＥＲメッセージ２２４を送る。
【００７９】
図４の状態機械に関連して先に述べたとおり、クライアントによって送られた認証データによって、プロキシはクライアントを認証することができるが、この認証データに基づいてセキュリティアソシエーションは完全には確立されない。そのためプロキシは、Ｐｒｏｘｙ Ａｕｔｈｅｎｔｉｃａｔｅヘッダをやはり含む別の４０７チャレンジ２２６をクライアントに送る。クライアントは次いで、セキュリティアソシエーションを完成させるのに必要な認証データを含むＰｒｏｘｙ Ａｕｔｈｏｒｉｚａｔｉｏｎヘッダを有する別のＲＥＧＩＳＴＥＲリクエスト２２８を送る。プロキシサーバは、第２のＲＥＧＩＳＴＥＲリクエストの中のデータに基づいてセキュリティアソシエーションを完成させ、プロキシについての認証データを含むＰｒｏｘｙ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｉｎｆｏｒｍａｔｉｏｎヘッダを有する「２００ＯＫ」メッセージ２３２を返す。「２００ＯＫ」メッセージ２３２の中の認証データに基づいてクライアントはプロキシを認証し、次いで別のＩＮＶＩＴＥメッセージ２３６を送る。このプロセスの例示的なメッセージを以下に示す。
【００８０】
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
【００８１】
図９に、ＮＴＬＭベースのプレ認証のシナリオを示す。このケースのメッセージフローは、ケルベロスベースのプレ認証のそれに似ているが、４０７チャレンジおよびＲＥＧＩＳＴＥＲメッセージが追加されている点が異なる。具体的にはクライアントが、ＮＴＬＭを使用することを指示し、ＮＴＬＭ認証データを含むＰｒｏｘｙ Ａｕｔｈｏｒｉｚａｔｉｏｎヘッダを含むＲＥＧＩＳＴＥＲメッセージ２４０および相互認証のためのリクエストを送る。プロキシは、受け取ったＮＴＬＭ認証データに基づいてクライアントを認証し、Ｐｒｏｘｙ Ａｕｔｈｅｎｔｉｃａｔｅヘッダを有する４０７チャレンジ２４２を返す。クライアントは次いで、プロキシとのセキュリティアソシエーションを完成するためのＮＴＬＭ認証データを含むＰｒｏｘｙ Ａｕｔｈｏｒｉｚａｔｉｏｎヘッダを有する第２のＲＥＧＩＳＴＥＲリクエスト２４４を送る。プロキシは次いで、Ｐｒｏｘｙ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｉｎｆｏｒｍａｔｉｏｎを有する「２００ＯＫ」メッセージ２４６を返す。プロキシを認証した後、クライアントはプロキシに第２のＩＮＶＩＴＥメッセージ２４８を送る。このプロセスの例示的なメッセージを以下に示す。
【００８２】
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
【００８３】
本発明の原理を適用することができる多くの可能な実施形態があることを考慮すれば、図面に関して本明細書に記載した実施形態は例示的なものであって、本発明の範囲を限定するものと解釈してはならないことが認識される。例えば、ソフトウェア（またはハードウェア）として示した記載の実施形態の要素をハードウェア（またはソフトウェア）として実装することができること、または本発明の趣旨から逸脱することなく記載の実施形態の配置および詳細を修正することができることを当業者は認識しよう。したがって本明細書に記載した発明は、前記請求項およびその等価物の範囲に含まれる全ての実施形態を企図する。
【００８４】
【発明の効果】
ケルベロスプロトコル、ＮＴＬＭプロトコルなどのセキュリティ機構を、ＳＩＰシグナリングオペレーションのメッセージフローに組み込んで、ＳＩＰクライアントとＳＩＰプロキシが相互に認証できるようにするための方式が提供される。
【図面の簡単な説明】
【図１】本発明を実現することができる例示的なコンピュータシステムを概略的に示すブロック図である。
【図２】セッションシグナリング段階中に相互認証するＳＩＰクライアントとＳＩＰプロキシサーバを含むセッションイニシエーションプロトコル（ＳＩＰ）システムを示す概略図である。
【図３】ＳＩＰクライアントとＳＩＰプロキシサーバの間の認証目的のシグナリングメッセージ交換を示す概略図である。
【図４】ＳＩＰのフレームワークに組み込まれたセキュリティ機構のオペレーションを表す状態機械を示す概略図である。
【図５】ＳＩＰクライアントが複数のＳＩＰプロキシと認証オペレーションを実行するためのシグナリングメッセージ交換を示す概略図である。
【図６】ケルベロスセキュリティ機構を使用したＳＩＰクライアントとプロキシの間のプレ認証プロセスにおけるメッセージフローを示す概略図である。
【図７】ケルベロスセキュリティ機構を使用したＳＩＰクライアントとプロキシの間のチャレンジド認証プロセスにおけるメッセージフローを示す概略図である。
【図８】ＮＴＬＭセキュリティ機構を使用したＳＩＰクライアントとプロキシの間のチャレンジド認証プロセスにおけるメッセージフローを示す概略図である。
【図９】ＮＴＬＭセキュリティ機構を使用したＳＩＰクライアントとプロキシの間のプレ認証プロセスにおけるメッセージフローを示す概略図である。
【符号の説明】
２０ パーソナルコンピュータ
２１ 処理ユニット
２２ システムメモリ
２３ システムバス
２４ ＲＯＭ
２５ ＲＡＭ
２７ ハードディスクドライブ
２８ 磁気ディスクドライブ
３０ 光ドライブ
３２ ハードディスクドライブインタフェース
３３ 磁気ディスクドライブインタフェース
３４ 光ディスクドライブインタフェース
３５ オペレーティングシステム
３６ アプリケーションプログラム
３７ その他のプログラムモジュール
３８ プログラムデータ
４０ キーボード
４２ マウス
４６ シリアルポートインタフェース
４７ モニタ
４８ ビデオアダプタ
４９ リモートコンピュータ
５０ メモリ記憶装置
５１ ローカルエリアネットワーク
５２ ワイドエリアネットワーク
５３ ネットワークインタフェース
５４ モデム
７２ ＳＩＰクライアント
７４ ＳＩＰプロキシサーバ
７６、８０ ユーザ
８２ ＩＮＶＩＴＥメッセージ
８６ ＳＩＰクライアント
８８ ワークステーション
９０ シグナリング経路
９６ ４０７チャレンジメッセージ
１０２ ドメインコントローラ
１０８ サーバチケット
１１０ ＩＮＶＩＴＥメッセージ
１１６ セッションキー
１２０ ＳＩＰプロキシサーバ
１２２ ２００ＯＫメッセージ
１７０、１７２、１７６ ＫＤＣ
１８０、１８２ ケルベロスモジュール
Claims (22)
- セッションイニシエーションプロトコル（ＳＩＰ）プロキシを介してセッションを開始することに関連してＳＩＰクライアントとＳＩＰプロキシの間の相互認証をするための方法であって、
前記ＳＩＰクライアントから前記ＳＩＰプロキシに第１のＩＮＶＩＴＥリクエストを送信するステップと、
前記ＳＩＰプロキシが前記第１のＩＮＶＩＴＥリクエストを受信したことに応答して、ＳＩＰプロキシのセキュリティコンテキストを含むチャレンジメッセージを前記ＳＩＰクライアントに送信するステップと、
前記ＳＩＰクライアントが前記チャレンジメッセージを受信したことに応答して、
前記ＳＩＰクライアントのドメインコントローラーから前記ＳＩＰプロキシのセッションキーとサーバーチケットとを取得するステップであって、該セッションキーは前記ＳＩＰクライアントのキーで暗号化されており、該サーバーチケットはＳＩＰプロキシの長期キーで暗号化されていてＳＩＰクライアントの認証データを含んでいるステップと、
前記ＳＩＰクライアントの前記キーに基づいて前記セッションキーを解読するステップと、
前記セッションキーによって署名され、かつ前記サーバーチケット及びＳＩＰプロキシのセキュリティコンテキストを含む第２のＩＮＶＩＴＥリクエストを前記ＳＩＰプロキシに送信するステップと、
前記ＳＩＰプロキシが前記第２のＩＮＶＩＴＥリクエストを受信したことに応答して、
前記ＳＩＰプロキシの前記長期キーに基づいて前記サーバーチケットを解読するステップと、
前記サーバーチケット内のＳＩＰクライアントの認証データが、前記ＳＩＰクライアントが信頼のおけるものであること、前記第２のＩＮＶＩＴＥリクエストに含まれるセキュリティコンテキストがＳＩＰプロキシのセキュリティコンテキストに合致するものであること、及び前記第２のＩＮＶＩＴＥリクエストが前記セッションキーによって署名されていることを示す場合に、前記第２のＩＮＶＩＴＥリクエストに基づいてＩＮＶＩＴＥリクエストを所望のサーバーに送信するステップと、
前記所望のサーバーから前記ＩＮＶＩＴＥリクエストに対する応答を受信すると、前記セッションキーで前記応答に署名して、ＳＩＰクライアントがＳＩＰプロキシを認証できるように前記署名された応答を前記ＳＩＰクライアントに送信するステップと
を含むことを特徴とする方法。 - 前記ＳＩＰプロキシは、前記セッションキーを生成することを特徴とする請求項１に記載の方法。
- 前記ＳＩＰプロキシは、前記セッションキーを自身のドメインコントローラーに提供し、前記ＳＩＰプロキシの前記ドメインコントローラーは、前記ＳＩＰクライアントのドメインコントローラーに前記セッションキーを提供することを特徴とする請求項２に記載の方法。
- 前記サーバーチケットは、前記セッションキーを含むことを特徴とする請求項１に記載の方法。
- 前記ＳＩＰクライアントが前記署名された応答を受信すると、前記応答が前記セッションキーで署名されていることを確認するステップをさらに含むことを特徴とする請求項１に記載の方法。
- セッションイニシエーションプロトコル（ＳＩＰ）プロキシを介してセッションを開始することに関連してＳＩＰクライアントとＳＩＰプロキシの間の相互認証を提供するコンピュータシステムを制御する命令を記憶したコンピュータ読み取り可能な記録媒体であって、
前記命令は、
前記ＳＩＰクライアントから第１のＩＮＶＩＴＥリクエストを受信するステップと、
セッションキーを中継コンピュータに提供するステップと、
前記第１のＩＮＶＩＴＥリクエストを受信したことに応答して、ＳＩＰプロキシのセキュリティコンテキストを含むチャレンジメッセージを前記ＳＩＰクライアントに送信するステップと、
認証データを含む暗号化されたサーバーチケットとセキュリティコンテキストとを含む、セッションキーによって署名された第２のＩＮＶＩＴＥリクエストをＳＩＰプロキシが受信するステップと、
前記ＳＩＰプロキシの長期キーに基づいて前記サーバーチケットを解読するステップと、
前記サーバーチケット内の認証データが、前記ＳＩＰクライアントが信頼のおけるものであること、前記第２のＩＮＶＩＴＥリクエストに含まれるセキュリティコンテキストがＳＩＰプロキシのセキュリティコンテキストに合致するものであること、及び前記第２のＩＮＶＩＴＥリクエストが前記セッションキーによって署名されていることを示す場合に、ＩＮＶＩＴＥリクエストを所望のサーバーに送信するステップと、
前記所望のサーバーから前記ＩＮＶＩＴＥリクエストに対する応答を受信すると、前記セッションキーで前記応答に署名して、ＳＩＰクライアントがＳＩＰプロキシを認証できるように前記署名された応答を前記ＳＩＰクライアントに転送するステップと
を含む方法を実行することによって前記コンピュータシステムを制御することを特徴とするコンピュータ読み取り可能な記録媒体。 - 前記サーバーチケットは、前記セッションキーを含むことを特徴とする請求項６に記載のコンピュータ読み取り可能な記録媒体。
- 前記中継コンピュータは、前記セッションキーをＳＩＰクライアントに提供することを特徴とする請求項６に記載のコンピュータ読み取り可能な記録媒体。
- 前記中継コンピュータは、前記ＳＩＰプロキシのドメインコントローラーであり、前記ＳＩＰプロキシのドメインコントローラーは、前記セッションキーを前記ＳＩＰクライアントのドメインコントローラーに提供することを特徴とする請求項６に記載のコンピュータ読み取り可能な記録媒体。
- 前記チャレンジメッセージを受信したことに応答して、前記ＳＩＰクライアントが、
前記中継コンピュータから前記ＳＩＰプロキシのセッションキーとサーバーチケットとを取得するステップであって、前記セッションキーは前記ＳＩＰクライアントのキーで暗号化されており、前記サーバーチケットはＳＩＰプロキシの長期キーで暗号化されていてＳＩＰクライアントの認証データを含んでいるステップと、
前記ＳＩＰクライアントの前記キーに基づいて前記セッションキーを解読するステップと、
前記セッションキーによって署名され、かつ前記サーバーチケット及びＳＩＰプロキシのセキュリティコンテキストを含む第２のＩＮＶＩＴＥリクエストを前記ＳＩＰプロキシに送信するステップと
を実行することを特徴とする請求項６に記載のコンピュータ読み取り可能な記録媒体。 - セッションイニシエーションプロトコル（ＳＩＰ）プロキシを介してセッションを開始することに関連してＳＩＰクライアントとＳＩＰプロキシの間の相互認証を提供するコンピュータシステムを制御する命令を記憶したコンピュータ読み取り可能な記録媒体であって、
前記命令は、
前記ＳＩＰプロキシに第１のＩＮＶＩＴＥリクエストを送信するステップと、
ＳＩＰプロキシのセキュリティコンテキストを含むチャレンジメッセージを前記ＳＩＰプロキシから受信するステップと、
前記チャレンジメッセージを受信したことに応答して、ＳＩＰクライアントが、
ＳＩＰクライアントの中継コンピュータからＳＩＰプロキシのセッションキーとサーバーチケットとを取得するステップであって、前記サーバーチケットはＳＩＰプロキシの長期キーで暗号化されており、ＳＩＰプロキシがＳＩＰクライアントを認証できるようにＳＩＰクライアントの認証データを含んでいるステップと、
前記セッションキーによって署名され、サーバーチケットとＳＩＰプロキシのセキュリティコンテキストとを含む第２のＩＮＶＩＴＥリクエストをＳＩＰプロキシに送信するステップと、
ＳＩＰプロキシから前記第２のＩＮＶＩＴＥリクエストに対する応答を受信するステップと、
前記応答がＳＩＰプロキシを認証するために前記セッションキーによって署名されていることを確認するステップと
を含む方法を実行することによって前記コンピュータシステムを制御することを特徴とするコンピュータ読み取り可能な記録媒体。 - 前記サーバーチケットは、前記セッションキーを含むことを特徴とする請求項１１に記載のコンピュータ読み取り可能な記録媒体。
- 前記ＳＩＰクライアントの中継コンピュータは、前記セッションキーを前記ＳＩＰプロキシの中継コンピュータから取得することを特徴とする請求項１１に記載のコンピュータ読み取り可能な記録媒体。
- 前記ＳＩＰクライアントの中継コンピュータは、前記ＳＩＰクライアントのドメインコントローラーであり、前記ＳＩＰプロキシの中継コンピュータは、前記ＳＩＰプロキシのドメインコントローラーであることを特徴とする請求項１３に記載のコンピュータ読み取り可能な記録媒体。
- 前記ＳＩＰクライアント及び前記ＳＩＰプロキシは、相異なるドメインに存在することを特徴とする請求項１１に記載のコンピュータ読み取り可能な記録媒体。
- 前記ＳＩＰプロキシは、前記サーバーチケットの認証データに基づいて前記ＳＩＰクライアントを認証することを特徴とする請求項１１に記載のコンピュータ読み取り可能な記録媒体。
- 前記第２のＩＮＶＩＴＥリクエストを受信すると、前記ＳＩＰプロキシが、
前記ＳＩＰプロキシの長期キーに基づいて前記サーバーチケットを解読し、
前記サーバーチケット内の認証データが、前記ＳＩＰクライアントが信頼のおけるものであること、前記第２のＩＮＶＩＴＥリクエストに含まれるセキュリティコンテキストがＳＩＰプロキシのセキュリティコンテキストに合致するものであること、及び前記第２のＩＮＶＩＴＥリクエストが前記セッションキーによって署名されていることを示す場合に、ＩＮＶＩＴＥリクエストを所望のサーバーに送信し、
前記所望のサーバーから前記ＩＮＶＩＴＥリクエストに対する応答を受信すると、前記セッションキーで前記応答に署名して、ＳＩＰクライアントがＳＩＰプロキシを認証できるように前記署名された応答をＳＩＰクライアントに転送する
ことを特徴とする請求項１１に記載のコンピュータ読み取り可能な記録媒体。 - 前記ＳＩＰプロキシは、前記第１のＩＮＶＩＴＥリクエストをＳＩＰクライアントから受信し、前記セッションキーを前記中継コンピュータに提供し、ＳＩＰプロキシのセキュリティコンテキストを含むチャレンジメッセージをＳＩＰクライアントに送信することを特徴とする請求項１５に記載のコンピュータ読み取り可能な記録媒体。
- セッションイニシエーションプロトコル（ＳＩＰ）プロキシを介してセッションを開始することに関連してＳＩＰクライアントとＳＩＰプロキシの間の相互認証をするための方法であって、
前記ＳＩＰクライアントから前記ＳＩＰプロキシに第１のＩＮＶＩＴＥリクエストを送信するステップと、
前記ＳＩＰプロキシが前記第１のＩＮＶＩＴＥリクエストを受信したことに応答して、ＳＩＰプロキシのセキュリティコンテキストを含むチャレンジメッセージを前記ＳＩＰクライアントに送信するステップと、
前記ＳＩＰクライアントが前記チャレンジメッセージを受信したことに応答して、中継コンピュータ経由でＳＩＰプロキシによって提供されたセッションキーによって署名され、かつサーバーチケット及びＳＩＰプロキシのセキュリティコンテキストを含む第２のＩＮＶＩＴＥリクエストを前記ＳＩＰプロキシに送信するステップであって、該サーバーチケットはＳＩＰクライアントの認証データを含んでいるステップと、
前記ＳＩＰプロキシが前記第２のＩＮＶＩＴＥリクエストを受信すると、
前記サーバーチケット内のＳＩＰクライアントの認証データが、前記ＳＩＰクライアントが信頼のおけるものであること、前記第２のＩＮＶＩＴＥリクエストに含まれるセキュリティコンテキストがＳＩＰプロキシのセキュリティコンテキストに合致するものであること、及び前記第２のＩＮＶＩＴＥリクエストが前記セッションキーによって署名されていることを示す場合に、前記第２のＩＮＶＩＴＥリクエストに基づいてＩＮＶＩＴＥリクエストを所望のサーバーに送信するステップと、
前記所望のサーバーから前記ＩＮＶＩＴＥリクエストに対する応答を受信すると、前記セッションキーで前記応答に署名して、前記署名された応答を前記ＳＩＰクライアントに転送するステップと
前記応答をＳＩＰクライアントが受信すると、前記応答がＳＩＰプロキシを認証するために前記セッションキーで署名されていることを確認するステップと
を含むことを特徴とする方法。 - 前記ＳＩＰクライアントは、ＳＩＰプロキシの長期キーで前記サーバーチケットを暗号化し、
前記ＳＩＰプロキシは、前記ＳＩＰプロキシの長期キーに基づいて前記サーバーチケットを解読することを特徴とする請求項１９に記載の方法。 - 前記ＳＩＰプロキシは、前記中継コンピュータに前記セッションキーを提供することを特徴とする請求項１９に記載の方法。
- 前記ＳＩＰプロキシ及び前記ＳＩＰクライアントが相異なるドメインに存在する場合に、
前記ＳＩＰプロキシは、ＳＩＰプロキシのドメインの中継コンピュータに前記セッションキーを提供し、
前記ＳＩＰプロキシのドメインの中継コンピュータは、ＳＩＰクライアントのドメインの中継コンピュータに前記セッションキーを提供し、
前記ＳＩＰクライアントのドメインの中継コンピュータは、ＳＩＰクライアントに前記セッションキーを提供することを特徴とする請求項１９に記載の方法。
Applications Claiming Priority (4)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US29823901P | 2001-06-14 | 2001-06-14 | |
| US60/298,239 | 2001-06-14 | ||
| 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 |
| US10/151,747 | 2002-05-17 |
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 Expired - Lifetime 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) | ATE398882T1 (ja) |
| DE (1) | DE60227132D1 (ja) |
Families Citing this family (153)
| 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 |
| 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 |
| US7496751B2 (en) * | 2001-10-29 | 2009-02-24 | Sun Microsystems, Inc. | Privacy and 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 |
| US20050268328A1 (en) * | 2002-07-03 | 2005-12-01 | Gabriele Corliano | Trust establishment for multi-party communications |
| AU2003298560A1 (en) * | 2002-08-23 | 2004-05-04 | Exit-Cube, Inc. | Encrypting operating system |
| 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 |
| KR101759456B1 (ko) * | 2003-12-01 | 2017-07-18 | 인터디지탈 테크날러지 코포레이션 | 사용자 개시 핸드오프에 기초한 세션 개시 프로토콜(ｓｉｐ) |
| 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 | 無線ＬＡＮを利用したＶｏＩＰワイヤレス電話システム及び方法 |
| 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 | 株式会社日立コミュニケーションテクノロジー | ルータ及びｓｉｐサーバ |
| 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 | 株式会社日立製作所 | ネットワークシステム、データ中継装置、セッションモニタシステム、およびパケットモニタ中継装置 |
| US7920520B2 (en) * | 2004-07-20 | 2011-04-05 | Qualcomm Incorporated | Handoff between a SIP network and a cellular communication system |
| US20090043765A1 (en) * | 2004-08-20 | 2009-02-12 | 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 |
| US20060210036A1 (en) * | 2005-03-16 | 2006-09-21 | Jeffrey Citron | System for effecting a telephone call over a computer network without alphanumeric keypad operation |
| 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 |
| US8086853B2 (en) * | 2005-03-18 | 2011-12-27 | Microsoft Corporation | Automatic centralized authentication challenge response generation |
| WO2006106250A1 (fr) * | 2005-04-07 | 2006-10-12 | France Telecom | Communication securisee entre un dispositif de traitement de donnees et un module de securite |
| JP4571006B2 (ja) * | 2005-04-19 | 2010-10-27 | エヌ・ティ・ティ・コミュニケーションズ株式会社 | ネットワーク制御装置、ネットワークシステム、及びプログラム |
| US8996423B2 (en) * | 2005-04-19 | 2015-03-31 | Microsoft Corporation | Authentication for a commercial transaction using a mobile module |
| 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 |
| CN1889562A (zh) * | 2005-06-28 | 2007-01-03 | 华为技术有限公司 | 对接收初始会话协议请求消息的设备进行认证的方法 |
| 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 |
| 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 |
| US20090119504A1 (en) * | 2005-08-10 | 2009-05-07 | Riverbed Technology, Inc. | Intercepting and split-terminating authenticated communication connections |
| CN100488139C (zh) * | 2005-08-10 | 2009-05-13 | 华为技术有限公司 | 建立聊天室数据传输通道实现聊天消息传送的方法 |
| US8613071B2 (en) * | 2005-08-10 | 2013-12-17 | Riverbed Technology, Inc. | Split termination for secure communication protocols |
| 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 |
| CN101288281B (zh) * | 2005-10-13 | 2012-10-03 | 沃纳格控股公司 | 用于检测设备附加的变化的方法和系统 |
| US7626963B2 (en) * | 2005-10-25 | 2009-12-01 | Cisco Technology, Inc. | EAP/SIM authentication for mobile IP to leverage GSM/SIM authentication infrastructure |
| EP1949660A4 (en) | 2005-11-09 | 2010-10-13 | Vonage Holdings Corp | METHOD AND SYSTEM FOR ADAPTED CALL 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 |
| AU2007211267A1 (en) * | 2006-02-01 | 2007-08-09 | Vonage Holdings Corp. | Method and apparatus for communicating a status of a device in a packet-based communication network |
| US8917717B2 (en) * | 2007-02-13 | 2014-12-23 | Vonage Network Llc | Method and system for multi-modal communications |
| US8087075B2 (en) * | 2006-02-13 | 2011-12-27 | Quest Software, Inc. | Disconnected credential validation using pre-fetched service tickets |
| MX2008010979A (es) * | 2006-02-27 | 2009-01-23 | Vonage Holdings Corp | Metodo y sistema para transferencia de datos bidireccional. |
| 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 |
| US8285983B2 (en) * | 2006-05-15 | 2012-10-09 | 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 |
| US8086710B2 (en) | 2006-10-30 | 2011-12-27 | Quest Software, Inc. | Identity migration apparatus and method |
| US7895332B2 (en) | 2006-10-30 | 2011-02-22 | Quest Software, Inc. | Identity migration system 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 | 삼성전자주식회사 | 키 확립 시스템 및 이를 이용한 방법 |
| 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 |
| NZ585054A (en) * | 2007-11-30 | 2013-08-30 | Ericsson Telefon Ab L M | Key management for secure communication |
| WO2009086845A1 (de) | 2008-01-07 | 2009-07-16 | Siemens Enterprise Communications 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 |
| CN105227636A (zh) * | 2008-02-14 | 2016-01-06 | 诺基亚公司 | 用于实施发布处理的系统和方法 |
| 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 |
| CN104394146B (zh) | 2009-04-13 | 2017-10-20 | 黑莓有限公司 | 用于确定sip消息的可信度的系统和方法 |
| 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 |
| US8443082B2 (en) * | 2011-02-28 | 2013-05-14 | Interactive Social Internetworks, Llc | Network communication systems and methods |
| 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 |
| US9137028B1 (en) | 2012-02-22 | 2015-09-15 | West Corporation | Internet sip registration/proxy service for audio conferencing |
| US8934383B1 (en) | 2012-02-22 | 2015-01-13 | 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 |
| WO2014166546A1 (en) | 2013-04-12 | 2014-10-16 | Nec Europe Ltd. | Method and system for accessing device by a user |
| HUE052489T2 (hu) * | 2013-04-26 | 2021-04-28 | Hamamatsu Photonics Kk | Képfelvevõ berendezés és eljárás és rendszer fókusztérkép elõállítására minta számára |
| EP2990850B1 (en) * | 2013-04-26 | 2020-09-16 | Hamamatsu Photonics K.K. | Image acquisition device and method and system for acquiring focusing information for specimen |
| US9203906B2 (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 |
| US9203593B2 (en) | 2013-06-30 | 2015-12-01 | 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 |
| JP7005192B2 (ja) * | 2017-06-30 | 2022-01-21 | キヤノン株式会社 | 情報処理装置、情報処理方法及びプログラム |
| JP6456451B1 (ja) * | 2017-09-25 | 2019-01-23 | エヌ・ティ・ティ・コミュニケーションズ株式会社 | 通信装置、通信方法、及びプログラム |
| FR3076149B1 (fr) * | 2017-12-27 | 2019-11-15 | Atos Integration | Procede de securisation de bout en bout d'une communication |
| US10833943B1 (en) | 2018-03-01 | 2020-11-10 | F5 Networks, Inc. | Methods for service chaining and devices thereof |
| CN109361892A (zh) * | 2018-10-30 | 2019-02-19 | 平安科技（深圳）有限公司 | 音视频通话的信令分析方法及装置、电子设备、存储介质 |
| 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 |
| US11831616B2 (en) * | 2020-03-24 | 2023-11-28 | Microsoft Technology Licensing, Llc | Reverse proxy servers for implementing application layer-based and transport layer-based security rules |
| CN111586007B (zh) * | 2020-04-29 | 2022-09-09 | 国家电网公司华中分部 | 一种数据传输的安全认证系统和方法 |
Family Cites Families (14)
| 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 |
| EP1254547B1 (en) * | 2000-02-08 | 2005-11-23 | 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 |
| US7529359B2 (en) * | 2001-03-20 | 2009-05-05 | Verizon Business Global Llc | Caller treatment in a SIP network |
| US7945592B2 (en) * | 2001-03-20 | 2011-05-17 | Verizon Business Global Llc | XML based transaction detail records |
| 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 |
-
2002
- 2002-05-17 US US10/151,747 patent/US7243370B2/en not_active Expired - Fee Related
- 2002-06-12 DE DE60227132T patent/DE60227132D1/de not_active Expired - Lifetime
- 2002-06-12 EP EP02013408A patent/EP1267548B1/en not_active Expired - Lifetime
- 2002-06-12 AT AT02013408T patent/ATE398882T1/de not_active IP Right Cessation
- 2002-06-14 JP JP2002174951A patent/JP4294268B2/ja not_active Expired - Lifetime
-
2007
- 2007-06-04 US US11/757,877 patent/US7770007B2/en not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2003108527A (ja) | 2003-04-11 |
| DE60227132D1 (de) | 2008-07-31 |
| ATE398882T1 (de) | 2008-07-15 |
| US20030005280A1 (en) | 2003-01-02 |
| EP1267548B1 (en) | 2008-06-18 |
| US7770007B2 (en) | 2010-08-03 |
| US20080022383A1 (en) | 2008-01-24 |
| EP1267548A2 (en) | 2002-12-18 |
| EP1267548A3 (en) | 2005-04-20 |
| US7243370B2 (en) | 2007-07-10 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4294268B2 (ja) | クライアント・プロキシ認証のためにセッションイニシエーションプロトコルリクエストメッセージにセキュリティ機構を組み込むための方法およびシステム | |
| Seitz et al. | RFC 9200: Authentication and Authorization for Constrained Environments Using the OAuth 2.0 Framework (ACE-OAuth) | |
| EP1758324B1 (en) | The session initial protocol identification method | |
| US7240366B2 (en) | End-to-end authentication of session initiation protocol messages using certificates | |
| US6993652B2 (en) | Method and system for providing client privacy when requesting content from a public server | |
| US20090094692A1 (en) | Session control server, communication device, communication system and communication method, and program and recording medium for the same | |
| US11546305B2 (en) | Methods and systems for secure DNS routing | |
| WO2007000115A1 (fr) | Procede d'authentification de dispositif recevant un message de demande sip | |
| KR101016277B1 (ko) | 보안성이 강화된 ｓⅰｐ 등록 및 ｓⅰｐ 세션 설정 방법 및장치 | |
| US20070005730A1 (en) | Method for distributing passwords | |
| Toorop et al. | DNS Zone Transfer over TLS | |
| WO2011017851A1 (zh) | 客户端安全访问消息存储服务器的方法和相关设备 | |
| TWI448128B (zh) | 用於雙堆疊操作互通授權的方法及裝置 | |
| JP2005327315A (ja) | クライアントとサーバ間の簡易認証方法 | |
| Toorop et al. | RFC 9103: DNS Zone Transfer over TLS | |
| JP2005229435A (ja) | リゾルバをアプリケーションとは別に備えた端末及びリゾルバプログラム | |
| Elmahalwy et al. | Securing Session Initiation Protocol for VOIP Services | |
| Kong | Security system for passive IP devices on SIP-based networks | |
| Alsmairat | Securing SIP in VoIP Domain | |
| Parecki | The Little Book of OAuth 2.0 RFCs | |
| Stenzel | RACED-A RIOT OS integration of the ACE-OAuth DTLS profile |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20050613 |
|
| RD04 | Notification of resignation of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7424 Effective date: 20050613 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20081111 |
|
| A521 | Request for written amendment filed |
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 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120417 Year of fee payment: 3 |
|
| 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: 20130417 Year of fee payment: 4 |
|
| 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: 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 |