クライアントの地理的位置を使用して保護スイートを決定するネットワークで実施される方法
【課題】クライアントの地理的位置を使用して保護スイートを決定するネットワークで実施される方法を提供すること。
【解決手段】サーバが、複数の代替保護スイートから選択された保護スイートを使用してクライアント装置と通信するように構成される。サーバは、端末装置から、当該端末装置でサポートされる保護スイートの提案リストを識別する情報を受信する。サーバと端末装置の両方にサポートされる保護スイートの中の特定の１つが、決定的な方式でサーバによって選択される。特定の保護スイートの使用が、端末装置が位置する地理的地域の法で禁止される場合、サーバは、本来であれば選択される保護スイートの代わりに、別の一致する保護スイートを選択する。サーバは、選択された保護スイートを端末装置に対して特定し、その後、その保護スイート中のパラメータ値に基づいて端末装置と通信する。
【解決手段】サーバが、複数の代替保護スイートから選択された保護スイートを使用してクライアント装置と通信するように構成される。サーバは、端末装置から、当該端末装置でサポートされる保護スイートの提案リストを識別する情報を受信する。サーバと端末装置の両方にサポートされる保護スイートの中の特定の１つが、決定的な方式でサーバによって選択される。特定の保護スイートの使用が、端末装置が位置する地理的地域の法で禁止される場合、サーバは、本来であれば選択される保護スイートの代わりに、別の一致する保護スイートを選択する。サーバは、選択された保護スイートを端末装置に対して特定し、その後、その保護スイート中のパラメータ値に基づいて端末装置と通信する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、仮想私設網などの通信ネットワークに関する。
【背景技術】
【０００２】
仮想私設網のユーザにとって重要な問題の１つは、特にデータがインターネットなどの公衆網を横断する場合のデータのセキュリティである。暗号化は、データを保護する方法の１つである。ＩＰＳｅｃ（ＩＰ Ｓｅｃｕｒｉｔｙの略）は、インターネットの主要標準組織であるＩｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅによって開発されたプロトコルの集合であり、公衆網上でのＴＣＰ／ＩＰスタックのＩＰ層におけるパケットのセキュアな交換を支援する。これらのプロトコルについては、少なくとも以下の文書に記載され、これらの文書は、参照により本明細書に全体が記載されるものとして含められる。ｗｗｗ．ｉｅｔｆ．ｏｒｇ、ｈｔｔｐ：／／ｗｗｗ．ｒｆｃ−ｅｄｉｔｏｒ．ｏｒｇ／、ＲＦＣ ２４０６ ｆｔｐ：／／ｆｔｐ．ｒｆｃ−ｅｄｉｔｏｒ．ｏｒｇ／ｉｎ−ｎｏｔｅｓ／ｒｆｃ２４０６、ＲＦＣ ２４０７ ｆｔｐ：／／ｆｔｐ．ｒｆｃ−ｅｄｉｔｏｒ．ｏｒｇ／ｉｎ−ｎｏｔｅｓ／ｒｆｃ２４０７、ＲＦＣ ２４０８ ｆｔｐ：／／ｆｔｐ．ｒｆｃ−ｅｄｉｔｏｒ．ｏｒｇ／ｉｎ−ｎｏｔｅｓ／ｒｆｃ２４０８．ｔｘｔ、ＲＦＣ ２４０９ ｆｔｐ：／／ｆｔｐ．ｒｆｃ−ｅｄｉｔｏｒ．ｏｒｇ／ｉｎ−ｎｏｔｅｓ／ｒｆｃ２４０９．ｔｘｔ、ＲＦＣ ４３０６ ｆｔｐ：／／ｆｔｐ．ｒｆｃ−ｅｄｉｔｏｒ．ｏｒｇ／ｉｎ−ｎｏｔｅｓ／ｒｆｃ４３０６。
【０００３】
ＩＰＳｅｃは、特に、仮想私設網を実装する際にセキュアなサービスを提供するために広く展開されている。ＩＰＳｅｃの仮想私設網は、サイト間の仮想私設網とリモート・アクセス用の仮想私設網の２つのカテゴリに分類することができる。リモート・アクセス用の仮想私設網のユーザは、業務の継続性のためにその接続を使用する。そうしたユーザには、各自の地理的位置に関係なく非常に重要なデータに安全にアクセスするためにこの種の接続に依拠する在宅勤務者や商用旅行者が含まれる。
【０００４】
ＩＰＳｅｃでは、ＤＥＳ、３ＤＥＳ、およびＡＥＳを含む数個の対称暗号化アルゴリズムが可能である。これらのアルゴリズムの違いは、ブロックおよび鍵のサイズである。ＤＥＳと３ＤＥＳのブロック・サイズは６４ビットで、これは、当該暗号化アルゴリズムの１回の実行で６４ビット（８バイト）を暗号化できることを意味する。一方、ＡＥＳのブロック・サイズは１２８ビットである。ＤＥＳは、その基本形で５６ビットの鍵を使用し、３ＤＥＳは、１６８ビットの鍵サイズ（３つの独立した５６ビットの鍵）であり、ＡＥＳは、少なくとも１２８ビットの鍵をサポートする。鍵長が長いほど、使用できる可能な鍵の数が多くなり、したがって暗号化が強くなり、これは総当たり攻撃で符号化を解読することがより難しくなることを意味する。
【非特許文献１】ｗｗｗ．ｉｅｔｆ．ｏｒｇ
【非特許文献２】ｈｔｔｐ：／／ｗｗｗ．ｒｆｃ−ｅｄｉｔｏｒ．ｏｒｇ／
【非特許文献３】ＲＦＣ ２４０６ ｆｔｐ：／／ｆｔｐ．ｒｆｃ−ｅｄｉｔｏｒ．ｏｒｇ／ｉｎ−ｎｏｔｅｓ／ｒｆｃ２４０６
【非特許文献４】ＲＦＣ ２４０７ ｆｔｐ：／／ｆｔｐ．ｒｆｃ−ｅｄｉｔｏｒ．ｏｒｇ／ｉｎ−ｎｏｔｅｓ／ｒｆｃ２４０７
【非特許文献５】ＲＦＣ ２４０８ ｆｔｐ：／／ｆｔｐ．ｒｆｃ−ｅｄｉｔｏｒ．ｏｒｇ／ｉｎ−ｎｏｔｅｓ／ｒｆｃ２４０８．ｔｘｔ
【非特許文献６】ＲＦＣ ２４０９ ｆｔｐ：／／ｆｔｐ．ｒｆｃ−ｅｄｉｔｏｒ．ｏｒｇ／ｉｎ−ｎｏｔｅｓ／ｒｆｃ２４０９．ｔｘｔ
【非特許文献７】ＲＦＣ ４３０６ ｆｔｐ：／／ｆｔｐ．ｒｆｃ−ｅｄｉｔｏｒ．ｏｒｇ／ｉｎ−ｎｏｔｅｓ／ｒｆｃ４３０６
【特許文献１】米国特許第６，４７０，４４７号
【特許文献２】米国特許第５，７８１，６２８号
【発明の開示】
【発明が解決しようとする課題】
【０００５】
すべての国がすべての暗号化アルゴリズムの使用を許可している訳ではない。一部の国の法規制は、特に強力なアルゴリズムで通信が暗号化されたときに有効な監視（例えば盗聴）を行うことが難しくなるため、特定の暗号化アルゴリズムのみの使用を許可している。これは、旅行するユーザにとっては、滞在している国の外にあるＶＰＮゲートウェイに接続する際に問題が生じる。米国を本拠地とする旅行者ユーザは、普通、米国内にいる時には上記の３つのアルゴリズムの中で最も安全性の高いアルゴリズム、すなわちＡＥＳを使用することを望む。しかし、ユーザが、ＡＥＳが許可されていない国に旅行する際には、現地の法規制あるいは規定に準拠するために、ＡＥＳより低い暗号化強度に格下げする必要がある。
【０００６】
そのような格下げは、ＩＰＳｅｃ環境または他の通信プロトコルの状況では容易に実現することができる。ＩＰＳｅｃを例に使用すると、ＩＰＳｅｃでは、ユーザの端末装置、すなわちＩＰＳｅｃクライアントが、いわゆる「セキュリティの関連付けペイロード」でＩＰＳｅｃサーバ（ゲートウェイ）にＯｆｆｅｒ（オファー、申し入れ）を送信することにより、セキュリティ・パラメータ値のネゴシエーションを開始する。このため、クライアントは、時にこの意味合いで「イニシエータ（ｉｎｉｔｉａｔｏｒ）」と呼ばれる。このＯｆｆｅｒは、通信の少なくとも１つの態様、具体的には通信のセキュリティを制御する１つまたは複数のセキュリティ・パラメータの値を含む、いわゆる「保護スイート（ｐｒｏｔｅｃｔｉｏｎ ｓｕｉｔｅ）」のリストを含む。各保護スイートは、ａ）特定のＩＰＳｅｃプロトコル、ｂ）特定の暗号化アルゴリズム（「トランスフォーム」とも称される）、およびｃ）Ｄｉｆｆｉｅ−Ｈｅｌｌｍａｎグループ、ハッシュ・パラメータ等のその他の保護属性またはパラメータ、の識別を備える。特定のプロトコル、暗号化アルゴリズム、または他のパラメータの識別を、本発明ではそのパラメータの「値」と呼ぶ。
【０００７】
ＩＰＳｅｃサーバは、サーバでサポートされる保護スイートの独自のリストをサポートする。サーバにサポートされる保護スイートの一部は、クライアントでサポートされる保護スイートと異なる場合もあるが、通例は一致する保護スイートが少なくとも１つある。Ｏｆｆｅｒに応答して、サーバは、クライアントとサーバの両方にサポートされる保護スイートのうちどれをそのセッションに使用するかを決定的な方式で選択する。例えば、現在の慣行では、サーバでサポートされる保護スイートに優先順位があり、サーバは、特定の方法論を用いて、当該通信セッションで使用するのに好ましい保護スイートを特定する。通例、その方法論は、Ｏｆｆｅｒに含まれている保護スイートで、サーバの順位付けが最も高い保護スイートを好ましい保護スイートとして特定する。そして、サーバは、そのセッションに使用する特定の保護スイートを特定するＰｒｏｐｏｓａｌ（プロポーザル、提案、ＩＰＳｅｃ環境では「ＩＫＥ Ｐｒｏｐｏｓａｌ」と呼ばれる）をクライアントに返す。したがって、サーバは、時にこの意味合いで「レスポンダ（ｒｅｓｐｏｎｄｅｒ）」と呼ばれる。その後、暗号鍵のネゴシエーションを含むセキュリティ・ネゴシエーションが継続する。その後、選択された保護スイートのパラメータ値、ネゴシエーション鍵、およびその他の固定パラメータ値またはネゴシエートされたパラメータ値に基づいて通信が進行する。
【０００８】
したがって、通信を確実に現地の（ｌｏｃａｌ ｌａｗ）に準拠させることは、非常に簡単なことである。ユーザは、ユーザインターフェース画面のチェックボックスなどを介してクライアント装置の通信オプションを設定して、例えば、許可されていない暗号化アルゴリズムや可能性としては他の許可されていない保護パラメータ値など、現地の法に違反することになるパラメータ値が組み込まれた保護スイート（「ポリシー」と呼ばれる場合もある）をすべてクライアント内で使用不可にすることができる。したがって、Ｏｆｆｅｒは、使用しても現地の法に違反しない保護スイートだけを含み、最終的にサーバによって選択され、Ｐｒｏｐｏｓａｌに指定される保護スイートが現地の法に違反するものではないことを保証する。
【課題を解決するための手段】
【０００９】
上記の手法は単純で平易であるが、本発明者は、さらなる改良が可能であることを認識した。
本発明の例示的実施形態では、レスポンダの保護スイートの選択が、使用すると許可されない通信を行わせるもの、例えば、特定の暗号化アルゴリズムを使用することで現地の法に違反する通信を行わせるものを含んでいる場合に、第１のエンティティ、すなわちレスポンダ（上記の例のＩＰＳｅｃサーバなど）が、第２のエンティティすなわちイニシエータ（ＩＰＳｅｃクライアントなど）の地理的位置を使用して、本来であれば当該セッションのためのレスポンダによる保護スイートの選択となる選択を変更する。したがって、イニシエータにサポートされる保護スイートが、例えばＡＥＳ暗号化アルゴリズムを組み込んだ特定の保護スイートを含んでいる場合には、その保護スイートが本来であればレスポンダの最も好ましい保護スイートであっても、レスポンダは、イニシエータから提案される保護スイートのうち別の保護スイート、すなわち許可されない保護パラメータ値を含まない保護スイートをＰｒｏｐｏｓａｌで指定する。
【００１０】
より広くは、本発明は、保護スイートが、そのうちの一部が通信のセキュリティに関連する複数のパラメータを含む実装を包含する。本発明は、保護スイートが１つのみのセキュリティ・パラメータ、例えば１つの暗号化標準やＤｉｆｆｉｅ−Ｈｅｌｌｍａｎグループの１つのみを含む場合のある実装も包含する。また、本発明は、より広くは、通信の少なくとも１つの態様がセキュリティや保護に関連するかどうかに関係なく、当該パラメータが、通信の少なくとも１つの態様を制御する実装を包含する。
【００１１】
イニシエータは、可能性としては例えばＧＰＳを使用して自身の地理的位置を判定することができ、その位置をサーバに報告することができ、サーバは、選択される保護スイートを、現地の法に違反しない保護スイートに限定する責任を負う。しかし、本発明の特定の実施形態では、レスポンダが、例えばパケットなど、イニシエータからの通信に含まれる発信元アドレスに基づいて、イニシエータの位置を判定する。例えば、ＩＰアドレスと国との対応付けのデータは容易に入手することができるので、ＩＰ環境では、イニシエータの位置は、例えばイニシエータから受信されるパケットに含まれるレイヤ３のＩＰアドレスから判定することができる。
【００１２】
本発明にはいくつかの利点がある。本発明は、現地の法についての知識をネットワークに移し、ユーザが現地の法について知る必要をなくす。さらに、ネットワークがイニシエータのＩＰアドレスまたは他のアドレスに基づいてイニシエータの位置を判定する実施形態では、イニシエータは、自身の地理的位置を識別する、あるいはその位置をネットワークに通信するように構成される必要がない。したがって、イニシエータ装置またはそのプロトコル・ソフトウェアで変更が一切必要とされることなく、現地の法規定に準拠した保護スイートの使用が実現される。
【００１３】
従来技術は、端末装置による特定の暗号化アルゴリズムの使用が、当該端末装置の位置に基づいて自動的に制御される構成を十分に認識している。例えば、２００２年１０月２２日にＬａｍｂｅｒｔ他に発行された米国特許第６，４７０，４４７号、１９９８年７月１４日にＡｌｐｅｒｏｖｉｃｈ他に発行された米国特許第５，７８１，６２８号を参照されたい。これらの特許は、無線通信（例えばセルラー電話）のコンテクストにおけるこの概念を開示する。しかし、その後も、本願の出願人は、例えば、クライアントの地理的位置を使用して、プロトコル・スイートの突き合わせが実施される方式を変更することが望ましいことを認識した。
【発明を実施するための最良の形態】
【００１４】
図１は、本発明が実施されるネットワークの概念図である。図示するように、仮想私設網（ＶＰＮ）クライアント１２は、セキュリティ保護されていない公衆ＩＰネットワーク、例としてインターネット１５を介してＶＰＮサービス・プロバイダ２０にアクセスすることができる。サービス・プロバイダ２０は、仮想私設網へのゲートウェイとして機能するいくつかのＶＰＮサーバ２２を含む。４つのＶＰＮサーバ２２１〜２２４が図示される。ＶＰＮサーバ２２は、セキュアな／信頼できるＩＰネットワークに接続するサービス・プロバイダのデータ・ネットワーク・インフラストラクチャ２３に接続される。このＩＰネットワークは、例として、サービス・プロバイダ２０の顧客である企業イントラネット３０である。イントラネット３０は、内部サーバ、データベース等の保護されるリソース３１を含む。下記で述べるように、この構成は、インターネット１５、ＶＰＮサーバ２２１、およびデータ・ネットワーク・インフラストラクチャ２３を介して、クライアント１２と、リソース３１のうち選択されたものとの間にセキュアな通信チャネルを提供する。セキュアなチャネルが確立されると、ユーザおよびグループ情報のセキュアな認証が行われることができる。
【００１５】
ＶＰＮサーバ２２は、サービス・プロバイダの制御インフラストラクチャ２１にもアクセスすることができ、インフラストラクチャ２１は、ＡＡＡ（認証、権限付与、課金）サーバ２１１、ポリシー・サーバ２１２、およびＩＰアドレス・データベース（ＤＢ）２１３を含む。クライアント１２のユーザがリソース３１の１つまたは複数にアクセスしたいときには、インターネット１５を通じて、ＶＰＮサーバ２２の特定の１つ、例としてＶＰＮサーバ２２１への通信セッションが開始される。ＶＰＮサーバ２２１とリソース３１間の通信チャネルは、セキュアなチャネルであり、サービス・プロバイダおよび／または企業イントラネットの所有者である企業によって管理される。しかし、クライアント１２からＶＰＮサーバ２２１までのチャネルは、公衆ネットワーク、すなわちインターネットを横断するため、セキュアでない。
【００１６】
インターネットを通じたクライアント１２とＶＰＮサーバ２２１間の通信のセキュリティを実現するために、この例のクライアントとサーバは、ＩＰＳｅｃ標準を使用して通信する。そのために、いくつかのいわゆる保護スイート（「ポリシー」と呼ばれる場合もある）がクライアント１２内で定義される。図２に示すように、クライアント１２（「イニシエータ」とも呼ばれる）は、保護スイート１、２、３、４、５と参照される５つの保護スイートをサポートするように構成されている。各保護スイートは、インターネット通信に特定レベルのセキュリティを実現するパラメータ値のセットからなる。具体的には、保護スイートは、例として次のパラメータで構成される：ａ）特定のＩＰＳｅｃプロトコルの識別、ｂ）特定の暗号化アルゴリズムの識別、およびｃ）特定のＤｉｆｆｉｅ−Ｈｅｌｌｍａｎグループおよびハッシュの識別等の他の保護属性。例として、保護スイート１は、諸項目の中でも特に、ａ）ＩＫＥ ＳＡプロトコル、ｂ）ＡＥＳ暗号化、ｃ）Ｄｉｆｆｉｅ−Ｈｅｌｌｍａｎグループ５、およびｄ）ＳＨＡ−１、のパラメータ値を含むことができる。保護スイート２は、特に、ａ）ＩＫＥ ＳＡプロトコル、ｂ）３ＤＥＳ暗号化、ｃ）Ｄｉｆｆｉｅ−Ｈｅｌｌｍａｎグループ２、およびｄ）ＳＨＡ−１ハッシュ、のパラメータ値からなることができる。これら各種の保護スイートは、重複する特性を有する場合もある。例えば、保護スイート３は、ＩＫＥ ＳＡプロトコルと３ＤＥＳ暗号化（保護スイート２と同様）、Ｄｉｆｆｉｅ−Ｈｅｌｌｍａｎグループ２（保護スイート２と同様）を含むことができ、またＭＤ５ハッシュも含むことができる。ポリシーは、各種のセキュリティ上の必要性を満たすように構成される。
【００１７】
クライアント１２は、ＶＰＮサーバ２２１（本発明では「レスポンダ」とも呼ぶ）との間で、当該セッションに使用する保護スイートについてネゴシエーションを開始する。具体的には、図２に示すように、クライアント１２は、クライアント１２が使用するように構成されているイニシエータ保護スイートのリストを含んだいわゆるＯｆｆｅｒを送信する。Ｏｆｆｅｒに含まれる保護スイートのリストは、特定の保護スイート各々を構成するパラメータ値のセットを指定する。
【００１８】
ＶＰＮサーバ２２は、この例では、８つの「レスポンダ」保護スイートＡ、Ｂ、Ｃ、．．．、Ｈのいずれかを使用するように構成されている。イニシエータ保護スイートの表記１、２、３．．．と、レスポンダ保護スイートの表記Ａ、Ｂ、Ｃ．．．の違いは、単に表記上の理由である。一般に、イニシエータ保護スイートの少なくとも１つは、レスポンダ保護スイートの少なくとも１つと同じである。例えば、レスポンダ保護スイートＣは、ａ）ＩＳＡＫＭＰ ＳＡプロトコル、ｂ）ＡＥＳ暗号化、ｃ）Ｄｉｆｆｉｅ−Ｈａｌｌｍａｎグループ２、からなることができる。すなわち、レスポンダ保護スイートＣは、イニシエータ保護スイート１と同じである可能性がある。ＶＰＮサーバ２２１は、自身の保護スイートの中でイニシエータ保護スイートの１つと一致する特定の１つを選択し、ＩＰＳｅｃ環境ではＩＫＥｐｒｏｐｏｓａｌと称されるいわゆる「Ｐｒｏｐｏｓａｌ」で、その保護スイートをクライアント１２に対して明らかにする。通例、レスポンダ保護スイートには優先順位があり、特定の保護スイートが法的に許可できないという一時的な事情は除いて、レスポンダは、Ｏｆｆｅｒに列挙されたイニシエータ保護スイートと一致する保護スイートで、自身の順位が最も高いものをＰｒｏｐｏｓａｌで指定する。したがって、先に挙げた例では、保護スイートＣが、Ｏｆｆｅｒで指定されるイニシエータ保護スイートと一致するものの中で最も好ましいレスポンダ保護スイートである場合、Ｐｒｏｐｏｓａｌは、保護スイート１をＰｒｏｐｏｓａｌで指定することになる。
【００１９】
図２にさらに示すように、セッションに使用する暗号鍵のネゴシエーションなどのさらなるネゴシエーションがその後行われる。上記の例を続けると、クライアント１２が現在位置する国がＡＥＳ暗号化の使用を許可しない場合がある。そのような場合、クライアントとサーバ間でネゴシエートされる保護スイートは、ＡＥＳを含むものであってはならない。ＶＰＮサーバ２２１もその国にあるのであれば、ＶＰＮサーバ２２１がＡＥＳを含む保護スイートとともに構成されていないので、問題はない。しかし、ＶＰＮサーバ２２１が別の国にある場合がある。例えば、クライアント１２が現在ＡＥＳの使用を許可していないインドにあり、一方、ＶＰＮサーバ２２１は、ＡＥＳが許可された米国にある場合がある。したがって、米国にあるサーバと通信する際に、クライアント１２は、例えば、保護スイート１を使用すると、物理的にインド国内に位置するインターネットの一部を通じてＡＥＳを使用させる点でインドの法律に違反することになる。
【００２０】
現在、ユーザは、許可されていない暗号化アルゴリズムを含むイニシエータ保護スイートをすべて（メニューやオプション画面を介して）使用不可にすることにより、現地法への準拠を達成することができる。この例では、これは、Ｏｆｆｅｒが、保護スイート１あるいはＡＥＳを含む他の保護スイートを一切含まないことを意味する。ＶＰＮサーバ２２１の最も好ましいレスポンダ保護スイートがＡＥＳを含んでいるとしても、サーバ２２１は、Ｏｆｆｅｒ中のそのような保護スイートには一致を見つけないことにより、見つかった一致する保護スイートがいずれもＡＥＳを含むものではないことを保証する。
【００２１】
しかし、不都合な点として、このような方式では、ユーザが、ａ）現地の規定に精通し、ｂ）暗号化あるいは他のパラメータに法規制を有する特定の国に入国する際に、自身のラップトップ中の問題となる保護スイートを忘れずに使用不可にすることが必要となる。ユーザにとって、現地の法規定の一覧を保持していなければならないことは面倒である。さらに、ユーザは、ある国から次の国へ移動する際にコンピュータのオプションを変更することを忘れる可能性も十分にある。例えばＧＰＳを使用したクライアントの場所の判定に基づいてこのタスクを行うようにクライアント自体を構成することも可能である。しかし、この方式では、諸国の法規定に関する最新の情報を得るために中央データベースに自動的にアクセスすることを恐らく含む、追加的な適切なソフトウェアをクライアントにロードすることが必要となる。
【００２２】
本発明によれば、これらのことがすべてレスポンダ側で対処される。詳細には、レスポンダは、使用するとクライアントが位置する国の法に違反する保護スイートを突き合わせの対象から除外する基準として、クライアントの場所を使用する。好都合な点として、この方式は、ネットワークにインテリジェンスを移し、ユーザが、ａ）現地の法を知っていること、ｂ）国を移動する際に忘れずにコンピュータを再設定することをいずれも不要にし、かつ／または、必要な機能を行うようにクライアント自体を構成する必要をなくす。
【００２３】
本発明は、次のように実施することができる。クライアント装置が、例えばＧＰＳを使用して自身の場所を判定し、その緯度と経度をサーバに報告し、サーバは、テーブル検索を用いてクライアントが現在いる国の場所を判定し、その後、上記のように、使用するとクライアントがいる国の法に違反することになる保護スイートを除外することができる。しかし、本発明の特徴によれば、イニシエータからの通信に含まれている発信元アドレス、この例では、現地のインターネット・サービス・プロバイダによってクライアント１２に割り当てられるイニシエータのＩＰアドレス、に基づいてレスポンダがイニシエータの場所を判定することにより、全プロセスがクライアントに対して透過になる。ＩＰアドレスと国の対応付けのデータは、容易に入手することができる。したがって、クライアントの場所は、ＩＰ環境では、例えば、イニシエータから受信されるパケットに含まれるレイヤ３のＩＰアドレスから判定することができる。図５は、フィールドの１つとしてパケットのソース・アドレスを含んでいる標準的なＩＰヘッダ形式を示す。
【００２４】
本明細書に開示される例示的実施形態では、ＶＰＮサーバ２２１は、プロセスを支援するポリシー・サーバ２１２にアクセスする。ポリシー・サーバ２１２は、下記で図４の内容の説明との関連で説明するように、ＩＰアドレス・データベース２１３にアクセスする。差し当たっては、ＶＰＮサーバ２２１がＩＰヘッダからクライアントのＩＰアドレスを入手し、そのアドレスをポリシー・サーバ２１２に送信することを図２から理解すれば十分である。ポリシー・サーバは、ＩＰアドレス・データベースから国の場所を判定し、許可されるレスポンダ保護スイートのリストをＶＰＮサーバ２２１に提供することによって応答する。例えば、レスポンダ保護スイートＡ〜Ｅが暗号化アルゴリズムとしてＤＥＳを含み、現地の法がＤＥＳのみの使用を許可する場合、ポリシー・サーバ２１２からＶＰＮサーバ２２１に提供される許可されるレスポンダ保護スイートのリストは、保護スイートＡ〜Ｅのみを含み、ＶＰＮサーバ２２１は、Ｏｆｆｅｒに含まれる保護スイートとの一致を見つける際に、それら５つの保護スイートに制限される。
【００２５】
図３は、すぐ上記で説明した機能の担当部分を実行するためにＶＰＮサーバ２２１によって実施されるプロセスのフローチャートである。具体的には、Ｏｆｆｅｒが受信されると（３１０）、Ｏｆｆｅｒの各パケットに含まれているクライアントのＩＰアドレスがＩＰヘッダから入手される（３１３）。そのアドレスがポリシー・サーバ２１２に送信され（３１５）、それに応答して、ＶＰＮサーバ２２１は、許可されるレスポンダ保護スイートのリストを受け取る（３１７）。ＶＰＮサーバ２２１に含まれているレスポンダ保護スイートの全集合には優先順位があることを思い出されたい。そして、許可されるリストにある保護スイートのうち最も好ましい保護スイートが、Ｏｆｆｅｒのイニシエータ保護スイートの１つと一致するかどうかが判定される（３２１）。一致する場合、ＶＰＮサーバは、一致したイニシエータ保護スイートを特定するＰｒｏｐｏｓａｌを送信し（３２３）、図３に示すプロセスは完了する。
【００２６】
許可されるリストにある保護スイートの中で最も好ましいものがＯｆｆｅｒのイニシエータ保護スイートと一致しない場合は、許可リストにあるすべての保護スイートが検討されたかどうかが判定される（３２５）。すべて検討されている場合は、一致はないことになり、ＶＰＮサーバは、当該セッションを拒否する（３２７）。一方、許可リストにあるすべての保護スイートが検討されたのではない場合は、許可リストにある保護スイートの中で次に好ましい保護スイートがＯｆｆｅｒのイニシエータ保護スイートと一致するかどうかが判定される（３２９）。一致する場合は、一致したイニシエータ保護スイートを特定するＰｒｏｐｏｓａｌが送信される（３２３）。そうでない場合は、許可リストにあるすべての保護スイートが検討されたかどうかが再度問われ（３２５）、プロセスは、ａ）一致が見つかるか、ｂ）セッションが拒否されるまで継続する。
【００２７】
図４は、すぐ上記で説明した機能の担当部分を実行するためにポリシー・サーバ２１２によって実施されるプロセスの概念フローチャートである。
ポリシー・サーバ２１２には２つのテーブルが記憶されている。テーブル２１２ｂは、レスポンダの保護スイートＡ〜Ｈをいくつかの保護スイート・グループに分類する。この例では、法で規制される保護スイートの唯一の態様は暗号化アルゴリズムであると想定する。したがって、レスポンダ保護スイートがそれぞれ３つの暗号化アルゴリズム（例えばＤＥＳ、３ＤＥＳ、ＡＥＳ）の１つを含むとすると、それらレスポンダ保護スイートを３つのグループ、Ｉ、ＩＩ、ＩＩＩに分類することが利便であり、可能である。ＤＥＳを含む保護スイートは、説明上、保護スイートＡ〜Ｃとし、グループＩとする。３ＤＥＳを含む保護スイートは、説明上、保護スイートＤおよびＥとし、グループＩＩとする。ＡＥＳを含む保護スイートは、説明上、保護スイートＦ〜Ｈとし、グループＩＩＩとする。テーブル２１２ａは、世界の各国を列挙し、国ごとに、３つの保護スイート・グループのうちどの使用が許可されるかを示す。
【００２８】
そして、動作の際、ポリシー・サーバ２１２は、ＶＰＮサーバ２２１からイニシエータのＩＰアドレスを受け取る。ポリシー・サーバ２１２は、そのアドレスを使用してＩＰアドレス・データベース２１３に照会し、そのアドレスを持つ装置（クライアント１２）が位置する国の識別をデータベースから受け取る。次いで、ポリシー・サーバ２１２は、テーブル２１２ａから、どの保護スイート・グループが現地の法で許可されるかを判定する。次いで、その判定結果を用いてテーブル２１２ｂにアクセスして、ＶＰＮサーバ２２１に送信される、前述の許可される保護スイートのリストを作成する。無論、レスポンダ保護スイートをグループに分けないことも可能である。国ごとに許可される保護スイートを直接テーブル２１２ａに列挙し、テーブル２１２ｂをなくしてもよい。しかし、図４に示す手法は、ａ）国が、許可される暗号化アルゴリズムに関する法を変更した時、および／またはｂ）新しいレスポンダ保護スイートが定義された時に変更を行うために多少平易な継続的なデータ保持を可能にする。
【００２９】
上記の説明は、本発明の原理を具体的に説明したに過ぎず、以下の段落で述べるように多くの変形が可能である。
本発明は、ＩＰベースのシステムおよびＩＰＳｅｃを含むＩＰプロトコルの文脈で提示した。しかし、本発明の原理は、現在周知の、または将来開発される可能性のある他種の通信プロトコルにも適用することができる。
【００３０】
ＩＰおよびＩＰＳｅｃの状況でも、特にクライアントとサーバの間でやり取りされる各種メッセージの順序および／または内容に関して、したがって、保護スイートの情報をいつ、どこで、どのようにやり取りするかに関して、変形が可能である。より詳細には、本明細書では、明記していないが、身元の保護が必要とされず、ネゴシエーションのために必要な往復の回数が減らされるいわゆるアグレッシブ・モードのＩＰＳｅｃの文脈で本発明を説明した。本発明の原理は、ＩＰＳｅｃの文脈で、いわゆるメイン・モードなど他の「形態」のＩＰＳｅｃにも適用可能である。こうしたＩＰＳｅｃの形態間の相違により、本発明の実施方法の詳細を変更することが望ましい場合もある。
【００３１】
それと同じように、本発明は、上記の特定のパラメータ値、例えば暗号化アルゴリズムがネゴシエートされるいわゆるフェーズ１のＩＫＥネゴシエーションの文脈で提示したことに留意されたい。しかし、本発明は、例えばいわゆるフェーズ２のネゴシエーションで他のパラメータがネゴシエートされる時にも使用することができる。
【００３２】
ポリシー・サーバ２１２によって行われる機能の一部またはすべては、代わりにＶＰＮサーバ２２１内で行うこともでき、その逆も同様である。具体的には、Ｏｆｆｅｒに含まれるイニシエータ保護スイートのリストは、ＶＰＮサーバ２２１からポリシー・サーバ２１２に転送し、ポリシー・サーバ２１２が図３に示す突き合わせの機能を行うことができる。この手法の利点は、所与の仮想私設網に通例含まれる複数のＶＰＮサーバのすべてが、新しく定義されたレスポンダ保護スイートに関する情報で更新されなくてもよいことである。
【００３３】
本発明は、仮想私設網の文脈で提示した。しかし、本発明の原理は、より広く他の種のネットワークに適用可能である。
本発明は、暗号化アルゴリズムに関して、クライアントに透過な現地法への準拠を可能にする手段として提示した。しかし、本発明の原理はより広く適用可能であり、現地の法が、可能性としては暗号化に関連しないプロトコル、ハッシュ、持続時間、認証等、暗号化以外の通信の態様を規制する状況で使用することができる。本明細書で使用される用語「現地の法」は、いわゆる「法律」自体だけでなく、規制、命令、指令、規則等、法律に類似する制約や規定も含むものとする。さらに、本発明は、その所有施設からクライアントがサーバにアクセスする私的あるいは準私的なエンティティが、特定のパラメータ値の使用に制約や規定を課す場合など、現地の法以外の理由で特定のパラメータ値が許可不能とみなされる環境で使用することができる。
【００３４】
将来のある時点で保護スイート自体が規格化された場合には、例示的実施形態のＶＰＮクライアントやＶＰＮサーバなどのエンティティが、各自でサポートされる各種保護スイートの内容を指定する必要はなくなる。そのような場合には、それらのエンティティが、名前あるいは保護スイートの何らかの他種の識別子を指定すれば済むようになると思われる。
【００３５】
本明細書で使用される用語「Ｏｆｆｅｒ（オファー）」および「Ｐｒｏｐｏｓａｌ（プロポーザル）」は、それらの最も広い態様で、単に、例えばクライアントとサーバなどの終点エンティティ間のやり取りの標識と理解されるものとする。したがって、本明細書におけるこれらの用語の使用は、本発明を特定の形式やＩＰＳｅｃなどのプロトコルに限定しないものとする。
【００３６】
したがって、本明細書に図示および／または記載される実施形態は例示的なものに過ぎないことが理解されよう。当業者は、本明細書には明示的には図示あるいは記載されないものの本発明の原理を実施し、したがって本発明の主旨および範囲内にある多数の代替構成およびプロセスを考案することができる。
【図面の簡単な説明】
【００３７】
【図１】本発明が実施される仮想私設網（ＶＰＮ）を含むネットワークの概念図である。
【図２】図１に示すＶＰＮクライアントとＶＰＮサーバ間の通信を示す図である。
【図３】本発明の実施を促進するためにレスポンダ、例として図１のＶＰＮサーバによって実施されるプロセスのフローチャートである。
【図４】本発明の実施を促進するために図１のネットワーク内のポリシー・サーバによって実施されるプロセスの概念フローチャートである。
【図５】図１のＶＰＮクライアントとＶＰＮサーバ間で通信されるパケットのＩＰヘッダの標準的な構造を示す図である。
【技術分野】
【０００１】
本発明は、仮想私設網などの通信ネットワークに関する。
【背景技術】
【０００２】
仮想私設網のユーザにとって重要な問題の１つは、特にデータがインターネットなどの公衆網を横断する場合のデータのセキュリティである。暗号化は、データを保護する方法の１つである。ＩＰＳｅｃ（ＩＰ Ｓｅｃｕｒｉｔｙの略）は、インターネットの主要標準組織であるＩｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅによって開発されたプロトコルの集合であり、公衆網上でのＴＣＰ／ＩＰスタックのＩＰ層におけるパケットのセキュアな交換を支援する。これらのプロトコルについては、少なくとも以下の文書に記載され、これらの文書は、参照により本明細書に全体が記載されるものとして含められる。ｗｗｗ．ｉｅｔｆ．ｏｒｇ、ｈｔｔｐ：／／ｗｗｗ．ｒｆｃ−ｅｄｉｔｏｒ．ｏｒｇ／、ＲＦＣ ２４０６ ｆｔｐ：／／ｆｔｐ．ｒｆｃ−ｅｄｉｔｏｒ．ｏｒｇ／ｉｎ−ｎｏｔｅｓ／ｒｆｃ２４０６、ＲＦＣ ２４０７ ｆｔｐ：／／ｆｔｐ．ｒｆｃ−ｅｄｉｔｏｒ．ｏｒｇ／ｉｎ−ｎｏｔｅｓ／ｒｆｃ２４０７、ＲＦＣ ２４０８ ｆｔｐ：／／ｆｔｐ．ｒｆｃ−ｅｄｉｔｏｒ．ｏｒｇ／ｉｎ−ｎｏｔｅｓ／ｒｆｃ２４０８．ｔｘｔ、ＲＦＣ ２４０９ ｆｔｐ：／／ｆｔｐ．ｒｆｃ−ｅｄｉｔｏｒ．ｏｒｇ／ｉｎ−ｎｏｔｅｓ／ｒｆｃ２４０９．ｔｘｔ、ＲＦＣ ４３０６ ｆｔｐ：／／ｆｔｐ．ｒｆｃ−ｅｄｉｔｏｒ．ｏｒｇ／ｉｎ−ｎｏｔｅｓ／ｒｆｃ４３０６。
【０００３】
ＩＰＳｅｃは、特に、仮想私設網を実装する際にセキュアなサービスを提供するために広く展開されている。ＩＰＳｅｃの仮想私設網は、サイト間の仮想私設網とリモート・アクセス用の仮想私設網の２つのカテゴリに分類することができる。リモート・アクセス用の仮想私設網のユーザは、業務の継続性のためにその接続を使用する。そうしたユーザには、各自の地理的位置に関係なく非常に重要なデータに安全にアクセスするためにこの種の接続に依拠する在宅勤務者や商用旅行者が含まれる。
【０００４】
ＩＰＳｅｃでは、ＤＥＳ、３ＤＥＳ、およびＡＥＳを含む数個の対称暗号化アルゴリズムが可能である。これらのアルゴリズムの違いは、ブロックおよび鍵のサイズである。ＤＥＳと３ＤＥＳのブロック・サイズは６４ビットで、これは、当該暗号化アルゴリズムの１回の実行で６４ビット（８バイト）を暗号化できることを意味する。一方、ＡＥＳのブロック・サイズは１２８ビットである。ＤＥＳは、その基本形で５６ビットの鍵を使用し、３ＤＥＳは、１６８ビットの鍵サイズ（３つの独立した５６ビットの鍵）であり、ＡＥＳは、少なくとも１２８ビットの鍵をサポートする。鍵長が長いほど、使用できる可能な鍵の数が多くなり、したがって暗号化が強くなり、これは総当たり攻撃で符号化を解読することがより難しくなることを意味する。
【非特許文献１】ｗｗｗ．ｉｅｔｆ．ｏｒｇ
【非特許文献２】ｈｔｔｐ：／／ｗｗｗ．ｒｆｃ−ｅｄｉｔｏｒ．ｏｒｇ／
【非特許文献３】ＲＦＣ ２４０６ ｆｔｐ：／／ｆｔｐ．ｒｆｃ−ｅｄｉｔｏｒ．ｏｒｇ／ｉｎ−ｎｏｔｅｓ／ｒｆｃ２４０６
【非特許文献４】ＲＦＣ ２４０７ ｆｔｐ：／／ｆｔｐ．ｒｆｃ−ｅｄｉｔｏｒ．ｏｒｇ／ｉｎ−ｎｏｔｅｓ／ｒｆｃ２４０７
【非特許文献５】ＲＦＣ ２４０８ ｆｔｐ：／／ｆｔｐ．ｒｆｃ−ｅｄｉｔｏｒ．ｏｒｇ／ｉｎ−ｎｏｔｅｓ／ｒｆｃ２４０８．ｔｘｔ
【非特許文献６】ＲＦＣ ２４０９ ｆｔｐ：／／ｆｔｐ．ｒｆｃ−ｅｄｉｔｏｒ．ｏｒｇ／ｉｎ−ｎｏｔｅｓ／ｒｆｃ２４０９．ｔｘｔ
【非特許文献７】ＲＦＣ ４３０６ ｆｔｐ：／／ｆｔｐ．ｒｆｃ−ｅｄｉｔｏｒ．ｏｒｇ／ｉｎ−ｎｏｔｅｓ／ｒｆｃ４３０６
【特許文献１】米国特許第６，４７０，４４７号
【特許文献２】米国特許第５，７８１，６２８号
【発明の開示】
【発明が解決しようとする課題】
【０００５】
すべての国がすべての暗号化アルゴリズムの使用を許可している訳ではない。一部の国の法規制は、特に強力なアルゴリズムで通信が暗号化されたときに有効な監視（例えば盗聴）を行うことが難しくなるため、特定の暗号化アルゴリズムのみの使用を許可している。これは、旅行するユーザにとっては、滞在している国の外にあるＶＰＮゲートウェイに接続する際に問題が生じる。米国を本拠地とする旅行者ユーザは、普通、米国内にいる時には上記の３つのアルゴリズムの中で最も安全性の高いアルゴリズム、すなわちＡＥＳを使用することを望む。しかし、ユーザが、ＡＥＳが許可されていない国に旅行する際には、現地の法規制あるいは規定に準拠するために、ＡＥＳより低い暗号化強度に格下げする必要がある。
【０００６】
そのような格下げは、ＩＰＳｅｃ環境または他の通信プロトコルの状況では容易に実現することができる。ＩＰＳｅｃを例に使用すると、ＩＰＳｅｃでは、ユーザの端末装置、すなわちＩＰＳｅｃクライアントが、いわゆる「セキュリティの関連付けペイロード」でＩＰＳｅｃサーバ（ゲートウェイ）にＯｆｆｅｒ（オファー、申し入れ）を送信することにより、セキュリティ・パラメータ値のネゴシエーションを開始する。このため、クライアントは、時にこの意味合いで「イニシエータ（ｉｎｉｔｉａｔｏｒ）」と呼ばれる。このＯｆｆｅｒは、通信の少なくとも１つの態様、具体的には通信のセキュリティを制御する１つまたは複数のセキュリティ・パラメータの値を含む、いわゆる「保護スイート（ｐｒｏｔｅｃｔｉｏｎ ｓｕｉｔｅ）」のリストを含む。各保護スイートは、ａ）特定のＩＰＳｅｃプロトコル、ｂ）特定の暗号化アルゴリズム（「トランスフォーム」とも称される）、およびｃ）Ｄｉｆｆｉｅ−Ｈｅｌｌｍａｎグループ、ハッシュ・パラメータ等のその他の保護属性またはパラメータ、の識別を備える。特定のプロトコル、暗号化アルゴリズム、または他のパラメータの識別を、本発明ではそのパラメータの「値」と呼ぶ。
【０００７】
ＩＰＳｅｃサーバは、サーバでサポートされる保護スイートの独自のリストをサポートする。サーバにサポートされる保護スイートの一部は、クライアントでサポートされる保護スイートと異なる場合もあるが、通例は一致する保護スイートが少なくとも１つある。Ｏｆｆｅｒに応答して、サーバは、クライアントとサーバの両方にサポートされる保護スイートのうちどれをそのセッションに使用するかを決定的な方式で選択する。例えば、現在の慣行では、サーバでサポートされる保護スイートに優先順位があり、サーバは、特定の方法論を用いて、当該通信セッションで使用するのに好ましい保護スイートを特定する。通例、その方法論は、Ｏｆｆｅｒに含まれている保護スイートで、サーバの順位付けが最も高い保護スイートを好ましい保護スイートとして特定する。そして、サーバは、そのセッションに使用する特定の保護スイートを特定するＰｒｏｐｏｓａｌ（プロポーザル、提案、ＩＰＳｅｃ環境では「ＩＫＥ Ｐｒｏｐｏｓａｌ」と呼ばれる）をクライアントに返す。したがって、サーバは、時にこの意味合いで「レスポンダ（ｒｅｓｐｏｎｄｅｒ）」と呼ばれる。その後、暗号鍵のネゴシエーションを含むセキュリティ・ネゴシエーションが継続する。その後、選択された保護スイートのパラメータ値、ネゴシエーション鍵、およびその他の固定パラメータ値またはネゴシエートされたパラメータ値に基づいて通信が進行する。
【０００８】
したがって、通信を確実に現地の（ｌｏｃａｌ ｌａｗ）に準拠させることは、非常に簡単なことである。ユーザは、ユーザインターフェース画面のチェックボックスなどを介してクライアント装置の通信オプションを設定して、例えば、許可されていない暗号化アルゴリズムや可能性としては他の許可されていない保護パラメータ値など、現地の法に違反することになるパラメータ値が組み込まれた保護スイート（「ポリシー」と呼ばれる場合もある）をすべてクライアント内で使用不可にすることができる。したがって、Ｏｆｆｅｒは、使用しても現地の法に違反しない保護スイートだけを含み、最終的にサーバによって選択され、Ｐｒｏｐｏｓａｌに指定される保護スイートが現地の法に違反するものではないことを保証する。
【課題を解決するための手段】
【０００９】
上記の手法は単純で平易であるが、本発明者は、さらなる改良が可能であることを認識した。
本発明の例示的実施形態では、レスポンダの保護スイートの選択が、使用すると許可されない通信を行わせるもの、例えば、特定の暗号化アルゴリズムを使用することで現地の法に違反する通信を行わせるものを含んでいる場合に、第１のエンティティ、すなわちレスポンダ（上記の例のＩＰＳｅｃサーバなど）が、第２のエンティティすなわちイニシエータ（ＩＰＳｅｃクライアントなど）の地理的位置を使用して、本来であれば当該セッションのためのレスポンダによる保護スイートの選択となる選択を変更する。したがって、イニシエータにサポートされる保護スイートが、例えばＡＥＳ暗号化アルゴリズムを組み込んだ特定の保護スイートを含んでいる場合には、その保護スイートが本来であればレスポンダの最も好ましい保護スイートであっても、レスポンダは、イニシエータから提案される保護スイートのうち別の保護スイート、すなわち許可されない保護パラメータ値を含まない保護スイートをＰｒｏｐｏｓａｌで指定する。
【００１０】
より広くは、本発明は、保護スイートが、そのうちの一部が通信のセキュリティに関連する複数のパラメータを含む実装を包含する。本発明は、保護スイートが１つのみのセキュリティ・パラメータ、例えば１つの暗号化標準やＤｉｆｆｉｅ−Ｈｅｌｌｍａｎグループの１つのみを含む場合のある実装も包含する。また、本発明は、より広くは、通信の少なくとも１つの態様がセキュリティや保護に関連するかどうかに関係なく、当該パラメータが、通信の少なくとも１つの態様を制御する実装を包含する。
【００１１】
イニシエータは、可能性としては例えばＧＰＳを使用して自身の地理的位置を判定することができ、その位置をサーバに報告することができ、サーバは、選択される保護スイートを、現地の法に違反しない保護スイートに限定する責任を負う。しかし、本発明の特定の実施形態では、レスポンダが、例えばパケットなど、イニシエータからの通信に含まれる発信元アドレスに基づいて、イニシエータの位置を判定する。例えば、ＩＰアドレスと国との対応付けのデータは容易に入手することができるので、ＩＰ環境では、イニシエータの位置は、例えばイニシエータから受信されるパケットに含まれるレイヤ３のＩＰアドレスから判定することができる。
【００１２】
本発明にはいくつかの利点がある。本発明は、現地の法についての知識をネットワークに移し、ユーザが現地の法について知る必要をなくす。さらに、ネットワークがイニシエータのＩＰアドレスまたは他のアドレスに基づいてイニシエータの位置を判定する実施形態では、イニシエータは、自身の地理的位置を識別する、あるいはその位置をネットワークに通信するように構成される必要がない。したがって、イニシエータ装置またはそのプロトコル・ソフトウェアで変更が一切必要とされることなく、現地の法規定に準拠した保護スイートの使用が実現される。
【００１３】
従来技術は、端末装置による特定の暗号化アルゴリズムの使用が、当該端末装置の位置に基づいて自動的に制御される構成を十分に認識している。例えば、２００２年１０月２２日にＬａｍｂｅｒｔ他に発行された米国特許第６，４７０，４４７号、１９９８年７月１４日にＡｌｐｅｒｏｖｉｃｈ他に発行された米国特許第５，７８１，６２８号を参照されたい。これらの特許は、無線通信（例えばセルラー電話）のコンテクストにおけるこの概念を開示する。しかし、その後も、本願の出願人は、例えば、クライアントの地理的位置を使用して、プロトコル・スイートの突き合わせが実施される方式を変更することが望ましいことを認識した。
【発明を実施するための最良の形態】
【００１４】
図１は、本発明が実施されるネットワークの概念図である。図示するように、仮想私設網（ＶＰＮ）クライアント１２は、セキュリティ保護されていない公衆ＩＰネットワーク、例としてインターネット１５を介してＶＰＮサービス・プロバイダ２０にアクセスすることができる。サービス・プロバイダ２０は、仮想私設網へのゲートウェイとして機能するいくつかのＶＰＮサーバ２２を含む。４つのＶＰＮサーバ２２１〜２２４が図示される。ＶＰＮサーバ２２は、セキュアな／信頼できるＩＰネットワークに接続するサービス・プロバイダのデータ・ネットワーク・インフラストラクチャ２３に接続される。このＩＰネットワークは、例として、サービス・プロバイダ２０の顧客である企業イントラネット３０である。イントラネット３０は、内部サーバ、データベース等の保護されるリソース３１を含む。下記で述べるように、この構成は、インターネット１５、ＶＰＮサーバ２２１、およびデータ・ネットワーク・インフラストラクチャ２３を介して、クライアント１２と、リソース３１のうち選択されたものとの間にセキュアな通信チャネルを提供する。セキュアなチャネルが確立されると、ユーザおよびグループ情報のセキュアな認証が行われることができる。
【００１５】
ＶＰＮサーバ２２は、サービス・プロバイダの制御インフラストラクチャ２１にもアクセスすることができ、インフラストラクチャ２１は、ＡＡＡ（認証、権限付与、課金）サーバ２１１、ポリシー・サーバ２１２、およびＩＰアドレス・データベース（ＤＢ）２１３を含む。クライアント１２のユーザがリソース３１の１つまたは複数にアクセスしたいときには、インターネット１５を通じて、ＶＰＮサーバ２２の特定の１つ、例としてＶＰＮサーバ２２１への通信セッションが開始される。ＶＰＮサーバ２２１とリソース３１間の通信チャネルは、セキュアなチャネルであり、サービス・プロバイダおよび／または企業イントラネットの所有者である企業によって管理される。しかし、クライアント１２からＶＰＮサーバ２２１までのチャネルは、公衆ネットワーク、すなわちインターネットを横断するため、セキュアでない。
【００１６】
インターネットを通じたクライアント１２とＶＰＮサーバ２２１間の通信のセキュリティを実現するために、この例のクライアントとサーバは、ＩＰＳｅｃ標準を使用して通信する。そのために、いくつかのいわゆる保護スイート（「ポリシー」と呼ばれる場合もある）がクライアント１２内で定義される。図２に示すように、クライアント１２（「イニシエータ」とも呼ばれる）は、保護スイート１、２、３、４、５と参照される５つの保護スイートをサポートするように構成されている。各保護スイートは、インターネット通信に特定レベルのセキュリティを実現するパラメータ値のセットからなる。具体的には、保護スイートは、例として次のパラメータで構成される：ａ）特定のＩＰＳｅｃプロトコルの識別、ｂ）特定の暗号化アルゴリズムの識別、およびｃ）特定のＤｉｆｆｉｅ−Ｈｅｌｌｍａｎグループおよびハッシュの識別等の他の保護属性。例として、保護スイート１は、諸項目の中でも特に、ａ）ＩＫＥ ＳＡプロトコル、ｂ）ＡＥＳ暗号化、ｃ）Ｄｉｆｆｉｅ−Ｈｅｌｌｍａｎグループ５、およびｄ）ＳＨＡ−１、のパラメータ値を含むことができる。保護スイート２は、特に、ａ）ＩＫＥ ＳＡプロトコル、ｂ）３ＤＥＳ暗号化、ｃ）Ｄｉｆｆｉｅ−Ｈｅｌｌｍａｎグループ２、およびｄ）ＳＨＡ−１ハッシュ、のパラメータ値からなることができる。これら各種の保護スイートは、重複する特性を有する場合もある。例えば、保護スイート３は、ＩＫＥ ＳＡプロトコルと３ＤＥＳ暗号化（保護スイート２と同様）、Ｄｉｆｆｉｅ−Ｈｅｌｌｍａｎグループ２（保護スイート２と同様）を含むことができ、またＭＤ５ハッシュも含むことができる。ポリシーは、各種のセキュリティ上の必要性を満たすように構成される。
【００１７】
クライアント１２は、ＶＰＮサーバ２２１（本発明では「レスポンダ」とも呼ぶ）との間で、当該セッションに使用する保護スイートについてネゴシエーションを開始する。具体的には、図２に示すように、クライアント１２は、クライアント１２が使用するように構成されているイニシエータ保護スイートのリストを含んだいわゆるＯｆｆｅｒを送信する。Ｏｆｆｅｒに含まれる保護スイートのリストは、特定の保護スイート各々を構成するパラメータ値のセットを指定する。
【００１８】
ＶＰＮサーバ２２は、この例では、８つの「レスポンダ」保護スイートＡ、Ｂ、Ｃ、．．．、Ｈのいずれかを使用するように構成されている。イニシエータ保護スイートの表記１、２、３．．．と、レスポンダ保護スイートの表記Ａ、Ｂ、Ｃ．．．の違いは、単に表記上の理由である。一般に、イニシエータ保護スイートの少なくとも１つは、レスポンダ保護スイートの少なくとも１つと同じである。例えば、レスポンダ保護スイートＣは、ａ）ＩＳＡＫＭＰ ＳＡプロトコル、ｂ）ＡＥＳ暗号化、ｃ）Ｄｉｆｆｉｅ−Ｈａｌｌｍａｎグループ２、からなることができる。すなわち、レスポンダ保護スイートＣは、イニシエータ保護スイート１と同じである可能性がある。ＶＰＮサーバ２２１は、自身の保護スイートの中でイニシエータ保護スイートの１つと一致する特定の１つを選択し、ＩＰＳｅｃ環境ではＩＫＥｐｒｏｐｏｓａｌと称されるいわゆる「Ｐｒｏｐｏｓａｌ」で、その保護スイートをクライアント１２に対して明らかにする。通例、レスポンダ保護スイートには優先順位があり、特定の保護スイートが法的に許可できないという一時的な事情は除いて、レスポンダは、Ｏｆｆｅｒに列挙されたイニシエータ保護スイートと一致する保護スイートで、自身の順位が最も高いものをＰｒｏｐｏｓａｌで指定する。したがって、先に挙げた例では、保護スイートＣが、Ｏｆｆｅｒで指定されるイニシエータ保護スイートと一致するものの中で最も好ましいレスポンダ保護スイートである場合、Ｐｒｏｐｏｓａｌは、保護スイート１をＰｒｏｐｏｓａｌで指定することになる。
【００１９】
図２にさらに示すように、セッションに使用する暗号鍵のネゴシエーションなどのさらなるネゴシエーションがその後行われる。上記の例を続けると、クライアント１２が現在位置する国がＡＥＳ暗号化の使用を許可しない場合がある。そのような場合、クライアントとサーバ間でネゴシエートされる保護スイートは、ＡＥＳを含むものであってはならない。ＶＰＮサーバ２２１もその国にあるのであれば、ＶＰＮサーバ２２１がＡＥＳを含む保護スイートとともに構成されていないので、問題はない。しかし、ＶＰＮサーバ２２１が別の国にある場合がある。例えば、クライアント１２が現在ＡＥＳの使用を許可していないインドにあり、一方、ＶＰＮサーバ２２１は、ＡＥＳが許可された米国にある場合がある。したがって、米国にあるサーバと通信する際に、クライアント１２は、例えば、保護スイート１を使用すると、物理的にインド国内に位置するインターネットの一部を通じてＡＥＳを使用させる点でインドの法律に違反することになる。
【００２０】
現在、ユーザは、許可されていない暗号化アルゴリズムを含むイニシエータ保護スイートをすべて（メニューやオプション画面を介して）使用不可にすることにより、現地法への準拠を達成することができる。この例では、これは、Ｏｆｆｅｒが、保護スイート１あるいはＡＥＳを含む他の保護スイートを一切含まないことを意味する。ＶＰＮサーバ２２１の最も好ましいレスポンダ保護スイートがＡＥＳを含んでいるとしても、サーバ２２１は、Ｏｆｆｅｒ中のそのような保護スイートには一致を見つけないことにより、見つかった一致する保護スイートがいずれもＡＥＳを含むものではないことを保証する。
【００２１】
しかし、不都合な点として、このような方式では、ユーザが、ａ）現地の規定に精通し、ｂ）暗号化あるいは他のパラメータに法規制を有する特定の国に入国する際に、自身のラップトップ中の問題となる保護スイートを忘れずに使用不可にすることが必要となる。ユーザにとって、現地の法規定の一覧を保持していなければならないことは面倒である。さらに、ユーザは、ある国から次の国へ移動する際にコンピュータのオプションを変更することを忘れる可能性も十分にある。例えばＧＰＳを使用したクライアントの場所の判定に基づいてこのタスクを行うようにクライアント自体を構成することも可能である。しかし、この方式では、諸国の法規定に関する最新の情報を得るために中央データベースに自動的にアクセスすることを恐らく含む、追加的な適切なソフトウェアをクライアントにロードすることが必要となる。
【００２２】
本発明によれば、これらのことがすべてレスポンダ側で対処される。詳細には、レスポンダは、使用するとクライアントが位置する国の法に違反する保護スイートを突き合わせの対象から除外する基準として、クライアントの場所を使用する。好都合な点として、この方式は、ネットワークにインテリジェンスを移し、ユーザが、ａ）現地の法を知っていること、ｂ）国を移動する際に忘れずにコンピュータを再設定することをいずれも不要にし、かつ／または、必要な機能を行うようにクライアント自体を構成する必要をなくす。
【００２３】
本発明は、次のように実施することができる。クライアント装置が、例えばＧＰＳを使用して自身の場所を判定し、その緯度と経度をサーバに報告し、サーバは、テーブル検索を用いてクライアントが現在いる国の場所を判定し、その後、上記のように、使用するとクライアントがいる国の法に違反することになる保護スイートを除外することができる。しかし、本発明の特徴によれば、イニシエータからの通信に含まれている発信元アドレス、この例では、現地のインターネット・サービス・プロバイダによってクライアント１２に割り当てられるイニシエータのＩＰアドレス、に基づいてレスポンダがイニシエータの場所を判定することにより、全プロセスがクライアントに対して透過になる。ＩＰアドレスと国の対応付けのデータは、容易に入手することができる。したがって、クライアントの場所は、ＩＰ環境では、例えば、イニシエータから受信されるパケットに含まれるレイヤ３のＩＰアドレスから判定することができる。図５は、フィールドの１つとしてパケットのソース・アドレスを含んでいる標準的なＩＰヘッダ形式を示す。
【００２４】
本明細書に開示される例示的実施形態では、ＶＰＮサーバ２２１は、プロセスを支援するポリシー・サーバ２１２にアクセスする。ポリシー・サーバ２１２は、下記で図４の内容の説明との関連で説明するように、ＩＰアドレス・データベース２１３にアクセスする。差し当たっては、ＶＰＮサーバ２２１がＩＰヘッダからクライアントのＩＰアドレスを入手し、そのアドレスをポリシー・サーバ２１２に送信することを図２から理解すれば十分である。ポリシー・サーバは、ＩＰアドレス・データベースから国の場所を判定し、許可されるレスポンダ保護スイートのリストをＶＰＮサーバ２２１に提供することによって応答する。例えば、レスポンダ保護スイートＡ〜Ｅが暗号化アルゴリズムとしてＤＥＳを含み、現地の法がＤＥＳのみの使用を許可する場合、ポリシー・サーバ２１２からＶＰＮサーバ２２１に提供される許可されるレスポンダ保護スイートのリストは、保護スイートＡ〜Ｅのみを含み、ＶＰＮサーバ２２１は、Ｏｆｆｅｒに含まれる保護スイートとの一致を見つける際に、それら５つの保護スイートに制限される。
【００２５】
図３は、すぐ上記で説明した機能の担当部分を実行するためにＶＰＮサーバ２２１によって実施されるプロセスのフローチャートである。具体的には、Ｏｆｆｅｒが受信されると（３１０）、Ｏｆｆｅｒの各パケットに含まれているクライアントのＩＰアドレスがＩＰヘッダから入手される（３１３）。そのアドレスがポリシー・サーバ２１２に送信され（３１５）、それに応答して、ＶＰＮサーバ２２１は、許可されるレスポンダ保護スイートのリストを受け取る（３１７）。ＶＰＮサーバ２２１に含まれているレスポンダ保護スイートの全集合には優先順位があることを思い出されたい。そして、許可されるリストにある保護スイートのうち最も好ましい保護スイートが、Ｏｆｆｅｒのイニシエータ保護スイートの１つと一致するかどうかが判定される（３２１）。一致する場合、ＶＰＮサーバは、一致したイニシエータ保護スイートを特定するＰｒｏｐｏｓａｌを送信し（３２３）、図３に示すプロセスは完了する。
【００２６】
許可されるリストにある保護スイートの中で最も好ましいものがＯｆｆｅｒのイニシエータ保護スイートと一致しない場合は、許可リストにあるすべての保護スイートが検討されたかどうかが判定される（３２５）。すべて検討されている場合は、一致はないことになり、ＶＰＮサーバは、当該セッションを拒否する（３２７）。一方、許可リストにあるすべての保護スイートが検討されたのではない場合は、許可リストにある保護スイートの中で次に好ましい保護スイートがＯｆｆｅｒのイニシエータ保護スイートと一致するかどうかが判定される（３２９）。一致する場合は、一致したイニシエータ保護スイートを特定するＰｒｏｐｏｓａｌが送信される（３２３）。そうでない場合は、許可リストにあるすべての保護スイートが検討されたかどうかが再度問われ（３２５）、プロセスは、ａ）一致が見つかるか、ｂ）セッションが拒否されるまで継続する。
【００２７】
図４は、すぐ上記で説明した機能の担当部分を実行するためにポリシー・サーバ２１２によって実施されるプロセスの概念フローチャートである。
ポリシー・サーバ２１２には２つのテーブルが記憶されている。テーブル２１２ｂは、レスポンダの保護スイートＡ〜Ｈをいくつかの保護スイート・グループに分類する。この例では、法で規制される保護スイートの唯一の態様は暗号化アルゴリズムであると想定する。したがって、レスポンダ保護スイートがそれぞれ３つの暗号化アルゴリズム（例えばＤＥＳ、３ＤＥＳ、ＡＥＳ）の１つを含むとすると、それらレスポンダ保護スイートを３つのグループ、Ｉ、ＩＩ、ＩＩＩに分類することが利便であり、可能である。ＤＥＳを含む保護スイートは、説明上、保護スイートＡ〜Ｃとし、グループＩとする。３ＤＥＳを含む保護スイートは、説明上、保護スイートＤおよびＥとし、グループＩＩとする。ＡＥＳを含む保護スイートは、説明上、保護スイートＦ〜Ｈとし、グループＩＩＩとする。テーブル２１２ａは、世界の各国を列挙し、国ごとに、３つの保護スイート・グループのうちどの使用が許可されるかを示す。
【００２８】
そして、動作の際、ポリシー・サーバ２１２は、ＶＰＮサーバ２２１からイニシエータのＩＰアドレスを受け取る。ポリシー・サーバ２１２は、そのアドレスを使用してＩＰアドレス・データベース２１３に照会し、そのアドレスを持つ装置（クライアント１２）が位置する国の識別をデータベースから受け取る。次いで、ポリシー・サーバ２１２は、テーブル２１２ａから、どの保護スイート・グループが現地の法で許可されるかを判定する。次いで、その判定結果を用いてテーブル２１２ｂにアクセスして、ＶＰＮサーバ２２１に送信される、前述の許可される保護スイートのリストを作成する。無論、レスポンダ保護スイートをグループに分けないことも可能である。国ごとに許可される保護スイートを直接テーブル２１２ａに列挙し、テーブル２１２ｂをなくしてもよい。しかし、図４に示す手法は、ａ）国が、許可される暗号化アルゴリズムに関する法を変更した時、および／またはｂ）新しいレスポンダ保護スイートが定義された時に変更を行うために多少平易な継続的なデータ保持を可能にする。
【００２９】
上記の説明は、本発明の原理を具体的に説明したに過ぎず、以下の段落で述べるように多くの変形が可能である。
本発明は、ＩＰベースのシステムおよびＩＰＳｅｃを含むＩＰプロトコルの文脈で提示した。しかし、本発明の原理は、現在周知の、または将来開発される可能性のある他種の通信プロトコルにも適用することができる。
【００３０】
ＩＰおよびＩＰＳｅｃの状況でも、特にクライアントとサーバの間でやり取りされる各種メッセージの順序および／または内容に関して、したがって、保護スイートの情報をいつ、どこで、どのようにやり取りするかに関して、変形が可能である。より詳細には、本明細書では、明記していないが、身元の保護が必要とされず、ネゴシエーションのために必要な往復の回数が減らされるいわゆるアグレッシブ・モードのＩＰＳｅｃの文脈で本発明を説明した。本発明の原理は、ＩＰＳｅｃの文脈で、いわゆるメイン・モードなど他の「形態」のＩＰＳｅｃにも適用可能である。こうしたＩＰＳｅｃの形態間の相違により、本発明の実施方法の詳細を変更することが望ましい場合もある。
【００３１】
それと同じように、本発明は、上記の特定のパラメータ値、例えば暗号化アルゴリズムがネゴシエートされるいわゆるフェーズ１のＩＫＥネゴシエーションの文脈で提示したことに留意されたい。しかし、本発明は、例えばいわゆるフェーズ２のネゴシエーションで他のパラメータがネゴシエートされる時にも使用することができる。
【００３２】
ポリシー・サーバ２１２によって行われる機能の一部またはすべては、代わりにＶＰＮサーバ２２１内で行うこともでき、その逆も同様である。具体的には、Ｏｆｆｅｒに含まれるイニシエータ保護スイートのリストは、ＶＰＮサーバ２２１からポリシー・サーバ２１２に転送し、ポリシー・サーバ２１２が図３に示す突き合わせの機能を行うことができる。この手法の利点は、所与の仮想私設網に通例含まれる複数のＶＰＮサーバのすべてが、新しく定義されたレスポンダ保護スイートに関する情報で更新されなくてもよいことである。
【００３３】
本発明は、仮想私設網の文脈で提示した。しかし、本発明の原理は、より広く他の種のネットワークに適用可能である。
本発明は、暗号化アルゴリズムに関して、クライアントに透過な現地法への準拠を可能にする手段として提示した。しかし、本発明の原理はより広く適用可能であり、現地の法が、可能性としては暗号化に関連しないプロトコル、ハッシュ、持続時間、認証等、暗号化以外の通信の態様を規制する状況で使用することができる。本明細書で使用される用語「現地の法」は、いわゆる「法律」自体だけでなく、規制、命令、指令、規則等、法律に類似する制約や規定も含むものとする。さらに、本発明は、その所有施設からクライアントがサーバにアクセスする私的あるいは準私的なエンティティが、特定のパラメータ値の使用に制約や規定を課す場合など、現地の法以外の理由で特定のパラメータ値が許可不能とみなされる環境で使用することができる。
【００３４】
将来のある時点で保護スイート自体が規格化された場合には、例示的実施形態のＶＰＮクライアントやＶＰＮサーバなどのエンティティが、各自でサポートされる各種保護スイートの内容を指定する必要はなくなる。そのような場合には、それらのエンティティが、名前あるいは保護スイートの何らかの他種の識別子を指定すれば済むようになると思われる。
【００３５】
本明細書で使用される用語「Ｏｆｆｅｒ（オファー）」および「Ｐｒｏｐｏｓａｌ（プロポーザル）」は、それらの最も広い態様で、単に、例えばクライアントとサーバなどの終点エンティティ間のやり取りの標識と理解されるものとする。したがって、本明細書におけるこれらの用語の使用は、本発明を特定の形式やＩＰＳｅｃなどのプロトコルに限定しないものとする。
【００３６】
したがって、本明細書に図示および／または記載される実施形態は例示的なものに過ぎないことが理解されよう。当業者は、本明細書には明示的には図示あるいは記載されないものの本発明の原理を実施し、したがって本発明の主旨および範囲内にある多数の代替構成およびプロセスを考案することができる。
【図面の簡単な説明】
【００３７】
【図１】本発明が実施される仮想私設網（ＶＰＮ）を含むネットワークの概念図である。
【図２】図１に示すＶＰＮクライアントとＶＰＮサーバ間の通信を示す図である。
【図３】本発明の実施を促進するためにレスポンダ、例として図１のＶＰＮサーバによって実施されるプロセスのフローチャートである。
【図４】本発明の実施を促進するために図１のネットワーク内のポリシー・サーバによって実施されるプロセスの概念フローチャートである。
【図５】図１のＶＰＮクライアントとＶＰＮサーバ間で通信されるパケットのＩＰヘッダの標準的な構造を示す図である。
【特許請求の範囲】
【請求項１】
通信の少なくとも１つの態様を制御する少なくとも１つのパラメータのサポートされる複数の値のうち選択された値を使用して、他のエンティティと通信するように構成された第１のエンティティによって使用する方法であって、
前記パラメータの提案される値を含む、第２のエンティティからのオファーを受信することと、
前記サポートされる値の１つでもある、前記提案される値の１つを前記選択された値として識別するプロポーザルを前記第２のエンティティに送信することと
を備え、
前記選択された値は、ａ）その特定の値を使用した前記第２のエンティティとの通信が前記第２のエンティティの位置で許可される場合には、前記提案され、かつサポートされる値のうち特定の値、および、ｂ）許可されない場合は、前記提案されかつサポートされる値のうち別の値である方法。
【請求項２】
前記少なくとも１つのパラメータは、セキュリティ・パラメータである、請求項１に記載の方法。
【請求項３】
前記セキュリティ・パラメータは、暗号化アルゴリズムである、請求項２に記載の方法。
【請求項４】
前記セキュリティ・パラメータの値は、個々の暗号化アルゴリズムの識別子である、請求項３に記載の方法。
【請求項５】
前記提案されかつサポートされる値のうち前記別の値は、前記選択された値が、前記提案されかつサポートされる値のうち前記別の値である結果、前記第２のエンティティとの通信が前記第２のエンティティの位置において許容不能にならないような値である、請求項１に記載の方法。
【請求項６】
前記第１のエンティティはネットワーク・サーバであり、前記第２のエンティティは前記サーバのクライアントである、請求項１に記載の方法。
【請求項７】
前記第１のエンティティは、仮想私設網のゲートウェイであり、前記第２のエンティティは、前記仮想私設網のクライアントであり、前記ゲートウェイと前記クライアントとの間の通信は、公衆ネットワークを横断する、請求項１に記載の方法。
【請求項８】
前記公衆ネットワークはインターネットである、請求項７に記載の方法。
【請求項９】
前記オファーの受信と前記プロポーザルの送信は、少なくとも１つのＩＰＳｅｃプロトコルに準拠する、請求項１に記載の方法。
【請求項１０】
前記許容不能な通信は、前記第２のエンティティが位置する場所における法的規制に違反する通信である、請求項１に記載の方法。
【請求項１１】
前記サポートされる値は、優先順位を有し、
前記提案されかつサポートされる値のうち前記特定の１つは、前記優先順位に基づいて選択され、
前記提案されかつサポートされる値のうち前記別の値は、前記提案されかつサポートされる値のうち前記特定の値よりも前記優先順位が低い、
請求項１に記載の方法。
【請求項１２】
個々のパラメータのサーバでサポートされる１つまたは複数の値をそれぞれが備える複数の組（ｓｕｉｔｅ）のうち選択された組によって少なくとも一部が定義される方式でクライアントと通信するように構成されたサーバによって使用する方法であって、
前記パラメータについて２つ以上の提案される値の組を含む、クライアントからのオファーを受信することと、
前記サーバでサポートされる値の組の１つでもある、前記提案される組の１つを前記選択された組として識別するプロポーザルを、前記クライアントに送信することと
を備え、
前記選択された組は、その組を使用すると前記クライアントとの通信が１つまたは複数の法規制に違反することになる場合以外は、前記サーバでサポートされる組の優先順位に基づいて決定される、前記提案され、かつサーバでサポートされる組のうち好ましい組であり、法規制に違反することになる場合、前記選択された組は、その組を使用しても前記クライアントとの通信が前記１つまたは複数の法規制に違反しない、前記提案され、かつサーバでサポートされる組のうち別の組である方法。
【請求項１３】
前記パラメータの少なくとも１つはセキュリティ・パラメータである、請求項１２に記載の方法。
【請求項１４】
前記セキュリティ・パラメータは暗号化アルゴリズムである、請求項１３に記載の方法。
【請求項１５】
前記パラメータの前記１つの各値は、個々の異なる暗号化アルゴリズムの識別子である、請求項１４に記載の方法。
【請求項１６】
前記サーバは仮想私設網のゲートウェイであり、前記ゲートウェイと前記クライアント間の通信は、公衆ネットワークを横断する、請求項１２に記載の方法。
【請求項１７】
前記公衆ネットワークはインターネットである、請求項１６に記載の方法。
【請求項１８】
前記オファーの受信と前記プロポーザルの送信は、少なくとも１つのＩＰＳｅｃプロトコルに準拠する、請求項１６に記載の方法。
【請求項１９】
前記提案され、かつサーバでサポートされる組のうち前記好ましい組は、前記提案される組の中で前記優先順位が最も高い組であり、前記提案され、かつサーバでサポートされる組のうち前記別の組は、前記好ましい組よりも前記優先順位が低い、請求項１に記載の方法。
【請求項１】
通信の少なくとも１つの態様を制御する少なくとも１つのパラメータのサポートされる複数の値のうち選択された値を使用して、他のエンティティと通信するように構成された第１のエンティティによって使用する方法であって、
前記パラメータの提案される値を含む、第２のエンティティからのオファーを受信することと、
前記サポートされる値の１つでもある、前記提案される値の１つを前記選択された値として識別するプロポーザルを前記第２のエンティティに送信することと
を備え、
前記選択された値は、ａ）その特定の値を使用した前記第２のエンティティとの通信が前記第２のエンティティの位置で許可される場合には、前記提案され、かつサポートされる値のうち特定の値、および、ｂ）許可されない場合は、前記提案されかつサポートされる値のうち別の値である方法。
【請求項２】
前記少なくとも１つのパラメータは、セキュリティ・パラメータである、請求項１に記載の方法。
【請求項３】
前記セキュリティ・パラメータは、暗号化アルゴリズムである、請求項２に記載の方法。
【請求項４】
前記セキュリティ・パラメータの値は、個々の暗号化アルゴリズムの識別子である、請求項３に記載の方法。
【請求項５】
前記提案されかつサポートされる値のうち前記別の値は、前記選択された値が、前記提案されかつサポートされる値のうち前記別の値である結果、前記第２のエンティティとの通信が前記第２のエンティティの位置において許容不能にならないような値である、請求項１に記載の方法。
【請求項６】
前記第１のエンティティはネットワーク・サーバであり、前記第２のエンティティは前記サーバのクライアントである、請求項１に記載の方法。
【請求項７】
前記第１のエンティティは、仮想私設網のゲートウェイであり、前記第２のエンティティは、前記仮想私設網のクライアントであり、前記ゲートウェイと前記クライアントとの間の通信は、公衆ネットワークを横断する、請求項１に記載の方法。
【請求項８】
前記公衆ネットワークはインターネットである、請求項７に記載の方法。
【請求項９】
前記オファーの受信と前記プロポーザルの送信は、少なくとも１つのＩＰＳｅｃプロトコルに準拠する、請求項１に記載の方法。
【請求項１０】
前記許容不能な通信は、前記第２のエンティティが位置する場所における法的規制に違反する通信である、請求項１に記載の方法。
【請求項１１】
前記サポートされる値は、優先順位を有し、
前記提案されかつサポートされる値のうち前記特定の１つは、前記優先順位に基づいて選択され、
前記提案されかつサポートされる値のうち前記別の値は、前記提案されかつサポートされる値のうち前記特定の値よりも前記優先順位が低い、
請求項１に記載の方法。
【請求項１２】
個々のパラメータのサーバでサポートされる１つまたは複数の値をそれぞれが備える複数の組（ｓｕｉｔｅ）のうち選択された組によって少なくとも一部が定義される方式でクライアントと通信するように構成されたサーバによって使用する方法であって、
前記パラメータについて２つ以上の提案される値の組を含む、クライアントからのオファーを受信することと、
前記サーバでサポートされる値の組の１つでもある、前記提案される組の１つを前記選択された組として識別するプロポーザルを、前記クライアントに送信することと
を備え、
前記選択された組は、その組を使用すると前記クライアントとの通信が１つまたは複数の法規制に違反することになる場合以外は、前記サーバでサポートされる組の優先順位に基づいて決定される、前記提案され、かつサーバでサポートされる組のうち好ましい組であり、法規制に違反することになる場合、前記選択された組は、その組を使用しても前記クライアントとの通信が前記１つまたは複数の法規制に違反しない、前記提案され、かつサーバでサポートされる組のうち別の組である方法。
【請求項１３】
前記パラメータの少なくとも１つはセキュリティ・パラメータである、請求項１２に記載の方法。
【請求項１４】
前記セキュリティ・パラメータは暗号化アルゴリズムである、請求項１３に記載の方法。
【請求項１５】
前記パラメータの前記１つの各値は、個々の異なる暗号化アルゴリズムの識別子である、請求項１４に記載の方法。
【請求項１６】
前記サーバは仮想私設網のゲートウェイであり、前記ゲートウェイと前記クライアント間の通信は、公衆ネットワークを横断する、請求項１２に記載の方法。
【請求項１７】
前記公衆ネットワークはインターネットである、請求項１６に記載の方法。
【請求項１８】
前記オファーの受信と前記プロポーザルの送信は、少なくとも１つのＩＰＳｅｃプロトコルに準拠する、請求項１６に記載の方法。
【請求項１９】
前記提案され、かつサーバでサポートされる組のうち前記好ましい組は、前記提案される組の中で前記優先順位が最も高い組であり、前記提案され、かつサーバでサポートされる組のうち前記別の組は、前記好ましい組よりも前記優先順位が低い、請求項１に記載の方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図２】
【図３】
【図４】
【図５】
【公開番号】特開２００８−１６０８５１（Ｐ２００８−１６０８５１Ａ）
【公開日】平成２０年７月１０日（２００８．７．１０）
【国際特許分類】
【出願番号】特願２００７−３２９６６５（Ｐ２００７−３２９６６５）
【出願日】平成１９年１２月２１日（２００７．１２．２１）
【出願人】（３９００３５４９３）エイ・ティ・アンド・ティ・コーポレーション (130)
【氏名又は名称原語表記】ＡＴ＆Ｔ ＣＯＲＰ．
【Ｆターム（参考）】
【公開日】平成２０年７月１０日（２００８．７．１０）
【国際特許分類】
【出願日】平成１９年１２月２１日（２００７．１２．２１）
【出願人】（３９００３５４９３）エイ・ティ・アンド・ティ・コーポレーション (130)
【氏名又は名称原語表記】ＡＴ＆Ｔ ＣＯＲＰ．
【Ｆターム（参考）】
[ Back to top ]