JP2007104691A - データ通信方法およびシステム - Google Patents

Abstract

【課題】接続先サーバをＩＰアドレスで指定したセッション制御メッセージをセッション管理サーバ経由で接続先サーバに転送可能にした暗号化通信方法とシステムの提供。
【解決手段】クライアントのアプリケーションプログラムまたは暗号化通信ソフトが、接続先サーバをＩＰアドレスで指定した形で接続要求を発行した時、クライアントまたはセッション管理サーバで、上記ＩＰアドレスをドメイン識別可能な所望のリソース識別子に自動的に変換し、受信メッセージの転送先ドメインを判定する。
【選択図】図１１

Description

本発明は、データ通信方法およびシステムに関し、更に詳しくは、クライアントとサーバとの間での暗号化データ通信を可能にし、且つ、セッション管理サーバを利用して、クライアントとサーバとの間の認証手順を容易にしたデータ通信方法およびシステムを提供することにある。

ネットワークにおける暗号化通信方法では、クライアントとサーバは、互いに意図しない相手装置との通信を防止するため、相手装置について認証手順を実行し、相手装置の認証に成功した時、通信に使用する暗号化パラメータを交換するようにしている。ＩＥＴＦ（Internet Engineering Task Force）のＲＦＣ２４０１（非特許文献１）に記述されたＩＰｓｅｃ（Internet Protocol Security）や、ＲＦＣ２２４６（非特許文献２）に記述されたＴＬＳ（Transport Layer Security）では、通信相手の認証に公開鍵証明書が適用される。

公開鍵証明書を用いた認証では、通信相手が提示した公開鍵証明書が信頼できる認証局から発行されたものであることを何らかの方法で検証する必要がある。公開鍵証明書の検証方法の１つとしては、例えば、通信相手が提示する公開鍵証明書の発行元認証局を証明するための信頼性のある認証局ｒｏｏｔ証明書を何らかの方法で事前に入手しておき、通信相手の認証手順において、相手装置が提示した公開鍵証明書に付与された認証局の署名を、認証局のｒｏｏｔ証明書の公開鍵によって検証する方法ある。この検証方法によれば、サーバとクライアントは、通信対象となる全ての通信装置の公開鍵証明書に対応して、各公開鍵証明書の発行元認証局のｒｏｏｔ証明書を事前に用意しておく必要がある。

例えば、図１に示すように、複数のクライアント（端末装置）ＣＬ１、ＣＬ２、ＣＬ３が、それぞれ発行元（ＣＡ１、ＣＡ２、ＣＡ３）の異なる秘密鍵ＳＫ１、ＳＫ２、ＳＫ３と公開鍵証明書ＰＫ１、ＰＫ２、ＰＫ３を所持し、サーバＳＶ１、ＳＶ２、ＳＶ３も、それぞれ発行元（ＣＡ１、ＣＡ２、ＣＡ３）の異なる秘密鍵ＳＫ１１、ＳＫ１２、ＳＫ１３と公開鍵証明書ＰＫ１１、ＰＫ１２、ＰＫ１３を所持したシステムを想定する。ここで、各クライアントが、複数のサーバＳＶ１、ＳＶ２、ＳＶ３と随時に通信できるようにするためには、図示したように、各サーバに、通信相手となる全てのクライアント装置ＣＬ１、ＣＬ２、ＣＬ３がもつ公開鍵証明書（ＰＫ１、ＰＫ２、ＰＫ３）の発行元認証局（ＣＡ１、ＣＡ２、ＣＡ３）と対応して、複数のｒｏｏｔ証明書ＲＴ１、ＲＴ２、ＲＴ３を事前に所持しておく必要がある。同様に、各クライアントにも、通信相手となるサーバＳＶ１、ＳＶ２、ＳＶ３がもつ公開鍵証明書（ＰＫ１１、ＰＫ１２、ＰＫ１３）の発行元認証局（ＣＡ１、ＣＡ２、ＣＡ３）と対応して、複数のｒｏｏｔ証明書ＲＴ１、ＲＴ２、ＲＴ３を事前に用意しておく必要がある。また、このシステム構成では、各クライアント装置とサーバは、通信相手を変えた時、その都度、認証処理を繰り返す必要がある。

図２は、上記ＲＦＣ２４０１に記述されたＩＰｓｅｃによる暗号化通信を行うためにクライアントが備えるソフトウェアの基本的なブロック構成を示す。
ここで、２０は、ネットワークインタフェースカード（ＮＩＣ）部、３０は、ＴＣＰ／ＩＰレイヤ、４０は、アプリケーションレイヤのソフトウェア部を示し、５０は、ＲＦＣ２４０９（非特許文献３）に記述された鍵管理（ＩＫＥ：Internet Key Exchange）プロセス用のソフトウェア部を示している。ＩＰｓｅｃエンジン３１は、ＴＣＰ／ＩＰレイヤのソフトウェアの一部として装備され、送信パケットに暗号化を適用するか否かの判定情報（ＳＰ情報）を記憶したＳＰＤＢ（Security Policy Data Base）３２と、暗号化通信に適用する暗号化方式や暗号鍵等の情報（ＳＡ情報）を記憶したＳＡＤＢ（Security Association Data Base）３３とを備えている。

上記クライアントの通信相手となるサーバも、図２と同様のソフトウェアを有し、クライアントとサーバのアプリケーションレイヤ同士、鍵管理プロセス同士が互いに通信するようになっている。

ＩＰｓｅｃエンジン３１は、アプリケーションレイヤ４０のプログラムが発行したＩＰパケットの送信要求を検出すると、該ＩＰパケットのヘッダ情報をＳＰＤＢ３２で検証し、このＩＰパケットにＩＰｓｅｃを適用すべきか否かを判定する。ＩＰパケットにＩＰｓｅｃを適用すると判断したＩＰｓｅｃエンジン３１は、ＳＡＤＢ３３から、ＩＰパケットに適用すべきＳＡ（Security Association）情報を取得する。ここで、もし、ＳＡＤＢ３３に上記ＩＰパケットと対応するＳＡ情報が登録されていなかった場合、ＩＰｓｅｃエンジン３１は、ＩＫＥ（鍵管理）プロセス５０に対して、通信相手（接続先サーバ）との間での暗号鍵を含むＳＡ情報の交換を要求する。

ＩＫＥプロセス５０は、ＲＦＣ２４０８（非特許文献４）に記載されたＩＳＡＫＭＰ（Internet Security Association and Key Management Protocol）に従って、通信相手とＳＡ情報を交換する。ＩＳＡＫＭＰでは、通信相手との間に暗号化通信路を形成した後、相手装置が通信を許容された真正な装置か否かを確認するための認証手順を実行する。ＩＫＥプロセス５０は、上記認証手順によって、相手装置が暗号化通信を許容された真正な装置であることを確認すると、ＩＳＡＫＭＰによって設定された通信路を介して、相手装置とＳＡ情報の交換を開始する。ＩＫＥプロセス５０は、通信相手とのＳＡ情報の交換が完了すると、ＩＰｓｅｃエンジン３１に、ＳＡ情報とこれに対応したＳＰ（Security Policy）情報を通知する。

ＩＰｓｅｃエンジン３１は、ＩＫＥプロセス５０から通知されたＳＰ情報とＳＡ情報をそれぞれＳＰＤＢ３２、ＳＡＤＢ３３に格納した後、ＩＰパケットを上記ＳＡ情報に従って暗号化して、通信相手に送信する。通信相手となるサーバ側では、上記暗号化されたＩＰパケットを受信すると、ＩＫＥプロセスによって合意したＳＡ情報に従って受信ＩＰパケットを復号化し、サーバ側アプリケーションレイヤにＩＰパケットの受信を通知する。

一方、ＲＦＣ３２６１（非特許文献５）には、ＴＬＳ（Transport Layer Security）によって、クライアント（ユーザエージェントクライアント）とセッション管理サーバであるＳＩＰ（Session Initiation Protocol）プロキシとの間、およびＳＩＰプロキシとサーバ（ユーザエージェント・サーバ）との間の相互認証を行って、クライアントとＳＩＰプロキシ、ＳＩＰプロキシとサーバが暗号化通信する方法が記載されている。ＲＦＣ３２６１のＳＩＰモデルによれば、クライアントとサーバは、それぞれがＳＩＰプロキシによって真正な通信相手として確認済みであり、且つ、クライアントとサーバとの間では、暗号化されたＳＩＰメッセージが送受信されるため、クライアント、サーバ、ＳＩＰプロキシ以外の他の装置が、上記クライアントとサーバとの間の通信内容を傍受することは困難となっている。

ＳＩＰは、テキストベースのプロトコルであり、ＳＩＰメッセージは、ヘッダ部と、セッション内容を示すメッセージボディ部とからなる。ＳＩＰに関しては、ＲＦＣ３２６３（非特許文献６）に記述されている。また、ＲＦＣ２３２７（非特許文献７）には、セッション記述に適用されるＳＤＰ（Session Description Protocol）と、クライアントとサーバとの間で交換される暗号化パラメータの記述方法について開示されている。ＳＩＰモデルのクライアントとサーバは、それぞれがＳＩＰプロキシとの間に形成した暗号通信路を介して、ＳＩＰメッセージによってセッション記述と暗号化パラメータを交換した後、上記暗号化パラメータを適用して、暗号化パケットを通信することができる。

RFC2401：Security Architecture for the Internet Protocol RFC2246：The TLS Protocol Version 1.0 RFC2409：The Internet Key Exchange (IKE) RFC2408：Internet Security Association and Key Management Protocol (ISAKMP) RFC3261：SIP: Session Initiation Protocol RFC3263：Session Initiation Protocol (SIP): Locating SIP Servers RFC2327：SDP: Session Description Protocol

図３は、上述したＳＩＰプロキシを適用した認証システムの１例を示す。ここで、ＰＲは、複数のクライアントＣＬ１、ＣＬ２、ＣＬ３と、複数のサーバＳＶ１、ＳＶ２、ＳＶ３とに接続されたＳＩＰプロキシを示す。ＳＩＰプロキシＰＲは、認証局ＣＡ４が発行した秘密鍵ＳＫ３０と、公開鍵証明書ＰＫ３０を使用しており、サーバＳＶ１、ＳＶ２、ＳＶ３を認証するために、これらのサーバが使用する公開鍵証明書の発行元認証局（ＣＡ１、ＣＡ２、ＣＡ３）と対応した複数のｒｏｏｔ証明書ＲＴ１、ＲＴ２、ＲＴ３を予め所持している。

ＳＩＰプロキシを適用した認証システムでは、各サーバとクライアントは、図３に示すように、通信相手を認証するためのｒｏｏｔ証明書として、ＳＩＰプロキシＰＲが使用する公開鍵証明書ＰＫ３０の発行元認証局と対応したｒｏｏｔ証明書ＲＴ４のみを所持すればよい。また、各クライアントは、ＳＩＰプロキシＰＲを介して１つのサーバと通信した後、接続先を別のサーバに変更する場合、ＳＩＰプロキシとの間では既に構築済みの暗号通信路を使用して通信できるため、新たな通信相手との間で暗号化パラメータを交換するだけで、暗号化通信を開始することが可能となる。つまり、ＳＩＰプロキシを適用した認証システムでは、各クライアントにとって、接続先サーバの変更の都度、新たに認証処理を行う必要がないという利点がある。

然るに、ＳＩＰのフレームワークにおいては、セッション管理サーバ（ＳＩＰプロキシ）は、ＡＯＲ（Address-of-Record）と呼ばれる「ユーザ名＠ドメイン名」 形式をもつ識別子（ＳＩＰ−ＵＲＩ）によって、受信ＳＩＰメッセージの転送先を決定している。従って、上述したＳＩＰプロキシのようなセッション管理サーバ経由のセッション設定を前提としたネットワークシステムでは、クライアント上で実行されるアプリケーションは、接続先サーバを指定するための識別子として、サーバの所属ドメインを特定可能なＳＩＰ−ＵＲＩ（Uniform Resource Identifier）を使用する必要がある。

更に詳述すると、ＳＩＰのフレームワークにおいては、クライアント側では、スタートラインに含まれるＲｅｑｕｅｓｔ−ＵＲＩとして、接続先サーバを指定するＡＯＲ形式のＳＩＰ−ＵＲＩを記述した接続要求ＳＩＰメッセージを生成し、該ＳＩＰメッセージをペイロードに含むＩＰパケットをクライアントの所属ドメインに位置するＳＩＰプロキシ宛に送信する。上記ＩＰパケットを受信したＳＩＰプロキシは、Ｒｅｑｕｅｓｔ−ＵＲＩとして記述されたＡＯＲが示すドメイン名に基づいて、例えば、ＤＮＳ（Domain Name System）のＮＡＰＴＲ Ｒｅｃｏｒｄ検索とＳＲＶ Ｒｅｃｏｒｄ検索を行うことにより、受信メッセージの転送先サーバが所属する他のドメインに位置したＳＩＰプロキシ（転送先ＳＩＰプロキシ）のＩＰアドレスあるいはＦＱＤＮ（Full Qualified Domain Name）を特定する。ＳＲＶ Ｒｅｃｏｒｄ検索の結果がＦＱＤＮを示した場合は、ＤＮＳのＡ Ｒｅｃｏｒｄ検索を実行することによって、転送先ＳＩＰプロキシのＩＰアドレスを取得できる。尚、ドメイン名から転送先ＳＩＰプロキシのＩＰアドレスを取得する手順については、ＲＦＣ３２６３（非特許文献６）に記述されている。

ここで、接続先サーバの所属ドメインが、ＳＩＰメッセージを受信したＳＩＰプロキシの所属ドメインと同一であった場合、ＳＩＰプロキシは、受信メッセージのＲｅｑｕｅｓｔ−ＵＲＩに記述されたＳＩＰ−ＵＲＩを検索キーとして、ロケーションサービスＤＢ（データベース）から接続先サーバのＩＰアドレス（またはＦＱＤＮ）を取得し、このＩＰアドレスをＩＰパケットの宛先アドレスとして、ＳＩＰメッセージを接続先サーバに転送する。接続先サーバの所属ドメインがＳＩＰプロキシ（または送信元クライアント）の所属ドメインと異なった場合は、ＳＩＰメッセージは、接続先サーバの所属ドメインに位置した別のＳＩＰプロキシに転送され、転送先のＳＩＰプロキシが、ロケーションサービスＤＢから接続先サーバのＩＰアドレスまたはＦＱＤＮを取得して、ＳＩＰメッセージを接続先サーバに転送する。

上述したように、セッション管理サーバ（ＳＩＰプロキシ）経由のセッション設定を前提とするネットワークでは、セッション管理サーバが、受信したＳＩＰメッセージに含まれる要求リソース識別子（ＳＩＰ−ＵＲＬ）から、接続先サーバが所属するドメインを判定し、受信メッセージを接続先サーバあるいは接続先セッション管理サーバに転送するようになっている。しかしながら、ＩＰ網に接続されるクライアント端末上で実行される一般のアプリケーションプログラムは、接続先サーバの指定に、上述したＡＯＲ形式のＳＩＰ−ＵＲＩのようにドメイン名を含む識別子ではなく、ＩＰアドレスのように接続先サーバのみを示す識別子を使用している。

アプリケーションプログラムまたは暗号化通信ソフトが、接続先サーバをＩＰアドレスで指定してサーバとの接続要求を発行し、クライアントが、接続先サーバをＩＰアドレスで指定した形で接続要求ＳＩＰメッセージを送信した場合、セッション管理サーバ（ＳＩＰプロキシ）は、受信した接続要求メッセージの転送先ドメインを特定することができない。この場合、クライアントが図３に示した認証システムの利点を享受できないという問題がある。

本発明の目的は、接続先サーバをＩＰアドレスで指定したセッション制御メッセージをセッション管理サーバ経由で接続先サーバに転送可能にしたデータ通信方法およびシステムを提供することにある。
本発明の他の目的は、クライアントが発生する接続先サーバをＩＰアドレスで指定した接続要求をセッション管理サーバ経由で接続先サーバに転送可能にしたデータ通信方法およびシステムを提供することにある。
本発明の更に他の目的は、クライアントとサーバとの間の暗号化データ通信を可能にし、且つ、暗号化データ通信に先立って必要となるクライアントとサーバとの間の認証手順を容易にしたデータ通信方法およびシステムを提供することにある。

上記目的を達成するため、本発明では、クライアントのアプリケーションプログラムまたは暗号化通信ソフトが、接続先サーバをＩＰアドレスで指定した形で接続要求を発行した時、クライアントまたはセッション管理サーバで、上記ＩＰアドレスをドメイン識別可能な所望のリソース識別子に自動的に変換することを特徴とする。

本発明によるクライアントとサーバとの間のデータ通信方法は、クライアントからセッション管理サーバに、接続先サーバのＩＰアドレスを指定して、該接続先サーバに割り当てられた所属ドメイン名を含むリソース識別子を問い合わせる第１ステップと、上記セッション管理サーバが、ＩＰアドレスとリソース識別子との対応関係を管理しているロケーションテーブルから、上記接続先サーバのＩＰアドレスと対応するリソース識別子を取得し、上記クライアントに通知する第２ステップと、上記クライアントから上記セッション管理サーバに、要求リソースを上記接続先サーバのリソース識別子で指定した接続要求メッセージを送信する第３ステップと、上記セッション管理サーバが、受信した接続要求メッセージに記述された上記リソース識別子に含まれるドメイン名に基づいて受信メッセージの転送先を判定し、受信メッセージを接続先サーバまたは該接続先サーバの所属ドメインを管理する別のセッション管理サーバに転送する第４ステップとからなることを特徴とする。

本発明によるデータ通信方法の別の実施例は、クライアントからセッション管理サーバに、要求リソースを接続先サーバのＩＰアドレスで指定した接続要求メッセージを送信する第１ステップと、上記接続要求メッセージを受信したセッション管理サーバが、ＩＰアドレスとリソース識別子との対応関係を管理しているロケーションテーブルから、上記接続先サーバのＩＰアドレスと対応するリソース識別子を取得する第２ステップと、上記セッション管理サーバが、受信メッセージに要求リソースとして記述されたＩＰアドレスを上記ロケーションテーブルから取得したリソース識別子に書き換える第３ステップと、上記セッション管理サーバが、上記リソース識別子に含まれるドメイン名に基づいて受信メッセージの転送先を判定し、受信メッセージを接続先サーバまたは該接続先サーバの所属ドメインを管理する別のセッション管理サーバに転送する第４ステップとからなることを特徴とする。

本発明によるデータ通信方法の更に他の実施例は、クライアントから接続先となるサーバに、該サーバに割り当てられた所属ドメイン名を含むリソース識別子を問い合わせる第１ステップと、上記サーバから上記クライアントに、問い合わせリソース識別子を通知する第２ステップと、上記クライアントからセッション管理サーバに、要求リソースを上記接続先サーバのリソース識別子で指定した接続要求メッセージを送信する第３ステップと、上記セッション管理サーバが、受信した接続要求メッセージに記述された上記リソース識別子に含まれるドメイン名に基づいて受信メッセージの転送先を判定し、受信メッセージを接続先サーバまたは該接続先サーバの所属ドメインを管理する別のセッション管理サーバに転送する第４ステップとからなることを特徴とする。

更に詳述すると、本発明のデータ通信方法は、接続要求メッセージの受信に応答して、接続先サーバからセッション管理サーバを介して要求元クライアントに、暗号化通信に必要となるパラメータ情報を含む接続応答メッセージを返送する第５ステップと、上記クライアントと接続先サーバとの間で、上記接続応答メッセージで指定されたパラメータ情報に従って暗号化されたメッセージを含むパケットを通信する第６ステップを含む。

上記セッション管理サーバは、例えば、ＳＩＰ（Session Initiation Protocol）サーバからなる。この場合、クライアントとセッション管理サーバとの間の通信メッセージは、例えば、ＲＦＣ３２６１に規定されたＴＬＳ（Transport Layer Security）によって暗号化され、クライアントと接続先サーバとの間の通信データは、例えば、ＲＦＣ２４０１に規定されたＩＰｓｅｃ（Internet Protocol Security）によって暗号化される。

本発明によって提供されるセッション管理サーバは、クライアントから、要求リソースを接続先サーバのＩＰアドレスで指定した接続要求メッセージを受信した時、ＩＰアドレスとリソース識別子との対応関係を管理しているロケーションテーブルから、上記接続先サーバのＩＰアドレスと対応するリソース識別子を取得し、受信メッセージに記述された要求リソースをＩＰアドレスから上記リソース識別子に書き換えるための手段と、上記リソース識別子に含まれるドメイン名に基づいて受信メッセージの転送先を判定し、受信メッセージを接続先サーバまたは該接続先サーバの所属ドメインを管理する別のセッション管理サーバに転送するための手段とを備えたことを特徴とする。

上記セッション管理サーバは、具体的には、通信ネットワークに接続されたネットワークインタフェース部と、セッション制御メッセージを処理するメッセージ処理部と、上記ネットワークインタフェース部から受信した暗号化メッセージを復号化して上記メッセージ処理部に渡すと共に、上記メッセージ処理部から出力されたセッション制御メッセージを暗号化して上記ネットワークインタフェース部に出力するためのセキュリティ部とを有し、上記メッセージ処理部が、上述した要求リソースの書き換え手段と受信メッセージの転送手段を備える。

本発明によって提供されるクライアント端末は、通信ネットワークに接続されたネットワークインタフェース部と、セッション制御メッセージを処理するメッセージ処理部と、アプリケーションプログラムが発生する接続先サーバ宛の送信メッセージを暗号化して上記ネットワークインタフェース部に出力すると共に、上記ネットワークインタフェース部から受信した暗号化メッセージを復号化して上記アプリケーションプログラムに渡すための第１セキュリティ部と、上記セキュリティ部から、接続先サーバとの暗号化パラメータの交換要求が発生した時、接続先サーバをＩＰアドレスで指定した接続要求メッセージを上記メッセージ処理部に出力し、上記メッセージ処理部から接続応答メッセージを受信した時、該受信メッセージから抽出した暗号化パラメータを上記第１セキュリティ部に渡すセキュリティ情報制御部とからなり、
上記メッセージ処理部が、上記セキュリティ情報制御部から接続要求メッセージを受信した時、上記ＩＰアドレスに基づいて上記セッション管理サーバまたは接続先サーバから接続先サーバのリソース識別子を取得し、該リソース識別子で要求リソースを指定した形で、上記接続要求メッセージを上記セッション管理サーバに送信することを特徴とする。

実際の応用では、本発明のクライアント端末は、上記ネットワークインタフェース部から受信した暗号化されたセッション制御メッセージを復号化して上記メッセージ処理部に渡すと共に、上記メッセージ処理部から出力されたセッション制御メッセージを暗号化して上記ネットワークインタフェース部に出力するための第２セキュリティ部を有し、
接続先サーバとの通信データが上記第１セキュリティ部によって暗号化され、セッション管理サーバと通信メッセージが上記第２セキュリティ部によって暗号化される。

本発明によれば、クライアントのアプリケーションプログラムまたは暗号化通信ソフトから、要求リソース（接続先サーバ）をＩＰアドレスで指定した形で接続要求が発行された場合でも、接続要求メッセージの要求リソースをＩＰアドレスからドメイン識別可能なリソース識別子に自動的に変換できる。従って、接続要求メッセージを転送制御するセッション管理サーバにおいて、受信メッセージのリソース識別子から転送先ドメインを判定し、受信メッセージを接続先サーバ、または接続先サーバの所属ドメインに位置した別のセッション管理サーバに転送することが可能となる。
本発明によれば、一般のアプリケーションプログラムを実行するクライアントでも、セッション管理サーバによる認証機能を利用することによって、接続先サーバとの間で容易に暗号化通信を実現できる。

以下、本発明の実施例について図面を参照して説明する。
図４は、本発明が適用されるネットワーク構成の１例を示す。
ここに示したネットワークは、ＳＩＰサーバＳＩＰａが管理する第１ドメインを形成する第１のネットワークＮＷ１と、ＳＩＰサーバＳＩＰｂが管理する第２ドメインを形成する第２のネットワークＮＷ２と、ロケーションサーバＬＳＶと、ＤＮＳ（Domain Name System）とからなる。

第１のネットワークＮＷ１には、クライアントＣＬ１ａ、ＣＬ２ａと、サーバＳＶ１ａ、ＳＶ２ａが接続され、第２のネットワークＮＷ２には、クライアントＣＬ１ｂ、ＣＬ２ｂと、サーバＳＶ１ｂ、ＳＶ２ｂが接続されている。また、ＳＩＰサーバＳＩＰａは、ＳＩＰプロキシＰＲａとレジストラＰＧａとからなり、ＳＩＰサーバＳＩＰｂは、ＳＩＰプロキシＰＲｂレジストラＰＧｂとからなっている。

ここで、各クライアントおよびサーバに付随して括弧内に示した文字列は、ＳＩＰメッセージの転送先識別子（リソース識別子）となるＡＯＲ（Address-of-Record）形式のＳＩＰ−ＵＲＩの値を示している。第１ネットワークＮＷ１に接続されたクライアントとサーバには、ＳＩＰサーバＳＩＰａのドメイン識別子「aaa.com」を含むＡＯＲが割り当てられ、第２ネットワークＮＷ２に接続されたクライアントとサーバには、ＳＩＰサーバＳＩＰｂのドメイン識別子「bbb.com」を含むＡＯＲが割り当てられている。

本発明のＳＩＰサーバＳＩＰａ、ＳＩＰｂは、それぞれの管轄下にあるクライアントから、接続先サーバをＩＰアドレスで指定したＳＩＰメッセージを受信した時、ロケーションサーバＬＳＶに、上記接続先ＩＰアドレスと対応するＡＯＲ（リソース識別子）の検索（ロケーションデータ検索）を要求する。また、ＳＩＰサーバＳＩＰａ、ＳＩＰｂは、それぞれ他のＳＩＰサーバから、接続先サーバをＡＯＲで指定したＳＩＰメッセージを受信した時、ロケーションサーバＬＳＶに、上記接続先ＡＯＲと対応するＩＰアドレスの検索を要求する。

ロケーションサーバＬＳＶは、ロケーションサービス・データベース（ＤＢ）に、例えば、図５に示すように、ＳＩＰサーバＳＩＰａ、ＳＩＰｂの管轄下にあるクライアントおよびサーバと対応した複数のエントリＥＮ−１、ＥＮ−２，・・・からなり、各エントリが、クライアントまたはサーバのＡＯＲ６１とＩＰアドレス６２との対応関係を示すロケーションサービステーブル６０を備えている。ロケーションサーバＬＳＶは、ＳＩＰサーバからのロケーションデータ検索要求に応答して、上記ロケーションサービステーブル６０から、検索キーとして指定されたＩＰアドレス（またはＡＯＲ）と対応するＡＯＲ（またはＩＰアドレス）を検索し、検索結果を要求元ＳＩＰサーバに返送する。

図６は、ＳＩＰプロキシＰＲａのハードウェア構成を示す。
ＳＩＰプロキシＰＲａは、プロセッサ（ＣＰＵ）１１と、プロセッサが実行する各種ソフトウェアとデータを記憶するためのメモリ１２およびハードディスク１３と、ネットワークＮＷ１（ＮＷ２）に接続するためのネットワークインタフェース１４と、入出力装置１５とからなり、これらの要素は内部バス１６によって相互接続されている。ＳＩＰプロキシＰＲｂ、レジストラＲＧａ、ＲＧｂ、クライアントＣＬ１ａ〜ＣＬ２ｂ、サーバＳＶ１ａ〜ＳＶ２ｂも、基本的には、図６に示したＳＩＰプロキシＰＲａと同様の構成要素からなる。

以下、図４に示した第１ドメインに所属するクライアントＣＬ１ａが、第２ドメインに所属するサーバＳＶ１ｂと暗号化データ通信する場合の通信手順を例にして、本発明の第１の実施例について説明する。
図７は、クライアントＣＬ１ａの基本的なソフトウェア構造を示す。他のクライアントＣＬ１ｂ〜ＣＬ２ｂも、これと同様のソフトウェア構造となっている。

クライアントＣＬ１ａのソフトウェアは、ネットワークインタフェースカード部（ＮＩＣ）２０Ｃと、ＩＰｓｅｃ暗号化／復号化機能を備えたＩＰｓｅｃエンジン３１Ｃを含むＴＣＰ／ＩＰレイヤ部３０Ｃと、アプリケーションプログラム４０Ｃと、鍵管理プロセス部５０Ｃとからなる。第１実施例では、鍵管理プロセス部５０Ｃが、ＳＰ／ＳＡ（Security Policy/ Security Association）制御部５１Ｃと、ＴＬＳ（Transport Layer Security）部５２Ｃと、ＳＩＰメッセージ処理部５３Ｃとを備えたことを特徴としている。

図８は、サーバＳＶ１ｂの基本的なソフトウェア構造を示す。他のサーバＳＶ１ａ、ＳＶ２ａ、ＳＶ２ｂも、これと同様のソフトウェア構造となっている。
サーバＳＶ１ｂのソフトウェアは、ネットワークインタフェースカード部（ＮＩＣ）２０Ｓと、ＩＰｓｅｃ暗号化／復号化機能を備えたＩＰｓｅｃエンジン３１Ｓを含むＴＣＰ／ＩＰレイヤ部３０Ｓと、アプリケーションプログラム４０Ｓと、鍵管理プロセス部５０Ｓとからなり、鍵管理プロセス部５０Ｓが、ＳＰ／ＳＡ制御部５１Ｓと、ＴＬＳ部５２Ｓと、ＳＩＰメッセージ処理部５３Ｓとを備えている。

クライアントＣＬ１ａのアプリケーションプログラム４０ＣとサーバＳＶ１ｂのアプリケーションプログラム４０Ｓは、それぞれが備えるＩＰｓｅｃエンジン３１Ｃ、３１ＳのＩＰｓｅｃ暗号化／復号化機能を利用して、暗号化データを通信する。一方、クライアントＣＬ１ａのＳＩＰメッセージ処理部５３Ｃは、後述するＳＩＰサーバＳＩＰａ（ＳＩＰプロキシＰＲａ、レジストラＲＧａ）のＳＩＰメッセージ処理部との間で、それぞれが備えるＴＬＳ部のメッセージ暗号化／復号化機能を利用して、暗号化されたＳＩＰメッセージを通信する。同様に、サーバＳＶ１ｂのＳＩＰメッセージ処理部５３Ｓも、ＳＩＰサーバＳＩＰａ（ＳＩＰプロキシＰＲａ、レジストラＲＧａ）のＳＩＰメッセージ処理部との間で、それぞれが備えるＴＬＳ部のメッセージ暗号化／復号化機能を利用して、暗号化されたＳＩＰメッセージを通信する。

図９は、ＳＩＰプロキシＰＲａの基本的なソフトウェア構造を示す。ＳＩＰプロキシＰＲｂも、これと同様のソフトウェア構造となっている。
ＳＩＰプロキシＰＲａのソフトウェアは、ネットワークインタフェースカード部（ＮＩＣ）２０Ｐと、ＴＣＰ／ＩＰレイヤ部３０Ｐと、鍵管理プロセス部５０Ｐとからなり、鍵管理プロセス部５０Ｐが、ＴＬＳ部５２Ｐと、ＳＩＰメッセージ処理部５３Ｐとを備えている。ＳＩＰメッセージ処理部５３Ｐは、後述するＳＩＰ−ＵＲＬ（ＡＯＲ）検索機能５４を備えている。ＳＩＰプロキシＰＲａのＳＩＰメッセージ処理部５３Ｐは、ＴＬＳ部５２Ｐのメッセージ暗号化／復号化機能を利用して、管理下にあるドメインに所属したクライアント、サーバ、および他のドメインを管理する他のＳＩＰプロキシ、例えばＰＲｂと暗号化メッセージを通信する。

図１０は、レジストラＲＧａの基本的なソフトウェア構造を示す。レジストラＲＧｂも、これと同様のソフトウェア構造となっている。
レジストラＲＧａのソフトウェアは、ネットワークインタフェースカード部（ＮＩＣ）２０Ｒと、ＴＣＰ／ＩＰレイヤ部３０Ｒと、メッセージの暗号化／復号化機能を備えたＴＬＳ部５２Ｒと、ＳＩＰメッセージ処理部５３Ｒと、レジストラ処理部６０Ｒとからなっている。ＳＩＰメッセージ処理部５３Ｒは、クライアントが発行したＡＯＲ取得要求、またはＳＩＰプロキシＰＲａが発行したＡＯＲ取得要求を受信すると、レジストラ処理部６０Ｒにロケーションデータの検索を要求する。レジストラ処理部６０Ｒは、ＳＩＰメッセージ処理部５３Ｒからの要求に応答して、ロケーションサーバＬＳＶが備えるロケーションサービスＤＢをアクセスする。尚、レジストラＲＧａとＳＩＰプロキシＰＲａとの間の通信には、暗号化は適用されない。

図１１と図１２は、本発明による暗号化データ通信の第１の実施例を示すシーケンス図を示している。第１の実施例では、クライアントＣＬ１ａがＡＯＲ取得要求を発行する。
本実施例において、クライアントＣＬ１ａからの接続要求先となる第２ネットワークに接続されたサーバＳＶ１ｂは、クライアントＣＬ１ａからの接続要求に先立って、ＳＩＰサーバＳＩＰｂのレジストラＲＧｂとの間で、サーバＳＶ１ｂの認証と暗号化通信用のパラメータ設定のためのＴＬＳネゴシェーション（Ｓ１）を実行した後、レジストラＲＧｂにロケーション登録要求メッセージ（ＳＩＰメッセージ：REGISTER）Ｍ１を送信する。

ロケーション登録要求メッセージＭ１は、例えば、図１３に示すように、ＩＰヘッダＨ１と、ＵＤＰ／ＴＣＰヘッダＨ２とを付したＩＰパケット形式で送信される。ＩＰヘッダＨ１は、宛先アドレスとしてレジストラＲＧｂ（ＳＩＰサーバＳＩＰａ）のＩＰアドレス、送信元アドレスとしてサーバＳＶ１ｂのＩＰアドレスを含む。

ＳＩＰメッセージは、ＳＩＰメッセージの種類（Request-Method）を示すスタートラインと、要求または応答内容を記述したヘッダ部と、必要に応じてセッション内容を記述したメッセージボディ部とからなる。メッセージの種類によっては、上記スタートラインに、該メッセージの宛先を示すリソース識別子（Request-URI）が記述される。また、メッセージボディ部におけるセッション内容の記述には、ＲＦＣ３２６６で仕様化されたＳＤＰ（Session Description Protocol）が適用される。

サーバＳＶ２ｂが発行するロケーション登録要求メッセージＭ１の場合、スタートラインには、ＳＩＰメッセージの種類として「REGISTER」、メッセージ宛先を示すリソース識別子として、レジストラＲＧｂのＳＩＰ−ＵＲＩである「registrar.bbb.com」が含まれる。また、スタートラインに続くヘッダ部には、ＳＩＰメッセージの経路を示すＶｉａヘッダ、メッセージの宛先を示すＴｏヘッダ、メッセージの送信元を示すＦｒｏｍヘッダ、送信元で指定したセッション識別子を示すＣａｌｌ−ＩＤヘッダ、要求メソッドを示すＣＳｅｃヘッダ、ロケーションサービステーブルに登録すべきサーバＳＶ１ｂのＩＰアドレス「sv1＠192.0.2.4」を含むＣｏｎｔａｃｔヘッダ、メッセージの有効時間を示すＥｘｐｉｒｅｓヘッダ、後続するメッセージボディ部の長さを示すＣｏｎｔｅｎｔ−Ｌｅｎｇｔｈヘッダ、その他のヘッダ情報が含まれる。ロケーション登録要求メッセージＭ１の場合、メッセージボディ部は省略されるため、Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈヘッダには値「０」が設定され、ＴｏヘッダとＦｒｏｍヘッダには、要求元サーバＳＶ１ｂのＵＲＩの値「sv1＠bbb.com」が設定されている。

レジストラＲＧｂは、上記ロケーション登録要求メッセージＭ１を受信すると、ロケーションサービスＤＢのロケーションサービステーブル６０に、受信メッセージのＦｒｏｍヘッダが示す要求元ＵＲＩ「sv1＠bbb.com」とＣｏｎｔａｃｔヘッダが示す要求元ＩＰアドレス「sv1＠192.0.2.4」との関係を示すロケーションデータを登録し（Ｓ２）、ロケーションデータの登録が完了すると（Ｓ３）、要求元サーバＳＶ２ｂに、図１４に示すロケーション登録応答メッセージＭ２を送信する。ロケーション登録応答メッセージＭ２のスタートラインは、ＳＩＰメッセージの種類として、応答メッセージであることを示す「200 OK」を含み、ヘッダ部には、ロケーション登録要求メッセージＭ１と略同一内容のヘッダ情報が設定される。

この状態で、クライアントＣＬ１ａのユーザが、アプリケーションプログラムを立ち上げ、サーバＳＶ１ｂのＩＰアドレス宛にパケットを送信する操作を行った場合、本発明の第１の実施例では、クライアントＣＬ１ａが、ＳＩＰサーバＳＩＰａ（レジストラＲＧａ）との間で、クライアントの認証と暗号化通信用のパラメータ設定のためのＴＬＳネゴシェーション（Ｓ４）を実行した後、ＳＩＰサーバＳＩＰａ（レジストラＲＧａ）にＡＯＲ（Address-of-Record）取得要求メッセージ（ＳＩＰメッセージ：GET AOR）Ｍ３を送信する。

上記ＡＯＲ取得要求メッセージＭ３は、例えば、図１５に示すように、スタートラインに、ＳＩＰメッセージ種類を示す「GET AOR」と、レジストラＲＧａのＵＲＩである「registrar.aaa.com」を含み、Ｖｉａヘッダは、クライアントＣＬ１ａのＳＡ／ＳＰ処理部５１Ｃの識別子となるＵＲＩの値を示している。また、Ｔｏヘッダには、クライアントＣＬ１ａの接続相手となるサーバＳＶ１ｂのＩＰアドレス「192.0.2.4」が設定され、Ｆｒｏｍヘッダには、クライアントＣＬ１ａのＵＲＩ「cl1＠aaa.com」が設定されている。

レジストラＲＧａは、ＡＯＲ取得要求メッセージＭ３を受信すると、ロケーションサービスＤＢのロケーションサービステーブル６０から、受信メッセージのＴｏヘッダが示すＩＰアドレス「192.0.2.4」と対応するＡＯＲ（サーバＳＶ１ｂのＵＲＩ）の値を検索し（Ｓ５）、ロケーションデータＡＯＲの検索が完了すると（Ｓ６）、要求元クライアントＣＬ１ａにＡＯＲ取得応答メッセージＭ４を送信する。

ＡＯＲ取得応答メッセージＭ４は、図１６に示すように、スタートラインに、メッセージ種類が応答メッセージであることを示す「200 OK」を含み、ヘッダ部には、ＡＯＲ取得要求メッセージＭ３と略同一内容のヘッダ情報と、ロケーションサービステーブル６０から検索されたサーバＳＶ１ｂのＵＲＩの値「sv1＠bbb.com」を示すＡＯＲヘッダが記述されている。

上記ＡＯＲ取得応答メッセージＭ４の受信によって接続先サーバＳＶ１ｂのＵＲＬを取得したクライアントＣＬ１ａは、ＳＩＰサーバＳＩＰａのＳＩＰプロキシＰＲａとの間で、クライアントの認証と暗号化通信用のパラメータ設定のためのＴＬＳネゴシェーション（Ｓ７）を実行した後、ＳＩＰプロキシＰＲａに対して、サーバＳＶ１ｂへの接続要求メッセージＭ５を送信する。

接続要求メッセージＭ５は、図１７に示すように、接続要求メッセージのヘッダ部Ｍ５−１とボディ部Ｍ５−２とからなり、接続要求メッセージのヘッダ部Ｍ５−１は、スタートラインに、メッセージ種類「REGISTER」と、Ｒｅｑｕｅｓｔ−ＵＲＩとして、メッセージ宛先となるサーバＳＶ１ｂのＳＩＰ−ＵＲＩ「sv1＠bbb.com」を含む。また、ヘッダ情報として、クライアントＣＬ１ａにおけるＳＩＰメッセージ処理部５３ＣのＳＩＰ−ＵＲＩを示すＶｉａヘッダ、サーバＳＶ１ｂのＳＩＰ−ＵＲＩ「sv1＠bbb.com」を含むＴｏヘッダ、クライアントＣＬ１ａのＳＩＰ−ＵＲＩ「cl1＠aaa.com」を含むＦｒｏｍヘッダと、Ｃｏｎｔｅｎｔ−Ｔｙｐｅヘッダ、Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈヘッダ、その他の情報を含む。Ｃｏｎｔｅｎｔ−Ｔｙｐｅヘッダは、ボディ部Ｍ５−２が関係するアプリケーションプログラムを示し、Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈヘッダは、ボディ部Ｍ５−２の長さを示している。

接続要求メッセージＭ５のボディ部Ｍ５−２は、例えば、図１８に示すように、クライアントＣＬ１ａとサーバＳＶ１ｂとの間での暗号化通信に適用するＳＡ情報として、ＩＫＥにおける通常のＩＰｓｅｃ用ＳＡ設定時と同様、暗号化プロトコルの識別情報を示すプロポーザルペイロード９１と、トランスフォーム識別情報を示すトランスフォームペイロード９２、鍵交換ペイロード９３、要求元の識別情報を示す第１ＩＤペイロード９４と、接続先の識別情報を示す第２ＩＤペイロード９５を含んでいる。

ここでは、クライアントＣＬ１ａが、２つのトランスフォームペイロード９２−１、９２−２で、トランスフォームＩＤとして「ESP-AES」と「ESP-3DES」を提案しており、そのうちの１つを接続先サーバＳＶ１ｂが選択して、接続応答メッセージでクライアントに通知することになる。尚、第１ＩＤペイロード９４のＩＤデータは、要求元クライアントＣＬ１ａのＩＰアドレスを示し、第２ＩＤペイロード９５のＩＤデータは、接続先サーバＳＶ１ｂのＩＰアドレスを示す。

ＳＩＰプロキシＰＲａは、上記接続要求メッセージＭ５を受信すると、要求元クライアントＣＬ１ａにサーバＳＶ１ｂと接続中であることを通知するために、図１９に示す接続中メッセージＭ６を送信した後、接続先サーバＳＶ１ｂが所属するドメインのＳＩＰプロキシＰＲｂとの間で、相互の認証と暗号化通信用のパラメータ設定のためのＴＬＳネゴシェーション（Ｓ８）を実行する。接続中メッセージＭ６は、スタートラインに、メッセージ種類として、要求を実行中であることを示す「100 Trying」を含み、ヘッダ部に、接続要求メッセージＭ５から抽出されたＶｉａ、Ｔｏ、Ｆｒｏｍ、Ｃａｌｌ−ＩＤ、ＣＳｅｃ等の数項目のヘッダ情報を含み、メッセージボディ部は省略されている。

ＳＩＰプロキシＰＲａは、ＳＩＰプロキシＰＲｂとの間のＴＬＳネゴシェーションが終わると、クライアントから受信した接続要求メッセージＭ５に、自分のＳＩＰ−ＵＲＩ「proxy.aaa.com」を含む新たなＶｉａヘッダと、接続要求がＵＲＩ「proxy.aaa.com」を経由したことを示すＲｅｃｏｒｄ−Ｒｏｕｔｅヘッダを追加し、図２０に示す接続要求メッセージＭ７として、ＳＩＰプロキシＰＲｂに送信する。

ＳＩＰプロキシＰＲｂは、上記接続要求メッセージＭ７を受信すると、受信メッセージのスタートラインから宛先ＵＲＩ「SV1＠aaa.com」を抽出し、図１２に示すように、ロケーションサーバＬＳＶに対して、ロケーションサービスＤＢからの上記宛先ＵＲＩと対応したＩＰアドレスの検索（ロケーションデータ検索）を要求する（Ｓ９）。ＳＩＰプロキシＰＲｂは、ロケーションサービスＤＢの検索結果を示すロケーションデータ（ＩＰアドレス「sv1＠192.0.2.4」）を受信すると（Ｓ１０）と、上記接続要求メッセージＭ７の要求元ＳＩＰプロキシＰＲａに対して、図２１に示す接続中メッセージＭ８を送信した後、ＩＰアドレス「sv1＠192.0.2.4」で特定される接続先サーバＳＶ１ｂとの間で、相互の認証と暗号化通信用のパラメータ設定のためのＴＬＳネゴシェーション（Ｓ１１）を実行する。

ＳＩＰプロキシＰＲｂは、接続先サーバＳＶ１ｂとの間のＴＬＳネゴシェーションが終了すると、接続要求メッセージＭ７のＲｅｑｕｅｓｔ−ＵＲＩをＩＰアドレス「sv1＠192.0.2.4」に書き換え、自分のＳＩＰ−ＵＲＩ「proxy.bbb.com」を含む新たなＶｉａヘッダと、接続要求がＵＲＩ「proxy.bbb.com」を経由したことを示すＲｅｃｏｒｄ−Ｒｏｕｔｅヘッダを追加し、図２２に示す接続要求メッセージＭ９として接続先サーバＳＶ１ｂに送信する。

接続先サーバＳＶ１ｂは、上記接続要求メッセージＭ９に応答して、接続応答メッセージＭ１０を返信する。接続応答メッセージＭ１０は、図２３に示すように、ヘッダ部Ｍ１０−１とボディ部Ｍ１０−２とからなり、ヘッダ部Ｍ１０−１のスタートラインには、メッセージ種類として、応答メッセージであることを示す「200 OK」を含み、スタートラインに続いて、接続要求メッセージＭ９と同様の複数項目のヘッダ情報を含む。また、ボディ部Ｍ１０−２は、例えば、図２４に示すように、接続要求メッセージＭ１０のボディ部Ｍ５−２で提案された２つのトランスフォームペイロード９２−１、９２−２のうち、サーバＳＶ１ｂが選択した１つのトランスフォームペイロード（この例では、EPS-AES）を残している。

ＳＩＰプロキシＰＲｂは、接続応答メッセージＭ１０を受信すると、受信メッセージのヘッダ部から自ＵＲＩを含むＶｉａヘッダを除去し、図２５に示す接続応答メッセージＭ１１に変換して、ＳＩＰプロキシＰＲａに送信する。ＳＩＰプロキシＰＲａは、接続応答メッセージＭ１１を受信すると、受信メッセージのヘッダ部から自ＵＲＩを含むＶｉａヘッダを除去し、図２６に示す接続応答メッセージＭ１２に変換して、要求元クライアントＣＬ１ａに送信する。

要求元クライアントＣＬ１ａは、接続応答メッセージＭ１２を受信すると、受信メッセージのボディ部Ｍ１０−２を解析して、接続先サーバＳＶ１ｂとのＩＰｓｅｃ通信に適用すべきＳＡ情報を決定し、これをＳＡＤＢ３３Ｃに登録した後、図２７に示す接続確認メッセージＭ１３をＳＩＰプロキシＰＲａに送信する。接続確認メッセージＭ１３は、スタートラインに、メッセージ種類「ACK」と、Ｒｅｑｕｅｓｔ−ＵＲＩとしてサーバＳＶ１ｂのＳＩＰ−ＵＲＩを含み、ヘッダ情報として、Ｖｉａ、Ｔｏ、Ｆｒｏｍ、Ｃａｌｌ−ＩＤ、ＣＳｅｃ、Ｒｏｕｔｅヘッダを含み、メッセージボディ部は省略されている。Ｒｏｕｔｅヘッダには、接続応答メッセージＭ１２のＲｅｃｏｒｄ−Ｒｏｕｔｅヘッダから抽出されたＵＲＩの値が設定される。

上記接続確認メッセージＭ１３は、ＳＩＰプロキシＰＲａで新たなＶｉａヘッダを追加し、ＳＩＰプロキシＰＲａと対応するＲｏｕｔｅヘッダを除去して、図２８に示す接続確認メッセージＭ１４としてＳＩＰプロキシＰＲｂに転送される。ＳＩＰプロキシＰＲｂは、接続確認メッセージＭ１４に新たなＶｉａヘッダを追加し、ＳＩＰプロキシＰＲｂと対応するＲｏｕｔｅヘッダを除去し、図２９に示す接続確認メッセージＭ１５に変換して接続先サーバＳＶ１ｂに転送する。

サーバＳＶ１ｂが上記接続確認メッセージＭ１５を受信することによって、クライアントＣＬ１ａとサーバＳＶ１ｂは、ＩＰｓｅｃ暗号化を適用したアプリケーション間のデータ通信（Ｓ２０）が可能となる。すなわち、クライアントＣＬ１ａは、サーバＳＶ１ｂへの送信データをＳＡＤＢ３３Ｃに登録されているＳＡ情報に従って暗号化し、これをＩＰパケット形式で送信する。サーバＳＶ１ｂは、クライアントＣＬ１ａからの受信データをＳＡＤＢ３３Ｖに登録されているＳＡ情報に従って復号化し、クライアントＣＬ１ａへの送信データを上記ＳＡ情報に従って暗号化して、ＩＰパケット形式で送信できる。

クライアントＣＬ１ａは、サーバＳＶ１ｂとの間でのデータ通信が終了すると、ＳＩＰプロキシＰＲａに対して、図３０に示す切断要求メッセージＭ２０を送信する。切断要求メッセージＭ２０は、スタートラインに、メッセージ種類「BYE」とサーバＳＶ１ｂのＳＩＰ−ＵＲＩを含み、ヘッダ情報として、接続確認メッセージＭ１３と同様、Ｖｉａ、Ｔｏ、Ｆｒｏｍ、Ｃａｌｌ−ＩＤ、ＣＳｅｃ、Ｒｏｕｔｅヘッダを含み、メッセージボディ部は省略される。

ＳＩＰプロキシＰＲａは、上記切断要求メッセージＭ２０を受信すると、要求元のクライアントＶＬ１ａに対して、図３１に示す切断中メッセージＭ２１を送信した後、切断要求メッセージＭ２０に新たなＶｉａヘッダを追加し、ＳＩＰプロキシＰＲａと対応するＲｏｕｔｅヘッダを除去し、図３２に示す切断要求メッセージＭ２２として、ＳＩＰプロキシＰＲｂに送信する。切断中メッセージＭ２１は、スタートラインに、メッセージ種類として、要求を実行中であることを示す「110 Trying」を含み、ヘッダ部に、切断要求メッセージＭ２０から抽出されたＶｉａ、Ｔｏ、Ｆｒｏｍ、Ｃａｌｌ−ＩＤ、ＣＳｅｃ等の数項目のヘッダ情報を含み、メッセージボディ部は省略されている。

ＳＩＰプロキシＰＲｂは、上記切断要求メッセージＭ２２を受信すると、ＳＩＰプロキシＰＲａに対して、図３３に示す切断中メッセージＭ２３を送信した後、切断要求メッセージＭ２２に新たなＶｉａヘッダを追加し、ＳＩＰプロキシＰＲｂと対応するＲｏｕｔｅヘッダを除去し、図３４に示す切断要求メッセージＭ２４として、サーバＳＶ１ｂに送信する。

サーバＳＶ１ｂは、切断要求メッセージＭ２４を受信すると、図３５に示す切断応答メッセージＭ２５をＳＩＰプロキシＰＲｂに送信する。切断応答メッセージＭ２５は、スタートラインに、メッセージ種類として、応答を示す「200 OK」を含み、ヘッダ部に、切断要求メッセージＭ２４から抽出されたＶｉａ、Ｔｏ、Ｆｒｏｍ、Ｃａｌｌ−ＩＤ、ＣＳｅｃ等の数項目のヘッダ情報を含み、メッセージボディ部は省略されている。

ＳＩＰプロキシＰＲｂは、切断応答メッセージＭ２５を受信すると、受信メッセージのヘッダ部から自ＵＲＩを含むＶｉａヘッダを除去し、図３６に示す切断応答メッセージＭ２６に変換して、ＳＩＰプロキシＰＲａに送信する。ＳＩＰプロキシＰＲａは、切断応答メッセージＭ２６を受信すると、受信メッセージのヘッダ部から自ＵＲＩを含むＶｉａヘッダを除去し、図３７に示す切断応答メッセージＭ２７に変換して、要求元クライアントＣＬ１ａに送信する。要求元クライアントＣＬ１ａは、上記切断応答メッセージＭ２７を受信すると、ＩＰｓｅｃ暗号化／復号化を終了し、同一または別のアプリケーションによる新たなパケット送信要求を待つ。

次に、図３８〜図４８を参照して、上述した本発明の第１実施例の暗号化データ通信を可能にするクライアントＣＬ１ａ、ＳＩＰサーバＳＩＰａ（ＳＩＰプロキシＰＲａ、レジストラＲＧａ）、サーバＳＶ２ｂの制御動作について説明する。
図３８は、クライアントＣＬ１ａにおいて、ＩＰｓｅｃエンジン３１が発行する暗号鍵交換要求に応答してＳＰ／ＳＡ制御部５１Ｃが実行する制御動作のフローチャート１００を示す。

クライアントＣＬ１ａのＩＰｓｅｃエンジン３１Ｃは、アプリケーション４０ＣからＩＰパケットの送信要求を検出すると、ＳＰＤＢ（Security Policy Data Base）３２Ｃを参照して、上記ＩＰパケットにＩＰｓｅｃ暗号化の適用要否を判定する。ＩＰｓｅｃ暗号化を適用すべきと判断した場合、ＩＰｓｅｃエンジン３１Ｃは、ＳＡＤＢ（Security Association Data Base）３３Ｃから、上記ＩＰパケットに適用すべき暗号鍵などのＳＡ（Security Association）情報を検索する。ここで、ＳＡＤＢにＩＰパケットに適用すべきＳＡ情報が未登録の場合、ＩＰｓｅｃエンジン３１Ｃは、鍵管理プロセス５０Ｃに対して、通信相手との暗号化パラメータの交換（鍵交換）を要求する。

本実施例では、ＩＰｓｅｃエンジン３１Ｃからの上記鍵交換要求をＳＰ／ＳＡ制御部５１Ｃで処理する。ＳＰ／ＳＡ制御部５１Ｃは、鍵交換要求を受信すると、鍵交換要求が示すＴＣＰ／ＩＰ通信パラメータと、ＳＰ／ＳＡ制御部５１Ｃが管理している利用可能なＳＡ情報とに基づいて、図１８に例示した接続要求メッセージのボディ部Ｍ５−２を作成し（ステップ１０１）、該接続要求メッセージボディ部Ｍ５−２をＳＩＰメッセージ処理部５３Ｃに渡し（１０２）、ＳＩＰメッセージ処理部５３Ｃからの接続応答メッセージボディ部の受信を待つ（１０３）。

ＳＰ／ＳＡ制御部５１Ｃは、ＳＩＰメッセージ処理部５３Ｃから、図２４に例示した接続応答メッセージボディ部Ｍ１０−２を受信すると、受信した接続応答メッセージボディ部を解析し、今回のＩＰｓｅｃ通信に使用すべきＳＡ情報を決定し（１０４）、ＩＰｓｅｃエンジン３１Ｃに、ＳＡＤＢ３３Ｃに設定すべきＳＡ情報を通知する（１０５）。

図３９（図３９Ａ、３９Ｂ）は、ＳＰ／ＳＡ制御部５１Ｃから接続要求メッセージのボディ部を受信した時、ＳＩＰメッセージ処理部５３Ｃが実行する制御動作のフローチャート１１０を示す。
ＳＩＰメッセージ処理部５３Ｃは、ＳＰ／ＳＡ制御部５１Ｃから接続要求メッセージのボディ部を受信すると、第２ＩＤペイロードのＩＤデータが示す接続先サーバのＩＰアドレスと、ＳＩＰメッセージ処理部５３Ｃが管理している通信制御パラメータとから、図１５に例示したＡＯＲ取得要求メッセージＭ３を作成し（ステップ１１１）、該メッセージをＴＳＬ部５２Ｃ、ＴＣＰ／ＩＰ部３０Ｃ、ＮＩＣ部２０Ｃを介して、クライアントＣＬ１ａと同一ドメインに位置するＳＩＰサーバＳＩＰａ（レジストラＲＧａ）宛に送信する（１１２）。このとき、ＴＬＳ部５２Ｃは、レジストラＲＧａとの間でＴＬＳネゴシェーション（図１１のＳ５）を実行した後、ＴＬＳ暗号化されたＡＯＲ取得要求メッセージＭ３をＴＣＰ／ＩＰ部３０Ｃ、ＮＩＣ部２０Ｃを介してレジストラＲＧａに送信する。上記ＡＯＲ取得要求メッセージＭ３は、ＴＣＰ／ＩＰ部３０Ｃによって、ＳＩＰサーバＳＶ１宛の宛先ＩＰアドレスを含むＩＰヘッダＨ１とＵＤＰ／ＴＣＰヘッダＨ２とが付加され、ＩＰパケット形式でネットワークＮＷ１に送出される。

ＳＩＰメッセージ処理部５３Ｃは、レジストラＲＧａからのＡＯＲ取得応答メッセージを待っており（１１３）、ＡＯＲ取得応答メッセージを受信すると、受信メッセージを解析し（１１４）、ＡＯＲヘッダから接続先サーバに割り当てられたＡＯＲ形式のＳＩＰ−ＵＲＩを抽出する（１１５）。この後、ＳＩＰメッセージ処理部５３Ｃは、上記ＳＩＰ−ＵＲＩをスタートラインとＴｏヘッダに適用して、ヘッダ部Ｍ５−１とＳＰ／ＳＡ制御部５１Ｃから受信したボディ部Ｍ５−２とからなる図１７に例示した接続要求メッセージＭ５を作成する（１１６）。

ＳＩＰメッセージ処理部５３Ｃは、上記接続要求メッセージをＴＳＬ部５２Ｃ、ＴＣＰ／ＩＰ部３０Ｃ、ＮＩＣ部２０Ｃを介して、ＳＩＰサーバＳＩＰａのＳＩＰプロキシＰＲａ宛に送信し（１１７）、ＳＩＰプロキシＰＲａからの応答を待つ（１１８）。ＳＩＰプロキシＰＲａから接続中メッセージＭ６を受信した場合は、接続中メッセージ処理（１１９）を実行した後、ＳＩＰプロキシＰＲａからの次の応答を待つ。

ＳＩＰメッセージ処理部５３Ｃは、ＳＩＰプロキシＰＲａから接続応答メッセージＭ１２を受信すると、受信メッセージを解析し（１２０）、受信メッセージから抽出した図２４に例示した接続応答メッセージボディ部Ｍ１２−２をＳＰ／ＳＡ制御部５１Ｃに渡す（１２１）。この後、ＳＩＰメッセージ処理部５３Ｃは、図２７に例示した接続確認メッセージＭ１３を作成し、これをＴＳＬ部５２Ｃ、ＴＣＰ／ＩＰ部３０Ｃ、ＮＩＣ部２０Ｃを介して、ＳＩＰプロキシＰＲａ宛に送信し（１２２）、このルーチンを終了する。

図４０は、ＡＯＲ取得要求メッセージＭ３を受信した時、レジストラＲＧａのＳＩＰメッセージ処理部５３Ｒが実行する制御動作のフローチャート２００を示す。
レジストラＲＧａのＳＩＰメッセージ処理部５３Ｒは、受信したＡＯＲ取得要求メッセージＭ３を解析し（ステップ２０１）、Ｔｏヘッダが示す接続先サーバＳＶ１ｂのＩＰアドレスを検索キーとして、ロケーションデータ検索クエリを作成し（２０２）、レジストラ処理部６０Ｒを介して、上記検索クエリをロケーションサーバＬＳＶに送信し（２０３）、ロケーションサーバからの応答を待つ（２０４）。

ＳＩＰメッセージ処理部５３Ｒは、レジストラ処理部６０Ｒを介して、ロケーションサーバＬＳＶからロケーションデータを受信すると、受信データが示すＳＩＰ−ＵＲＩをＡＯＲヘッダとして含む図１６に例示したＡＯＲ取得応答メッセージＭ４を作成し（２０５）、該メッセージＭ４をＴＣＰ／ＩＰ部３０Ｒ、ＮＩＣ部２０Ｒを介してＡＯＲ取得要求メッセージＭ３の送信元（この例では、クライアントＣＬ１ａ）に送信し（２０６）、このルーチンを終了する。

図４１（図４１Ａ〜図４１Ｄ）は、クライアントＣＬ１ａから接続要求メッセージＭ５を受信した時、ＳＩＰプロキシＰＲａのＳＩＰメッセージ処理部５３Ｐが実行する制御動作のフローチャート３００を示す。
ＳＩＰプロキシＰＲａのＳＩＰメッセージ処理部５３Ｐは、クライアントＣＬ１ａからの接続要求メッセージＭ５を受信すると、受信メッセージを解析し（ステップ３０１）、受信メッセージのスタートラインに記述されたＲｅｑｕｅｓｔ−ＵＲＩをチェックして（３０２）、上記Ｒｅｑｕｅｓｔ−ＵＲＩが示すドメイン名から、受信メッセージの転送先を判定する（３０３）。

受信メッセージの転送先が他のドメインに所属していると判定された場合、ＳＩＰメッセージ処理部５３Ｐは、ＤＮＳ検索（ＮＡＰＴＲ検索＋ＳＲＶ検索＋Ａ検索）等によって、受信メッセージの転送先ドメインのＳＩＰサーバ（ＳＩＰプロキシ）を決定する（３０４）。図１１で示した例では、ＤＮＳ検索によって、接続要求メッセージＭ５の転送先が、ＳＩＰプロキシＰＲｂであることが判明する。この場合、ＳＩＰメッセージ処理部５３Ｐは、図１９で例示した接続中メッセージＭ６をＴＬＳ部５２Ｐ、ＴＣＰ／ＩＰ部３０Ｐ、ＮＩＣ部２０Ｐを介して、接続要求メッセージＭ５の送信元であるクライアントＣＬ１ａに送信（３０５）した後、接続要求メッセージＭ５に新たなＶｉａヘッダを付加した形の接続要求メッセージＭ７をＳＩＰプロキシＰＲｂに転送して（３０６）、ＳＩＰプロキシＰＲｂからの応答を待つ（３０７）。

ＳＩＰメッセージ処理部５３Ｐは、ＳＩＰプロキシＰＲｂから接続中メッセージＭ８を受信すると、接続中メッセージ処理（３０８）を実行した後、ＳＩＰプロキシＰＲｂからの次の応答を待つ。ＳＩＰメッセージ処理部５３Ｐは、ＳＩＰプロキシＰＲｂから接続応答メッセージＭ１１を受信すると、受信メッセージを解析し（３０９）、受信メッセージから自ＳＩＰ−ＵＲＩを含むＶｉａヘッダを除去し、接続応答メッセージＭ１２として、接続要求元（クライアントＣＬ１ａ）に転送する（３１０）。この後、ＳＩＰメッセージ処理部５３Ｐは、接続要求元（クライアントＣＬ１ａ）からの応答を待つ（３１１）。ＳＩＰメッセージ処理部５３Ｐは、接続確認メッセージＭ１３を受信すると、受信メッセージを解析し（３１２）、受信メッセージに自分のＳＩＰ−ＵＲＩを含む新たなＶｉａヘッダを付加し、接続確認メッセージＭ１３として、ＳＩＰプロキシＰＲｂに転送して（３１３）、このルーチンを終了する。

判定ステップ３０３で、クライアント端末ＣＬ１ａから受信した接続要求メッセージの転送先が、例えば、サーバＳＶ１ａ（またはＳＶ２ａ）のように、ＳＩＰプロキシＰＲａと同一ドメインに所属していると判定された場合、ＳＩＰメッセージ処理部５３Ｐは、受信メッセージのＲｅｑｕｅｓｔ−ＵＲＩが示すＳＩＰ−ＵＲＩを検索キーとするロケーションデータ（ＩＰアドレス）検索クエリを作成し（３１５）、該ロケーションデータ検索クエリをロケーションサーバＬＳＶに送信して（３１６）、ロケーションサービス応答を待つ（３１７）。

ＳＩＰメッセージ処理部５３Ｐは、ロケーションサーバＬＳＶからロケーションデータを受信すると、上記ロケーションデータが示す接続先サーバのＩＰアドレスを宛先ＩＰアドレスに適用して、接続要求メッセージをＩＰパケット形式でネットワークＮＷ１に送信し（３１８）、接続先サーバからの応答を待つ（３１９）。上記接続要求メッセージには、ＳＩＰプロキシＰＲａのＳＩＰ−ＵＲＩを含む新たなＶｉａヘッダが付加されている。

接続先サーバから接続応答メッセージを受信すると、ＳＩＰメッセージ処理部５３Ｐは、受信メッセージを解析し（３２０）、自分と対応するＶｉａヘッダを除去した形の接続応答メッセージを接続要求元に転送して（３２１）、接続要求元（クライアントＣＬ１ａ）からの応答を待つ（３２２）。ＳＩＰメッセージ処理部５３Ｐは、接続要求元から接続確認メッセージを受信すると、受信メッセージを解析し（３２３）、新たなＶｉａヘッダを付加した形の接続確認メッセージを接続先サーバに転送して（３２４）、このルーチンを終了する。

図４２（図４２Ａ、図４２Ｂ）は、接続先サーバＳＶ１ｂのＳＩＰメッセージ処理部５３Ｓが、ＳＩＰプロキシＰＲｂから接続要求メッセージＭ９を受信した時に実行する制御動作のフローチャート４００を示す。
ＳＩＰプロキシＰＲｂから接続先サーバＳＶ１ｂに送信された接続要求メッセージＭ９は、ＴＬＳ部５２Ｓで復号化した後、ＳＩＰメッセージ処理部５３Ｓに入力される。ＳＩＰメッセージ処理部５３Ｓは、接続要求メッセージＭ９を受信すると、受信メッセージを解析し（ステップ４０１）、受信メッセージから抽出した接続要求メッセージボディ部Ｍ５−２をＳＰ／ＳＡ制御部５１Ｓに渡し（４０２）、ＳＰ／ＳＡ制御部５１Ｓからの応答を待つ（４０３）。

ＳＩＰメッセージ処理部５３Ｓは、ＳＰ／ＳＡ制御部５１Ｓから接続応答メッセージボディ部Ｍ１０−２を受信すると、図２５に例示した接続応答メッセージＭ１１を作成する（４０４）。ＳＩＰメッセージ処理部５３Ｓは、ＴＬＳ部、ＴＣＰ／ＩＰ部、ＮＩＣ部を介して、上記接続応答メッセージＭ１１をＳＩＰプロキシＰＲｂに転送し（４０５）、ＳＩＰプロキシＰＲｂからの応答を待つ（４０６）。ＳＩＰメッセージ処理部５３Ｓは、ＳＩＰプロキシＰＲｂから、接続確認メッセージＭ１５を受信すると、受信メッセージを解析し（４０７）、接続確認メッセージＭ１５を受信したことをＳＰ／ＳＡ制御部５１Ｓに通知して（４０８）、このルーチンを終了する。

図４３は、ＳＩＰメッセージ処理部５３Ｓから接続要求メッセージボディ部Ｍ５−２を受信した時、サーバＳＶ１ｂのＳＰ／ＳＡ制御部５１Ｓが実行する制御動作の示すフローチャート４２０を示す。
ＳＰ／ＳＡ制御部５１Ｓは、ＳＩＰメッセージ処理部５３Ｓから受信した接続要求メッセージボディ部Ｍ５−２を解析し（ステップ４２１）、接続要求メッセージボディ部Ｍ５−２に記述されたＳＡ情報（図１８の例では、トランスフォームペイロード９２−１、９２−２）から、クライアントとの暗号化通信に適用すべきＳＡを選択して、図２４に例示した接続応答メッセージのボディ部Ｍ１０−２を作成する（４２２）。ＳＰ／ＳＡ制御部５１Ｓは、上記接続応答メッセージボディ部Ｍ１０−２をＳＩＰメッセージ処理部５３Ｓに渡し（４２３）、ＳＩＰメッセージ処理部５３Ｓからの応答を待つ（４２４）。ＳＰ／ＳＡ制御部５１Ｓは、ＳＩＰメッセージ処理部５３Ｓから接続確認メッセージの受信通知を受けると、ＩＰｓｅｃエンジン３１Ｓに対して、ＳＡＤＢ３３Ｓに設定すべきＳＡ情報を通知して（４２５）、このルーチンを終了する。

図４４は、クライアントＣＬ１ａにおいて、ＩＰｓｅｃエンジン３１Ｃが発行する暗号鍵消去要求に応答してＳＡ／ＳＰ処理部５１Ｃが実行する制御動作のフローチャート１３０を示す。
クライアントＣＬ１ａのユーザが、サーバＳＶ１ｂと交信していたアプリケーションを終了すると、ＩＰｓｅｃエンジン３１ＣからＳＡ／ＳＰ制御部５１Ｃに、暗号鍵消去要求が発行される。ＳＡ／ＳＰ制御部５１Ｃは、ＩＰｓｅｃエンジン３１Ｃから暗号鍵消去要求を受信すると、ＳＩＰメッセージ処理部５３Ｃに、切断要求メッセージの発行を要求し（１３１）、ＳＩＰメッセージ処理部５３Ｃからの応答を待つ（１３２）。ＳＡ／ＳＰ制御部５１Ｃは、ＳＩＰメッセージ処理部５３Ｃから切断応答メッセージの受信通知を受けると、ＩＰｓｅｃエンジン３１Ｃに対して、上記暗号鍵消去要求と対応するＳＡＤＢの設定値消去を指示し（１３３）、このルーチンを終了する。

図４５は、ＳＡ／ＳＰ制御部５１Ｃから切断要求メッセージの発行要求を受信した時にＳＩＰメッセージ処理部５３Ｃが実行する制御動作のフローチャート１４０を示す。
ＳＩＰメッセージ処理部５３Ｃは、ＳＡ／ＳＰ制御部５１Ｃから切断要求メッセージの発行要求を受信すると、図３０に例示した切断要求メッセージＭ２０を作成し（ステップ１４１）、ＴＬＳ部５２Ｃ、ＴＣＰ／ＩＰ部３０ＣのＩＰｓｅｃエンジン３１Ｃ、ＮＩＣ部２０Ｃを介して、上記切断要求メッセージＭ２０のＩＰパケットをＳＩＰサーバＳＩＰａ（ＳＩＰプロキシＰＲａ）に送信する（１４２）。

ＳＩＰメッセージ処理部５３Ｃは、ＳＩＰプロキシＰＲａからの応答を待ち（１４３）、切断中メッセージＭ２１を受信した場合は、切断中メッセージ処理（１４４）を実行した後、ＳＩＰプロキシＰＲａからの次の応答を待つ。ＳＩＰメッセージ処理部５３Ｃは、ＳＩＰプロキシＰＲａから図３７に例示した切断応答メッセージＭ２７を受信すると、受信メッセージを解析し（１４５）、ＳＰ／ＳＡ制御部５１Ｃに切断応答メッセージの受信を通知し（１４６）、このルーチンを終了する。

図４６（図４６Ａ、図４６Ｂ）は、クライアントから切断要求メッセージＭ２０を受信した時にＳＩＰプロキシＰＲａのＳＩＰメッセージ処理部５３Ｐが実行する制御動作のフローチャート３４０を示す。
ＳＩＰメッセージ処理部５３Ｐは、受信した切断要求メッセージＭ２０を解析し（ステップ３４１）、受信メッセージのＲｅｑｕｅｓｔ−ＵＲＩをチェックする（３４２）。ＳＩＰメッセージ処理部５３Ｐは、Ｒｅｑｕｅｓｔ−ＵＲＩに記述されたドメイン名から、受信メッセージの転送先を判定し（３４３）、転送先が他のドメインに所属していると判定された場合、ＤＮＳ検索（ＮＡＰＴＲ検索＋ＳＲＶ検索＋Ａ検索）等によって、受信メッセージの転送先ドメインのＳＩＰサーバ（ＳＩＰプロキシ）を決定する（３４４）。

図１２で示した例では、上記ＤＮＳ検索によって、切断要求メッセージＭ２０の転送先が、ＳＩＰプロキシＰＲｂであることが判明する。この場合、ＳＩＰメッセージ処理部５３Ｐは、ＴＬＳ部５２Ｐ、ＴＣＰ／ＩＰ部３０Ｐ、ＮＩＣ部２０Ｐを介して、切断要求メッセージＭ２０の送信元であるクライアントＣＬ１ａに、図３１に例示した切断中メッセージＭ２１を送信（３４５）した後、切断要求メッセージＭ２０に新たなＶｉａヘッダを付加し、ＳＩＰプロキシＰＲａに対応するＲｏｕｔｅヘッダを除去した切断要求メッセージＭ２２をＳＩＰプロキシＰＲｂに転送し（３４６）、ＳＩＰプロキシＰＲｂからの応答を待つ（３４７）。

ＳＩＰメッセージ処理部５３Ｐは、ＳＩＰプロキシＰＲｂから切断中メッセージＭ２３を受信すると、切断中メッセージ処理（３４８）を実行した後、ＳＩＰプロキシＰＲｂからの次の応答を待つ。ＳＩＰメッセージ処理部５３Ｐは、ＳＩＰプロキシＰＲｂから切断応答メッセージＭ２６を受信すると、受信メッセージを解析し（３４９）、受信メッセージから自ＳＩＰ−ＵＲＩを含むＶｉａヘッダを除去し、切断応答メッセージＭ２７として、切断要求元（クライアントＣＬ１ａ）に転送し（３５０）、このルーチンを終了する。

尚、判定ステップ３４３で、もし、クライアント端末ＣＬ１ａから受信した切断要求メッセージＭ２０の転送先が、ＳＩＰプロキシＰＲａと同一ドメインに所属していると判定された場合、ＳＩＰメッセージ処理部５３Ｐは、受信メッセージのＲｅｑｕｅｓｔ−ＵＲＩが示すＳＩＰ−ＵＲＩを検索キーとするロケーションデータ（ＩＰアドレス）検索クエリを作成し（３５１）、該検索クエリをロケーションサーバＬＳＶに送信して（３５２）、ロケーションサービス応答を待つ（３５３）。

ＳＩＰメッセージ処理部５３Ｐは、ロケーションサーバＬＳＶからロケーションデータを受信すると、上記ロケーションデータが示すサーバＩＰアドレスを宛先ＩＰアドレスに適用して、切断要求メッセージのＩＰパケットをネットワークＮＷ１に送信し（３５４）、サーバからの応答を待つ（３５５）。尚、上記切断要求メッセージには、ＳＩＰプロキシＰＲａのＳＩＰ−ＵＲＩを含む新たなＶｉａヘッダが付加されている。
切断要求メッセージの宛先サーバから切断応答メッセージを受信すると、ＳＩＰメッセージ処理部５３Ｐは、受信メッセージを解析し（３５６）、自分のＶｉａヘッダを除去した形の切断応答メッセージを切断要求元に転送し（３５７）、このルーチンを終了する。

図４７は、ＳＩＰプロキシから切断要求メッセージＭ２４を受信した時、サーバＳＶ１ｂのＳＩＰメッセージ処理部５３Ｓが実行する制御動作のフローチャート４３０を示す。
ＳＩＰメッセージ処理部５３Ｓは、ＴＬＳ部５２Ｓを介して切断要求メッセージＭ２４を受信すると、受信メッセージを解析し（ステップ４３１）、ＳＰ／ＳＡ制御部５１Ｓに対して、切断すべき通信の識別情報（例えば、Ｃａｌｌ−ＩＤ）を指定して、切断要求の受信を通知し（４３２）、ＳＰ／ＳＡ制御部５１Ｓからの応答を待つ（４３３）。ＳＩＰメッセージ処理部５３Ｓは、ＳＰ／ＳＡ制御部５１Ｓから切断応答を受信すると、図３５に例示した切断応答メッセージＭ２５を作成し（４３４）、ＴＬＳ部、ＴＣＰ／ＩＰ部、ＮＩＣ部を介してＳＩＰプロキシＰＲｂに転送し（４３５）、このルーチンを終了する。

図４８は、ＳＩＰメッセージ処理部５３Ｓから切断要求の発生を通知された時、ＳＰ／ＳＡ制御部５１Ｓが実行する制御動作のフローチャート４４０を示す。
ＳＰ／ＳＡ制御部５１Ｓは、通知された通信識別情報にもとづいて、ＳＡＤＢ３３Ｓから消去すべきＳＡ情報を特定し（ステップ４４１）、ＩＰｓｅｃエンジン３１Ｓに上記ＳＡ情報の消去を指示し（４４２）、このルーチンを終了する。

次に、図４９から図５９を参照して、本発明による暗号化データ通信の第２の実施例について説明する。
上述した第１実施例では、接続先サーバをＩＰアドレスで指定した形でパケット送信要求が発生した時、クライアントのＳＩＰメッセージ処理部５３Ｃが、上記接続先ＩＰアドレスと対応したＳＩＰ−ＵＲＩを取得するためのＡＯＲ取得要求を発行し、レジストラから取得したＳＩＰ−ＵＲＩを適用して、ＳＩＰプロキシ宛の接続要求メッセージを発行した。

本発明の第２実施例は、接続先サーバをＩＰアドレスで指定した形でパケット送信要求が発生した時、クライアントが、接続先サーバをＩＰアドレスで指定した形の接続要求メッセージを発行し、該接続要求メッセージを受信したＳＩＰプロキシが、受信メッセージのスタートラインに記述されたＲｅｑｕｅｓｔ−ＵＲＩの形式をチェックし、接続先がＩＰアドレスで指定されていた場合、これをＳＩＰ−ＵＲＩに書き換えて、接続先サーバの所属ドメインに位置する他のＳＩＰサーバに接続要求メッセージを転送するようにしたことを特徴とする。

図４９と図５０は、本発明の第２実施例における暗号化通信シーケンス図を示す。図１１、図１２と同一符号で示された第１実施例で説明済みのステップとメッセージについては、できるだけ説明を省略する。
本発明の第２実施例では、クライアントＣＬ１ａは、接続先サーバをＩＰアドレスで指定した形でパケット送信要求が発生した時、ＳＩＰプロキシＰＲａとの間で、クライアントの認証と暗号化通信用パラメータ設定のためのＴＬＳネゴシェーション（Ｓ７）を実行した後、ＳＩＰプロキシＰＲａに対して、直ちに接続要求メッセージＭ５ｘを送信する。ここで送信される接続要求メッセージＭ５ｘは、図５１に示すように、スタートラインに記述されるＲｅｑｕｅｓｔ−ＵＲＩと、ヘッダ部に記述されるＴｏヘッダが、接続先サーバＳＶ１ｂをＩＰアドレス「192.0.2.4」で指定している。ヘッダ部のその他のヘッダ情報と、接続要求メッセージボディ部Ｍ５−２の内容は、図１７および図１８に示した第１実施例の接続要求メッセージＭ５と同一である。

ＳＩＰプロキシＰＲａは、受信した接続要求メッセージＭ５ｘのＲｅｑｕｅｓｔ−ＵＲＩが「SIP:IPアドレス」形式となっているため、ロケーションサービスＤＢのロケーションサービステーブル６０から、上記ＩＰアドレス「192.0.2.4」と対応するＡＯＲ（ＳＩＰ−ＵＲＩ）を検索する（Ｓ５）。ＳＩＰプロキシＰＲａは、ロケーションサービステーブル６０からＡＯＲ「sv1＠bbb.com」を取得すると（Ｓ６）、要求元クライアントＣＬ１ａに、図５２に示す接続中メッセージＭ６ｘを送信した後、接続先サーバＳＶ１ｂが所属するドメインのＳＩＰプロキシＰＲｂとの間で、相互の認証と暗号化通信用のパラメータ設定のためにＴＬＳネゴシェーション（Ｓ８）を実行する。接続中メッセージＭ６ｘの内容は、ＩＰアドレス記述となっているＴｏヘッダを除いて、図１９に示した第１実施例の接続中メッセージＭ６と同一である。

ＳＩＰプロキシＰＲａは、ＳＩＰプロキシＰＲｂとの間のＴＬＳネゴシェーションが終了すると、ＳＩＰプロキシＰＲｂに対して、図５３に示す接続要求メッセージＭ７ｘを送信する。接続要求メッセージＭ７ｘは、クライアントＣＬ１ａから受信した接続要求メッセージＭ５ｘに、ＳＩＰプロキシＰＲａのＳＩＰ−ＵＲＩを含むＶｉａヘッダを追加し、
スタートラインのＲｅｑｕｅｓｔ−ＵＲＩをＩＰアドレス「192.0.2.4」からＳＩＰ−ＵＲＩ「sv1＠bbb.com」に書き換えた内容となっている。以下、第１実施例の同様の通信シーケンスが実行され、アプリケーション間のデータ通信状態（Ｓ２０）に至る。

ＳＩＰプロキシＰＲｂからＳＩＰプロキシＰＲａに送信される接続中メッセージＭ８ｘ、ＳＩＰプロキシＰＲｂから接続先サーバＳＶ１ｂに送信される接続要求メッセージＭ９ｘ、サーバＳＶ１ｂからＳＩＰプロキシＰＲｂに送信される接続応答メッセージＭ１０ｘ、ＳＩＰプロキシＰＲｂからＳＩＰプロキシＰＲａに送信される接続応答メッセージＭ１１ｘ、ＳＩＰプロキシＰＲａに要求元クライアントＣＬ１ａに送信される接続応答メッセージＭ１２ｘ、クライアントＣＬ１ａからＳＩＰプロキシＰＲａに送信される接続確認メッセージＭ１３ｘ、ＳＩＰプロキシＰＲａからＳＩＰプロキシＰＲｂに送信される接続確認メッセージＭ１４ｘ、ＳＩＰプロキシＰＲｂからサーバＳＶ１ｂに送信される接続確認メッセージＭ１５ｘは、ＩＰアドレス記述となっているＴｏヘッダを除いて、それぞれ第１実施例で例示したＳＩＰメッセージＭ８〜Ｍ１５と同一内容となる。

クライアントＣＬ１ａは、サーバＳＶ１ｂとの間でのアプリケーションデータ通信が終了すると、ＳＩＰプロキシＰＲａに対して、図５４に示す切断要求メッセージＭ２０ｘを送信する。切断要求メッセージＭ２０ｘは、スタートラインのＲｅｑｕｅｓｔ−ＵＲＩとＴｏヘッダが、サーバＳＶ１ｂをＩＰアドレス「sv1＠192.0.2.4」で指定している。ヘッダ部のその他のヘッダ情報は、図１７および図１８に示した第１実施例の接続要求メッセージＭ５と同一である。

ＳＩＰプロキシＰＲａは、上記切断要求メッセージＭ２０ｘを受信すると、要求元のクライアントＶＬ１ａに対して、切断中メッセージＭ２１ｘを送信した後、切断要求メッセージＭ２０ｘを図５５に示す切断要求メッセージＭ２２ｘに変換して、ＳＩＰプロキシＰＲｂに送信する。切断中メッセージＭ２１ｘは、ＩＰアドレス記述となっているＴｏヘッダを除いて、図３１に示した第１実施例の切断中メッセージＭ２１と同一の内容となっている。切断要求メッセージＭ２２ｘは、クライアントＣＬ１ａから受信した切断要求メッセージＭ２０ｘに、ＳＩＰプロキシＰＲａのＳＩＰ−ＵＲＩを含むＶｉａヘッダを追加し、ＳＩＰプロキシＰＲａと対応するＲｏｕｔｅヘッダを除去し、スタートラインのＲｅｑｕｅｓｔ−ＵＲＩをＩＰアドレスからＳＩＰ−ＵＲＩに書き換えた内容となっている。

ＳＩＰプロキシＰＲｂは、上記切断要求メッセージＭ２２を受信すると、ＳＩＰプロキシＰＲａに対して、切断中メッセージＭ２３ｘを送信した後、切断要求メッセージＭ２２ｘに新たなＶｉａヘッダを追加し、ＳＩＰプロキシＰＲｂと対応するＲｏｕｔｅヘッダを除去し、スタートラインのＲｅｑｕｅｓｔ−ＵＲＩをＳＩＰ−ＵＲＩからＩＰアドレスに書き換え、切断要求メッセージＭ２４ｘとしてサーバＳＶ１ｂに送信する。切断中メッセージＭ２３ｘと切断要求メッセージＭ２４ｘは、ＩＰアドレス記述となっているＴｏヘッダを除いて、図３３、図３４に示した第１実施例のＳＩＰメッセージと同一内容となっている。

サーバＳＶ１ｂは、切断要求メッセージＭ２４ｘを受信すると、ＳＩＰプロキシＰＲｂに切断応答メッセージＭ２５ｘを送信する。切断応答メッセージＭ２５ｘは、ＩＰアドレス記述となっているＴｏヘッダを除いて、図３５に示した第１実施例のＳＩＰメッセージと同一内容となっている。上記切断応答メッセージＭ２５ｘは、ＳＩＰプロキシＰＲｂとＳＩＰプロキシＰＲａで、第１実施例と同様の変換処理を受け、最終的に切断応答メッセージＭ２７ｘとして、要求元クライアントＣＬ１ａに送信される。要求元クライアントＣＬ１ａは、上記切断応答メッセージＭ２７ｘを受信すると、ＩＰｓｅｃ暗号化／復号化を終了し、同一または別のアプリケーションによる新たなパケット送信要求を待つ。

次に、図５６〜図５９を参照して、本発明の第２実施例の暗号化通信を可能にするクライアントＣＬ１ａと、ＳＩＰサーバＳＩＰａ（ＳＩＰプロキシＰＲａ、レジストラＲＧａ）の特徴的な動作について説明する。
第２実施例において、クライアントＣＬ１ａのＩＰｓｅｃエンジン３１ＣとＳＡ／ＳＰ制御部５１Ｃは、第１実施例と同様の機能をもつ。図５６は、第２実施例において、ＳＡ／ＳＰ制御部５１Ｃから接続要求メッセージのボディ部受信した時、クライアントＣＬ１ａのＳＩＰメッセージ処理部５３Ｃが実行する制御動作のフローチャート１１０ｘを示している。

ＳＩＰメッセージ処理部５３Ｃは、ＳＰ／ＳＡ制御部５１Ｃから接続要求メッセージのボディ部Ｍ５−２を受信すると、第２ＩＤペイロードのＩＤデータが示す接続先サーバのＩＰアドレスをスタートラインのＲｅｑｕｅｓｔ−ＵＲＩとＴｏヘッダに適用して、ヘッダ部Ｍ５ｘ−１と、ＳＰ／ＳＡ制御部５１Ｃから受信したボディ部Ｍ５−２とからなる図５１に例示した接続要求メッセージＭ５ｘを作成する（１１１ｘ）。

ＳＩＰメッセージ処理部５３Ｃは、上記接続要求メッセージをＴＳＬ部５２Ｃ、ＴＣＰ／ＩＰ部３０Ｃ、ＮＩＣ部２０Ｃを介して、ＳＩＰサーバＳＩＰａのＳＩＰプロキシＰＲａ宛に送信し（１１７）、ＳＩＰプロキシＰＲａからの応答を待ち（１１８）、ＳＩＰプロキシＰＲａから接続中メッセージＭ６を受信した場合は、接続中メッセージ処理（１１９）を実行した後、更にＳＩＰプロキシＰＲａからの応答を待つ。

ＳＩＰメッセージ処理部５３Ｃは、ＳＩＰプロキシＰＲａから接続応答メッセージＭ１２ｘを受信すると、受信メッセージを解析し（１２０）、受信メッセージから抽出した図２４に例示した接続応答メッセージボディ部Ｍ１２−２をＳＰ／ＳＡ制御部５１Ｃに渡す（１２１）。この後、ＳＩＰメッセージ処理部５３Ｃは、接続確認メッセージＭ１３ｘを作成し、該メッセージをＴＳＬ部５２Ｃ、ＴＣＰ／ＩＰ部３０Ｃ、ＮＩＣ部２０Ｃを介して、ＳＩＰプロキシＰＲａ宛に送信し（１２２）、このルーチンを終了する。

図５７は、クライアントＣＬ１ａから接続要求メッセージＭ５ｘを受信した時、ＳＩＰプロキシＰＲａのＳＩＰメッセージ処理部５３Ｐが実行する制御動作のフローチャート３００ｘの特徴部分を示す。
ＳＩＰプロキシＰＲａのＳＩＰメッセージ処理部５３Ｐは、クライアントＣＬ１ａからの接続要求メッセージＭ５ｘを受信すると、受信メッセージを解析し（ステップ３０１）、受信メッセージのスタートラインに記述されたＲｅｑｕｅｓｔ−ＵＲＩをチェックし（３０２）、Ｒｅｑｕｅｓｔ−ＵＲＩがドメイン名を含むか否かを判定する（３３０）。
Ｒｅｑｕｅｓｔ−ＵＲＩがドメイン名を含む場合、すなわち、「sips:ユーザ名＠ドメイン名」形式の記述となっていた場合は、ステップ３０３で、Ｒｅｑｕｅｓｔ−ＵＲＩのドメイン名から接続要求メッセージの転送先を判定する。

Ｒｅｑｕｅｓｔ−ＵＲＩがドメイン名を含まない、すなわち、「sips:ＩＰアドレス」形式の記述となっていた場合は、上記Ｒｅｑｕｅｓｔ−ＵＲＩが示す接続先サーバＳＶ１ｂのＩＰアドレスを検索キーとして、ロケーションデータ検索クエリを作成し（３３１）、該検索クエリをロケーションサーバＬＳＶに送信して（３３２）、ロケーションサーバからの応答を待つ（３３３）。ＳＩＰメッセージ処理部５３Ｒは、ロケーションサーバＬＳＶから、ロケーションデータとして接続先サーバＳＶ１ｂのＳＩＰ−ＵＲＩを受信すると、該ＳＩＰ−ＵＲＩを適用して、クライアントＣＬ１ａから受信した接続要求メッセージＭ５ｘのＲｅｑｕｅｓｔ−ＵＲＩをＩＰアドレスからＳＩＰ−ＵＲＩに書き換え、自分のＳＩＰ−ＵＲＩを含むＶｉａヘッダとＲｅｃｏｒｄ−Ｒｏｕｔｅを追加して（３３４）、ステップ３０３で、Ｒｅｑｕｅｓｔ−ＵＲＩのドメイン名から接続要求メッセージの転送先を判定する。ステップ３０３以降の動作は、図４１（図４１Ａ〜図４１Ｄ）で説明した第１実施例と同様である。

図５８は、クライアントＣＬ１ａにおいて、ＳＡ／ＳＰ制御部５１Ｃから切断要求メッセージの発行要求を受信した時にＳＩＰメッセージ処理部５３Ｃが実行する制御動作のフローチャート１４０ｘを示す。
ＳＩＰメッセージ処理部５３Ｃは、ＳＡ／ＳＰ制御部５１Ｃから切断要求メッセージの発行要求を受信すると、スタートラインのＲｅｑｕｅｓｔ−ＵＲＩとＴｏヘッダに現在通信中のサーバＳＶ１ｂのＩＰアドレス「sv1＠192.0.2.4」を適用して、図５４に例示した切断要求メッセージＭ２０ｘを作成し（ステップ１４１ｘ）、ＴＬＳ部５２Ｃ、ＴＣＰ／ＩＰ部３０ＣのＩＰｓｅｃエンジン３１Ｃ、ＮＩＣ部２０Ｃを介して、ＳＩＰサーバＳＩＰａ（ＳＩＰプロキシＰＲａ）に送信する（１４２）。

ＳＩＰメッセージ処理部５３Ｃは、ＳＩＰプロキシＰＲａからの応答を待ち（１４３）、切断中メッセージＭ２１ｘを受信した場合は、切断中メッセージ処理（１４４）を実行した後、ＳＩＰプロキシＰＲａからの次の応答を待つ。ＳＩＰメッセージ処理部５３Ｃは、ＳＩＰプロキシＰＲａから切断応答メッセージＭ２７ｘを受信すると、受信メッセージを解析し（１４５）、ＳＰ／ＳＡ制御部５１Ｃに対して、切断応答メッセージの受信を通知し（１４６）、このルーチンを終了する。

図５９は、クライアントから切断要求メッセージＭ２０ｘを受信した時にＳＩＰプロキシＰＲａのＳＩＰメッセージ処理部５３Ｐが実行する制御動作のフローチャート３４０ｘを示す。
ＳＩＰメッセージ処理部５３Ｐは、受信した切断要求メッセージＭ２０ｘを解析し（ステップ３４１）、受信メッセージのＲｅｑｕｅｓｔ−ＵＲＩをチェックして（３４２）、Ｒｅｑｕｅｓｔ−ＵＲＩがドメイン名を含むか否かを判定する（３６０）。Ｒｅｑｕｅｓｔ−ＵＲＩがドメイン名を含む場合は、ドメイン名から、受信メッセージの転送先を判定する（３４３）。Ｒｅｑｕｅｓｔ−ＵＲＩがドメイン名を含まない、すなわち、「sips:ＩＰアドレス」形式の記述となっていた場合は、接続要求メッセージの受信時に図５７のステップ３３１〜３３３で取得しておいた接続先サーバのＳＩＰ−ＵＲＩを適用して、上記切断要求メッセージＭ２０ｘのＲｅｑｕｅｓｔ−ＵＲＩを書き換え（３６１）、該Ｒｅｑｕｅｓｔ−ＵＲＩが示すドメイン名から、受信メッセージの転送先を判定する（３４３）。ステップ３４３以降の動作は、図４６（図４６Ａ〜図４１Ｃ）で説明した第１実施例と同様である。

以上の如く、第２実施例のＳＩＰプロキシＰＲａは、ＳＩＰメッセージ処理部５３Ｐが、図９に示したように、受信ＳＩＰメッセージのＲｅｑｕｅｓｔ−ＵＲＩが示すＩＰアドレスをＳＩＰ−ＵＲＩに変換するためのＳＩＰ−ＵＲＩ（ＡＯＲ）検索機能５４を備えたことを特徴としている。

次に、図６０〜図６７を参照して、本発明による暗号化データ通信の第３の実施例について説明する。
第３実施例は、接続先サーバをＩＰアドレスで指定した形でパケット送信要求が発生した時、クライアントＣｌ１ａのＳＩＰメッセージ処理部５３Ｃが、上記ＩＰアドレスを使用して接続先サーバにＳＩＰ−ＵＲＩを問い合わせ、接続先サーバから取得したＳＩＰ−ＵＲＩをＲｅｑｕｅｓｔ−ＵＲＩに記述することによって、ＳＩＰプロキシ側で受信メッセージから接続先ドメインを判定可能な形の接続要求メッセージを発行するようにしたことを特徴としている。

図６０は、第３実施例のクライアントＣＬ１ａが備える基本的なソフトウェア構造を示し、図６１は、接続先サーバＳＶ１ｂが備える基本的なソフトウェア構造を示している。
図７、図８と比較すると、クライアントＣＬ１ａのＳＩＰメッセージ処理部５３Ｃと、サーバＳＶ１ｂのＳＩＰメッセージ処理部５３Ｓとが、それぞれＳＩＰ−ＵＲＩ要求／応答メッセージを交信するためのＡＯＲ解決機能５５Ｃ、５５Ｓを備え、サーバＳＶ１ｂのＳＩＰメッセージ処理部５３Ｓが、ＡＯＲ解決機能５５Ｓが参照するロケーションテーブル７０を備えた点が相違している。上記ロケーションテーブル７０は、図６２に示すように、サーバＳＶ１ｂのＡＯＲ（ＳＩＰ−ＵＲＩ）７１と、ＩＰアドレス７２との対応関係を示している。

図６３は、第３実施例の暗号化データ通信のシーケンス図を示す。
ここでは、クライアントＣＬ１ａからの接続要求の発行に先立って、クライアントＣＬ１ａの所属ドメインを管理するＳＩＰプロキシＰＲａと、接続先サーバＳＶ１ｂの所属ドメインを管理するＳＩＰプロキシＰＲｂとの間で、相互の認証と暗号化通信のパラメータ設定のためのＴＬＳネゴシェーション（ステップＳ０）が実行済みで、接続先サーバＳＶ１ｂとレジストラＲＧｂとの間で、ＴＬＳネゴシェーション（Ｓ１）とロケーションの登録手順が実行済みとなっているものとする。但し、ＳＩＰプロキシ間のＴＬＳネゴシェーション（Ｓ０）は、第１、第２実施例のステップＳ８で示したように、クライアントＣＬ１ａからの接続要求が発生した時点で、必要に応じて実行するようにしても構わない。

本実施例では、クライアントＣＬ１ａにおいて、サーバＳＶ１ｂをＩＰアドレスで指定した接続発生した時、ＳＩＰメッセージ処理部５３Ｃが、サーバＳＶ１ｂ宛にダイレクトに、ＡＯＲ解決要求メッセージＭ３０を送信し、サーバＳＶ１ｂのＳＩＰメッセージ処理部５３Ｓが、上記ＡＯＲ解決要求メッセージＭ３０の受信に応答して、サーバＳＶ１ｂのＳＩＰ−ＵＲＩ［sv1＠bbb.com］を示すＡＯＲ解決応答メッセージＭ４０を返送する。

ＡＯＲ解決要求メッセージＭ３０は、例えば、図６４に示すように、スタートラインに、メッセージ種類として「GETAOR」、Ｒｅｑｕｅｓｔ−ＵＲＩとして、サーバＳＶ１ｂのＩＰアドレス「1922.0.2.4」が記述されている。また、スタートラインに続くヘッダ情報として、クライアントＣＬ１ａ（ＳＩＰメッセージ処理部５３Ｃ）の識別情報を含むＶｉａヘッダ、サーバＳＶ１ｂのＩＰアドレスを含むＴｏヘッダ、クライアントＣＬ１ａ（ＳＩＰメッセージ処理部５３Ｃ）のＳＩＰ−ＵＲＩを含むＦｒｏｍヘッダと、Ｃａｌｌ−ＩＤヘッダ、ＣＳｅｑヘッダ、Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈヘッダを含む。ＡＯＲ解決要求メッセージＭ３０にはボディ部がなく、Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈは０となっている。

ＡＯＲ解決応答メッセージＭ４０は、図６５に示すように、スタートラインに、応答メッセージを示すメッセージ種類「200 OK」を含む。また、ヘッダ情報として、ＡＯＲ解決要求メッセージＭ３０と同一内容のＶｉａヘッダ、Ｔｏヘッダ、Ｆｒｏｍヘッダ、ＣＳｅｑを含み、ＡＯＲヘッダによって、目的ＡＯＲであるサーバＳＶ１ｂのＳＩＰ−ＵＲＩの値「sv1＠bbb.com」が示されている。

クライアントＣＬ１ａのＳＩＰメッセージ処理部５３Ｃは、上記ＡＯＲ解決応答メッセージＭ４０を受信すると、Ｒｅｑｕｅｓｔ−ＵＲＩにサーバＳＶ１ｂのＳＩＰ−ＵＲＩを適用した接続要求メッセージＭ５を作成し、ＴＬＳ部５２Ｃ、ＩＰｓｅｃエンジン３０Ｃ、ＮＩＣ部２０Ｃを介して、ＳＩＰプロキシＰＲａに送出する。このとき、ＴＬＳ部５２Ｃは、ＳＩＰプロキシＰＲａとの間でＴＬＳネゴシェーション（Ｓ７）を実行した後、接続要求メッセージＭ５を暗号化して、ＳＩＰプロキシＰＲａに送信する。

ＳＩＰプロキシＰＲａは、接続要求メッセージＭ５を受信すると、第１実施例と同様、要求元クライアントＣＬ１ａに接続中メッセージＭ６を送信した後、ＳＩＰプロキシＰＲｂ宛に、接続要求メッセージＭ７を送信する。以降の手順は、図１２で説明した第１実施例と同様である。

図６６は、第３実施例のクライアントＣＬ１ａにおいて、ＳＰ／ＳＡ制御部５１Ｃから接続要求メッセージのボディ部を受信した時、ＳＩＰメッセージ処理部５３Ｃが実行する制御動作のフローチャート１１０ｙを示す。
ＳＩＰメッセージ処理部５３Ｃは、ＳＰ／ＳＡ制御部５１Ｃから接続要求メッセージのボディ部を受信すると、第２ＩＤペイロードのＩＤデータが示す接続先サーバＶ１ｂのＩＰアドレスと、ＳＩＰメッセージ処理部５３Ｃが管理している通信制御パラメータとから、図６４に例示したＡＯＲ取得要求メッセージＭ３０を作成し（ステップ１１１ｙ）、該メッセージをＴＣＰ／ＩＰ部３０Ｃ、ＮＩＣ部２０Ｃを介して、サーバＳＶ１ｂに送信する（１１２ｙ）。この場合、ＡＯＲ取得要求メッセージＭ３０は、ＴＬＳ部５２Ｃを経由しないため、サーバＳＶ１ｂとの間でのＴＬＳネゴシェーションは実行されず、ＡＯＲ取得メッセージＭ３０は暗号化されない平文メッセージとして宛先サーバＳＶ１ｂに送信さされる。

ＳＩＰメッセージ処理部５３Ｃは、サーバＳＶ１ｂからのＡＯＲ取得応答メッセージを待っており（１１３ｙ）、ＡＯＲ取得応答メッセージＭ４０を受信すると、受信メッセージを解析し（１１４）、ＡＯＲヘッダから接続先サーバに割り当てられたＳＩＰ−ＵＲＩを抽出する（１１５）。この後、ＳＩＰメッセージ処理部５３Ｃは、上記ＳＩＰ−ＵＲＩをスタートラインとＴｏヘッダに適用して、ヘッダ部Ｍ５−１と、ＳＰ／ＳＡ制御部５１Ｃから受信したボディ部Ｍ５−２とからなる図１７に例示した接続要求メッセージＭ５を作成する（１１６）。以降の処理手順は、図３９で説明した第１実施例と同様である。

図６７は、クライアントからＡＯＲ取得要求メッセージＭ３０を受信した時、サーバＳＶ１ｂのＳＩＰメッセージ処理部５３Ｓが実行する制御動作のフローチャート４５０を示す。
サーバＳＶ１ｂのＳＩＰメッセージ処理部５３Ｓは、ＡＯＲ取得要求メッセージＭ３０を受信すると、受信メッセージを解析し（ステップ４５１）、ロケーションテーブル７０から、受信メッセージのＴｏヘッダが示すＩＰアドレスと対応するＡＯＲ値（ＳＩＰ−ＵＲＩ）を取得する（４５２）。ＳＩＰメッセージ処理部５３Ｓは、取得したＡＯＲ値をＡＯＲヘッダに設定して、ＡＯＲ取得応答メッセージＭ４０を作成し（４５３）、これをＡＯＲ取得要求メッセージＭ３０の送信元であるクライアントに送信し（４５４）、このルーチンを終了する。

以上の実施例では、暗号化データ通信が終了した時、クライアントＣＬ１ａ側から切断要求を発行した場合の通信シーケンスについて説明したが、サーバＳＶ１ｂが所属するＳＩＰプロキシＰＲｂも、クライアント側のＳＩＰプロキシＰＲａと同様の機能を備えているため、サーバＳＶ１ｂから切断要求が発行された場合でも、メッセージの送信方向が逆になるだけで、結果的には実施例と同様の手順が実行されることになる。

また、実施例では、第１ドメインに所属するクライアントＣＬ１ａから、第２ドメインに所属するサーバＳＶ１ｂに接続要求を発行した場合の通信シーケンスについて説明したが、第１実施例において、クライアントＣＬ１ａが、サーバＳＶ１ｂとの通信を終了した後、別のサーバ、例えば、サーバＳＶ２ｂ（またはサーバＳＶ１ａ）と通信するアプリケーションを起動した場合、クライアントＣＬ１ａとレジストラＲＧａとの間、およびクライアントＣＬ１ａとＳＩＰプロキシＰＲａとの間では、既に暗号化通信のための条件設定が完了した状態にある。従って、アプリケーションプログラムからデータの送信要求が発生した時、ＴＬＳ部５２Ｃは、ＳＩＰサーバＳＩＰａとの間でのＴＬＳネゴシェーションを省略して、ＳＩＰメッセージ処理部５３Ｃから受信したＡＯＲ取得要求メッセージ、または接続要求メッセージを直ちに暗号化して、ネットワークＮＷ１に送信することが可能となる。

尚、実施例では、ＳＩＰメッセージのＲｅｑｕｅｓｔ−ＵＲＩやＴｏヘッダにＩＰアドレスを適用する時、例えば、図１５や図５１の「sips：192.0.2.4」のように記述した。この場合、ＳＩＰメッセージを受信したＳＩＰプロキシ、レジストラまたはサーバ側では、着目フィールドにおける「sips：」に続く文字列が、３桁以下の数字をドットで区切ったＩＰアドレス表記となっているか否かによって、ＳＩＰ−ＵＲＩ記述かＩＰアドレス記述かを判定できる。ＳＩＰ−ＵＲＩ記述かＩＰアドレス記述かを判定を確実にするためは、例えば、「sips：192.0.2.4；id=ipv4」のように、ＵＲＩパラメータを使用して、ＡＯＲ解決を必要とするＳＩＰ−ＵＲＩであることを明示するようにしてもよい。また、例えば、「ipv4：192.0.2.4」のように、着目フィールドでＩＰｖ４（またはＩＰｖ６）というスキームを検出した場合は、その後にＩＰアドレスが記述されているものと約束してもよい。

公開鍵暗号化通信における従来の認証システムを説明するため図。 ＩＰｓｅｃによる暗号化通信を行うために従来のクライアントが備えるソフトウェアの基本的なブロック構成を示す図。 本発明と関係するＳＩＰプロキシを適用した認証システムを説明するための図。 本発明のセッション管理サーバ（ＳＩＰサーバ）を含むネットワーク構成の１例を示す図。 図４に示したロケーションサーバＬＳＶが備えるロケーションサービステーブルの１例を示す図。 図４に示したＳＩＰプロキシＰＲａのハードウェア構成を示すブロック図。 図４に示したクライアントＣＬ１ａの基本的なソフトウェア構造を示す図。 図４に示したサーバＳＶ１ｂの基本的なソフトウェア構造を示す図。 図４に示したＳＩＰプロキシＰＲａの基本的なソフトウェア構造を示す図。 図４に示したレジストラＲＧａの基本的なソフトウェア構造を示す図。 本発明による暗号化通信の第１の実施例を説明するためのシーケンス図の一部。 本発明による暗号化通信の第１の実施例を説明するためのシーケンス図の残部。 図１１におけるロケーション登録要求メッセージＭ１のフォーマットの１例を示す図。 図１１におけるロケーション登録応答メッセージＭ２のフォーマットの１例を示す図。 図１１におけるロケーションＡＯＲ取得要求メッセージＭ３のフォーマットの１例を示す図。 図１１におけるロケーションＡＯＲ取得応答メッセージＭ４のフォーマットの１例を示す図。 図１１における接続要求メッセージＭ５のフォーマットの１例を示す図。 接続要求メッセージＭ５のボディ部Ｍ５−２のフォーマットの１例を示す図。 図１１における接続中メッセージＭ６のフォーマットの１例を示す図。 図１１における接続要求メッセージＭ７のフォーマットの１例を示す図。 図１２における接続中メッセージＭ８のフォーマットの１例を示す図。 図１２における接続要求メッセージＭ９のフォーマットの１例を示す図。 図１２における接続応答メッセージＭ１０のフォーマットの１例を示す図。 接続応答メッセージＭ１０のボディ部Ｍ１０−２のフォーマットの１例を示す図。 図１２における接続応答メッセージＭ１１のフォーマットの１例を示す図。 図１２における接続応答メッセージＭ１２のフォーマットの１例を示す図。 図１２における接続確認メッセージＭ１３のフォーマットの１例を示す図。 図１２における接続確認メッセージＭ１４のフォーマットの１例を示す図。 図１２における接続確認メッセージＭ１５のフォーマットの１例を示す図。 図１２における切断要求メッセージＭ２０のフォーマットの１例を示す図。 図１２における切断中メッセージＭ２１のフォーマットの１例を示す図。 図１２における切断要求メッセージＭ２２のフォーマットの１例を示す図。 図１２における切断中メッセージＭ２３のフォーマットの１例を示す図。 図１２における切断要求メッセージＭ２４のフォーマットの１例を示す図。 図１２における切断応答メッセージＭ２５のフォーマットの１例を示す図。 図１２における切断応答メッセージＭ２６のフォーマットの１例を示す図。 図１２における切断応答メッセージＭ２７のフォーマットの１例を示す図。 鍵交換要求を受信した時、クライアントＣＬ１ａのＳＰ／ＳＡ制御部５１Ｃが実行する制御動作を示すフローチャート。 接続要求メッセージのボディ部を受信した時、クライアントＣＬ１ａのＳＩＰメッセージ処理部５３Ｃが実行する制御動作を示すフローチャートの一部。 接続要求メッセージのボディ部を受信した時、クライアントＣＬ１ａのＳＩＰメッセージ処理部５３Ｃが実行する制御動作を示すフローチャートの残部。 ＡＯＲ取得要求メッセージを受信した時、レジストラＲＧａのＳＩＰメッセージ処理部５３Ｒが実行する制御動作を示すフローチャート。 接続要求メッセージを受信した時、ＳＩＰプロキシＰＲａのＳＩＰメッセージ処理部５３Ｐが実行する制御動作を示すフローチャートの第１部分。 接続要求メッセージを受信した時、ＳＩＰプロキシＰＲａのＳＩＰメッセージ処理部５３Ｐが実行する制御動作を示すフローチャートの第２部分。 接続要求メッセージを受信した時、ＳＩＰプロキシＰＲａのＳＩＰメッセージ処理部５３Ｐが実行する制御動作を示すフローチャートの第３部分。 接続要求メッセージを受信した時、ＳＩＰプロキシＰＲａのＳＩＰメッセージ処理部５３Ｐが実行する制御動作を示すフローチャートの第４部分。 接続要求メッセージを受信した時、サーバＳＶ１ｂのＳＩＰメッセージ処理部５３Ｓが実行する制御動作を示すフローチャート。 接続要求メッセージのボディ部を受信した時、サーバＳＶ１ｂのＳＰ／ＳＡ制御部５１Ｓが実行する制御動作を示すフローチャート。 鍵消去要求を受信した時、クライアントＣＬ１ａのＳＰ／ＳＡ制御部５１Ｃが実行する制御動作を示すフローチャート。 切断要求メッセージの発行要求を受信した時、クライアントＣＬ１ａのＳＩＰメッセージ処理部５３Ｃが実行する制御動作を示すフローチャート。 切断要求メッセージを受信した時、ＳＩＰプロキシＰＲａのＳＩＰメッセージ処理部５３Ｐが実行する制御動作を示すフローチャートの一部。 切断要求メッセージを受信した時、ＳＩＰプロキシＰＲａのＳＩＰメッセージ処理部５３Ｐが実行する制御動作を示すフローチャートの残部。 切断要求メッセージを受信した時、サーバＳＶ１ｂのＳＩＰメッセージ処理部５３Ｓが実行する制御動作を示すフローチャート。 切断要求の発生通知を受信した時、サーバＳＶ１ｂのＳＰ／ＳＡ制御部５１Ｓが実行する制御動作を示すフローチャート。 本発明による暗号化通信の第２の実施例を説明するためのシーケンス図の一部。 本発明による暗号化通信の第２の実施例を説明するためのシーケンス図の残部。 図４９における接続要求メッセージＭ５ｘのフォーマットの１例を示す図。 図４９における接続中メッセージＭ６ｘのフォーマットの１例を示す図。 図４９における接続要求メッセージＭ７ｘのフォーマットの１例を示す図。 図５０における切断要求メッセージＭ２０ｘのフォーマットの１例を示す図。 図５０における切断要求メッセージＭ２２ｘのフォーマットの１例を示す図。 接続要求メッセージのボディ部を受信した時、第２実施例のクライアントＣＬ１ａのＳＩＰメッセージ処理部５３Ｃが実行する制御動作を示すフローチャートの一部。 接続要求メッセージを受信した時、第２実施例のＳＩＰプロキシＰＲａのＳＩＰメッセージ処理部５３Ｐが実行する制御動作を示すフローチャートの一部。 切断要求メッセージの発行要求を受信した時、第２実施例のクライアントＣＬ１ａのＳＩＰメッセージ処理部５３Ｃが実行する制御動作を示すフローチャート。 切断要求メッセージを受信した時、第２実施例のＳＩＰプロキシＰＲａのＳＩＰメッセージ処理部５３Ｐが実行する制御動作を示すフローチャートの一部。 本発明の第３実施例のクライアントＣＬ１ａが備える基本的なソフトウェア構造を示す図。 本発明の第３実施例のサーバＳＶ１ｂが備える基本的なソフトウェア構造を示す図。 サーバＳＶ１ｂが備えるロケーションテーブルの内容を示す図。 本発明による暗号化通信の第３の実施例を説明するためのシーケンス図の一部。 図６３におけるＡＯＲ取得要求メッセージＭ３０のフォーマットの１例を示す図。 図６３におけるＡＯＲ取得応答メッセージＭ４０のフォーマットの１例を示す図。 接続要求メッセージのボディ部を受信した時、第３実施例のクライアントＣＬ１ａのＳＩＰメッセージ処理部５３Ｃが実行する制御動作を示すフローチャートの一部。 ＡＯＲ取得要求メッセージを受信した時、第３実施例のサーバＳＶ１ｂのＳＩＰメッセージ処理部５３Ｓが実行する制御動作を示すフローチャート

符号の説明

ＣＬ１ａ〜ＣＬ２ｂ：クライアント、ＳＶ１ａ〜ＳＶ２ｂ：サーバ、
ＳＩＰａ、ＳＩＰｂ：ＳＩＰサーバ、ＰＲａ、ＰＲｂ：ＳＩＰプロキシ、
ＲＧａ、ＲＧｂ：レジストラ、ＬＳＶ：ロケーションサーバ、
２０：ネットワークインタフェースカード部、３０：ＴＣＰ／ＩＰレイヤ部、
３１：ＩＰｓｅｃエンジン、４０：アプリケーションソフト、５０：鍵管理プロセス、
５１：ＳＰ／ＳＡ制御部、５２：ＴＬＳ部、５３：ＳＩＰメッセージ処理部、
６０：レジストラ処理部。

Claims (6)

1. セッション管理プロトコルに従って、第１端末と第２端末との間にセッションを確立するセッション管理装置上で実行されるプログラムであって、
   上記第１端末から、上記第２端末をＩＰアドレスで指定して、上記セッション管理プロトコルで必要とする上記第２端末の識別情報の問合せメッセージを受信した時、該受信メッセージが示す上記ＩＰアドレスを用いて、上記第２端末の識別情報を取得する機能と、
   取得した上記第２端末の識別情報を上記第１端末に通知する機能とを上記セッション管理装置に実行させることを特徴とするプログラム。
2. セッション管理プロトコルに従って、第１端末と第２端末との間にセッションを確立するセッション管理装置上で実行されるプログラムであって、
   上記第１端末から、上記第２端末との間のセッションの確立要求メッセージを受信した時、該受信メッセージ内で上記第２端末がＩＰアドレスで指定されているか否かを確認する機能と、
   上記第２端末がＩＰアドレスで指定されていた場合、該ＩＰアドレスを用いて、上記セッション管理プロトコルで必要とする上記第２端末の識別情報を取得する機能と、
   上記識別情報で上記第２端末を指定して、上記第２端末との間のセッション確立のための要求メッセージを作成する機能とを上記セッション管理装置に実行させることを特徴とするプログラム。
3. 前記第２端末の識別情報の取得機能が、端末ＩＰアドレスと前記セッション管理プロトコルで必要とする端末識別情報との対応関係を保持した別の装置に対して、前記第２端末のＩＰアドレスと対応する識別情報を問い合わせることを特徴とする請求項１または請求項２に記載のプログラム。
4. セッション管理プロトコルに従って、セッション管理装置を介して第２端末との間にセッションを確立する場合に第１端末上で実行されるプログラムであって、
   上記第２端末上で実行されるアプリケーションプログラムと通信する該第１端末上のアプリケーションプログラムから、上記第２端末をＩＰアドレスで指定して、上記第２端末との通信要求を受付けた時、上記第２端末を上記ＩＰアドレスで指定して、上記セッション管理プロトコルで必要とする上記第２端末の識別情報の問合せメッセージを作成する機能と、
   ネットワークから上記問合せメッセージに対する応答メッセージを受信した時、該応答メッセージが示す識別情報によって上記第２端末を指定して、上記セッション管理装置に上記第２端末との間のセッションの確立を要求するメッセージを作成する機能とを上記第１端末に実行させることを特徴とするプログラム。
5. 前記問合せメッセージの作成機能は、該メッセージの宛先を前記セッション管理装置とすることを特徴とする請求項４に記載のプログラム。
6. 前記セッション管理プロトコルがＳＩＰ（Session Initiation Protocol）であり、前記識別情報がＳＩＰ−ＵＲＩ（Uniform Resource Identifier）であることを特徴とする請求項１、２、または請求項４に記載のプログラム。

Images