[関連出願への相互参照]
この出願は、2018年11月15日に出願された"セキュリティアソシエーションSAの鍵再生成"と題するインド特許出願第IN201831042965号に基づく優先権を主張し、その内容は、その全体が参照により本明細書に組み込まれる。
本明細書における開示は、一般的に、遠隔通信に関し、より具体的には、インターネットセキュリティプロトコルに関し、そして、さらにいっそう具体的には、制限された電力、帯域幅、及び/又は処理能力を有するモバイルデバイス等のためのセキュリティアソシエーションを鍵再生成するための方法、デバイス、システムに関する。
インターネット鍵交換バージョン2(IKEv2)は、RFC7296によって定義されるプロトコルであり、IKEv2は、本明細書における明示的な開示に反する場合を除き、本明細書に完全に記載されているかのように、すべての目的のために参照により本明細書に組み込まれている。本明細書において使用される複数の語は、本明細書における明示的な開示に反する場合を除き、RFC7296によって与えられる意味を有する。
IKEv2は、IPSecプロトコル一式によってセキュリティアソシエーション(SA)をセットアップするのに使用される。セキュリティアソシエーションSAは、IKEトンネル又はIPsecトンネルであってもよい。インターネットプロトコルセキュリティ(IPsec)は、ネットワークを介して送信されるデータのパケットを認証し及び暗号化するネットワークプロトコル一式である。
IKEメッセージフローは、要求及びその要求に続く応答を含む。信頼性を保証することは、要求側の責任である。タイムアウト間隔の中でその応答を受信しない場合には、要求側は、その要求を再送信する必要がある(又は、その接続を放棄する必要がある)。IKEセッションの要求側とレスポンダとの間の最初の要求/応答メッセージ対(IKE_SA_INIT)は、IKE_SAのためのセキュリティパラメータを交渉し、ノンスを送信し、そして、複数のDiffie-Hellman値を送信する。2番目の要求/応答メッセージ対(IKE_AUTH)は、複数の識別子を送信し、それらの2つの識別子に対応する秘密の知識を証明し、そして、最初の(及び、最初のみのことが多い)認証ヘッダー(AH)及び/又はカプセル化セキュリティペイロード(ESP) CHILD_SAのためのSAをセットアップする。
IKEv2のIKE鍵再生成手順は、RFC7296によって定義され、RFC7296は、本明細書における明示的な開示に反する場合を除き、本明細書に完全に記載されているかのように、すべての目的のために参照により本明細書に組み込まれている。本明細書において使用される複数の語は、本明細書における明示的な開示に反する場合を除き、RFC7296によって与えられる意味を有する。
定義によれば、鍵再生成は、SAの期限が切れる前に、期限が切れるそのSAの代わりとなる新たなSAを作成することである。
例えば、要求側とレスポンダとの間のIKE鍵再生成のやりとりは、1つ又は複数のSAペイロードを搬送し、それらのSAペイロードは、それら自体が1つ又は複数の提案ペイロードを含む。各々の提案は、暗号法一式の単一のセット(例えば、単一の又は複数の暗号法一式)を含む。通常は、これらの一式は、鍵再生成の時点においては変更されない。(例えば、暗号法一式の単一セットの場合に)SAペイロードの最小サイズは、通常、52バイトである。IKE鍵再生成の場合には、最小の可能なサイズは、44バイトである。この最小の可能なサイズは、44バイトのSAペイロードサイズ及び40バイトの提案サイズを含んでもよい。その最小値は、選択されそしてSAペイロードの中で送信される暗号法一式のタイプ及び数によって決定される。
SAペイロード構造は、通常、SAペイロード、提案、及び、変換及び属性を含む。SAペイロードの内側には、プロトコルID及びSPIを含む1つ又は1つよりも多くの提案ペイロードが存在し、提案ペイロードの内側には、暗号アルゴリズムを含む変換及び選択的に鍵の長さを含む属性が存在するであろう。例えば、複数の属性を指定することによって、さらにある特定の提案を定義すると、SAペイロードのサイズを増加させるであろう。当業者は、従来のSAペイロードがRFC7296の3.3節において詳細に開示されているということを理解するであろう。
例えば、要求側とレスポンダとの間のIPSec鍵再生成のやりとりは、また、暗号法一式(例えば、単一の又は複数の暗号法一式)を含むSAペイロード及びそれらとともに(TSiペイロード及びTSrペイロード等の)TSペイロードを搬送する。ほとんどの場合に、これらのペイロードは、IKE鍵再生成手順と同様に、鍵再生成の時点においては変更されない。通常、SAペイロードの最小サイズは、40バイトであり、各々のTSサイズは、24バイト(2*24=48バイト)である。
図1Aは、従来のSAペイロードの構造の複数の例のうちのいくつかを提供する。最初のSAペイロードは、属性を含まず、2番目のSAペイロードは、属性を含み、それらの2つのSAペイロードの各々は、1つの提案を含む。3番目のSAペイロードは、各々が属性を含む2つの提案を含む。
ペイロードサイズは、IKE及び/又はIPSec SAの鍵再生成を実行する際に、複数の暗号法一式に対して比例的に増加する。この鍵再生成は、周期的にトリガされる。各々の鍵再生成は、帯域幅及び電力を消費して、これらのペイロードを処理する。
セキュリティアソシエーションの鍵再生成のための方法、デバイス、及びシステムに関連する概念を紹介するためにこの要約を提供する。さらに、既知のSA鍵再生成プロセスにおいて交換される既存のタイプのメッセージを変更する。さらに、SA鍵再生成プロセスのための新たなメッセージを導入する。この開示は、IKEv2を参照して議論されるが、他の鍵再生成メカニズムにも等しく本発明を適用することが可能であるというということが理解されるであろう。
第1の態様によれば、この出願のある1つの実施形態は、第1のネットワークデバイス及び第2のネットワークデバイスを含むネットワークシステムにおいてセキュリティアソシエーション(SA)の鍵再生成を実行するための方法であって、前記第1のネットワークデバイスと前記第2のネットワークデバイスとの間に、インターネット鍵交換(IKE)トンネル及びインターネットプロトコルセキュリティ(IPSec)トンネルが確立される、方法を提供する。当該方法において、前記第1のネットワークデバイスは、前記第1のネットワークデバイスと関連する暗号法一式に変更があるか否かを決定し、そして、その決定の結果が、前記第1のネットワークデバイスと関連する前記暗号法一式に変更がないということであるときに、前記第2のネットワークデバイスに、SAの鍵再生成を実行するための第1の鍵再生成要求を送信する。前記第1の鍵再生成要求は、第1のセキュリティパラメータインデックス(SPI)を搬送し、前記第1のネットワークデバイスと関連する暗号法一式を搬送しない。その次に、前記第1のネットワークデバイスは、前記第1のネットワークデバイスと関連する前記暗号法一式及び前記第2のネットワークデバイスと関連する前記暗号法一式に変更がないときに、前記第1のSPI及び前記第2のSPIにしたがって、前記SAの鍵再生成を実行する。具体的には、前記第1のネットワークデバイスは、前記第1のSPI、前記第2のSPI、及び鍵再生成を実行するべき前記SAのために使用される前記暗号法一式にしたがって、前記SAの鍵再生成を実行する。
上記の技術的解決方法においては、鍵再生成要求及び鍵再生成応答の中で暗号法一式を搬送しないことによって、鍵再生成の場合にペイロードのサイズを減少させることにより、例えば、IKE SA鍵再生成又はIPSec SA鍵再生成のうちのいずれについても、SA鍵再生成の過程において、帯域幅、より多くの処理時間、及び電力を節約する。
第1の態様に関して、第1の可能な実装において、前記SAが前記IKE SAのチャイルドSAである前記IPSec SAである場合に、前記第1のネットワークデバイスと関連するフロー情報に変更があるときは、前記第1の鍵再生成要求は、前記第1のネットワークデバイスと関連するフロー情報を搬送するTSペイロードを搬送しない。前記第2のネットワークデバイスと関連するフロー情報に変更がないときは、前記第1の鍵再生成応答は、前記第2のネットワークデバイスと関連するフロー情報を搬送するTSペイロードを搬送しない。したがって、第1のネットワークデバイスは、第1のネットワークデバイスと関連するフロー情報及び第2のネットワークデバイスと関連するフロー情報を変更することなく、SAの鍵再生成を実行する。
上記のIPSEC鍵再生成のシナリオにおいては、鍵再生成要求及び鍵再生成応答の中でTSペイロード(TSiペイロード及びTSrペイロード)を搬送しないことによって、さらに、ペイロードを減少させる。IPSEC SAにおける複数の暗号法一式について、ペイロードサイズを比例的に減少させるであろう。軽量ペイロードは、さらに、IPSec鍵再生成の際に、帯域幅、処理時間、及び電力を節約することが可能である。
第1の態様に関して、第2の可能な実装において、前記SAが前記IKE SAであり、前記第1の鍵再生成要求が、前記IKE SAの鍵再生成を実行するためのCREATE_CHILD_SA要求であり、前記CREATE_CHILD_SA要求が、前記第1のSPIを搬送するNEW_SPI通知ペイロードを搬送するか、又は、前記第1のSPIを搬送するLightweight SAペイロードを搬送し、そして、前記第1の鍵再生成応答が、前記IKE SAの鍵再生成を実行するためのCREATE_CHILD_SA応答であるときに、前記CREATE_CHILD_SA応答は、前記第2のSPIを搬送する他のNEW_SPI通知ペイロードを搬送するか、又は、前記第2のSPIを搬送する他のLightweight SAペイロードを搬送する。したがって、前記SAが、前記IKE SAのチャイルドSAである前記IPSec SAであり、前記第1の鍵再生成要求が、チャイルドSAの鍵再生成を実行するためのCREATE_CHILD_SA要求であり、前記CREATE_CHILD_SA要求が、前記第1のSPIを搬送するNEW_SPI通知ペイロードを搬送するか、又は、前記第1のSPIを搬送するLightweight SAペイロードを搬送し、そして、前記第1の鍵再生成応答が、前記チャイルドSAの鍵再生成を実行するためのCREATE_CHILD_SA応答であるときに、前記CREATE_CHILD_SA応答は、前記第2のSPIを搬送する前記NEW_SPI通知ペイロードを搬送するか、又は、前記第2のSPIを搬送する他のLightweight SAペイロードを搬送する。
この実施形態において説明されている軽量鍵再生成アプローチを使用することによって、このNEW_SPI通知ペイロード又はLightweight SAペイロードは、例えば、最低36バイトを節約することが可能であり、複数の暗号法一式において、節約されるバイトの数を比例的に増加させ、このことは、複雑な検証の処理を減少させ、したがって、IKE鍵再生成又はIPSec鍵再生成のやりとりにおけるSAペイロードの処理を減少させる。例えば、NEW_SPI通知ペイロードのサイズは、12乃至16バイトの範囲にあってもよい。
第2の態様によれば、この出願のある1つの実施形態は、第1のネットワークデバイス及び第2のネットワークデバイスを含むネットワークシステムに適用されるセキュリティアソシエーション(SA)の鍵再生成を実行するための方法であって、前記第2のネットワークデバイスと第1のネットワークデバイスとの間に、インターネット鍵交換(IKE)及びインターネットプロトコルセキュリティ(IPSec)トンネルが確立される方法を提供する。当該方法において、前記第2のネットワークデバイスは、前記第1のネットワークデバイスから、SAの鍵再生成を実行するための第1の鍵再生成要求を受信する。前記第1の鍵再生成要求は、第1のセキュリティパラメータインデックス(SPI)を搬送し、第1のネットワークデバイスと関連する暗号法一式を搬送しない。前記第2のネットワークデバイスは、前記第2のネットワークデバイスと関連する暗号法一式に変更があるか否かを決定する。前記第2のネットワークが、前記第2のネットワークデバイスと関連する前記暗号構成に変更がないということを決定するときに、前記第2のネットワークデバイスは、前記第2のネットワークデバイスと関連する暗号法一式を搬送することなく、第2のSPIを搬送する第1の鍵再生成応答を送信する。そして、前記第1のSPI及び前記第2のSPIにしたがって、前記SAの鍵再生成を実行する。
上記の技術的解決方法においては、鍵再生成要求及び鍵再生成応答の中で暗号法一式を搬送しないことによって、鍵再生成の場合にペイロードのサイズを減少させることにより、例えば、IKE SA鍵再生成又はIPSec SA鍵再生成のうちのいずれについても、SA鍵再生成の過程において、帯域幅、より多くの処理時間、及び電力を節約する。
第2の態様に関して、第1の可能な実装において、前記SAがIKE SAのチャイルドSAである前記IPSec SAである場合に、前記第1のネットワークデバイスと関連するフロー情報に変更があるときは、前記第1の鍵再生成要求は、前記第1のネットワークデバイスと関連するフロー情報を搬送するTSペイロードを搬送しない。前記第2のネットワークデバイスと関連するフロー情報に変更がないときは、前記第1の鍵再生成応答は、前記第2のネットワークデバイスと関連するフロー情報を搬送するTSペイロードを搬送しない。したがって、第1のネットワークデバイスと関連するフロー情報及び第2のネットワークデバイスと関連するフロー情報を変更することにより、SAの鍵再生成を実行する。
上記のIPSEC鍵再生成のシナリオにおいては、鍵再生成要求及び鍵再生成応答の中でTSペイロード(TSiペイロード及びTSrペイロード)を搬送しないことによって、さらに、ペイロードを減少させる。IPSEC SAにおける複数の暗号法一式について、ペイロードサイズを比例的に減少させるであろう。軽量ペイロードは、さらに、IPSec鍵再生成の際に、帯域幅、処理時間、及び電力を節約することが可能である。
第3の態様によれば、この出願のある1つの実施形態は、第1のネットワークデバイス及び第2のネットワークデバイスを含むネットワークシステムにおいてセキュリティアソシエーション(SA)の鍵再生成を実行するためのネットワークデバイスを提供する。前記第1のネットワークデバイスと前記第2のネットワークデバイスとの間に、インターネット鍵交換(IKE)及びインターネットプロトコルセキュリティ(IPSec)トンネルが確立され、当該ネットワークデバイスは、前記第1のネットワークデバイスとして構成される。当該ネットワークデバイスは、決定モジュール、送信モジュール、受信モジュール、及び鍵再生成モジュールを含む。前記決定モジュールは、前記第1のネットワークデバイスと関連する暗号法一式に変更があるか否かを決定するように構成される。前記送信モジュールは、前記第1のネットワークデバイスと関連する前記暗号法一式に変更がないときに、前記第2のネットワークデバイスに、SAの鍵再生成を実行するための第1の鍵再生成要求を送信するように構成され、前記第1の鍵再生成要求は、第1のセキュリティパラメータインデックス(SPI)を搬送し、前記第1のネットワークデバイスと関連する暗号法一式を搬送しない。前記受信モジュールは、前記第2のネットワークデバイスから第1の鍵再生成応答を受信するように構成される。前記第2のネットワークデバイスと関連する暗号法一式に変更がないときに、前記第1の鍵再生成応答は、第2のSPIを搬送し、前記第2のネットワークデバイスと関連する暗号法一式を搬送しない。鍵再生成モジュールは、前記第1のネットワークデバイスと関連する前記暗号法一式及び前記第2のネットワークデバイスと関連する前記暗号法一式に変更がないときに、前記第1のSPI及び前記第2のSPIにしたがって、前記SAの鍵再生成を実行するように構成される。
上記の技術的解決方法においては、鍵再生成要求及び鍵再生成応答の中で暗号法一式を搬送しないことによって、鍵再生成の場合にペイロードのサイズを減少させることにより、例えば、IKE SA鍵再生成又はIPSec SA鍵再生成のうちのいずれについても、SA鍵再生成の過程において、帯域幅、より多くの処理時間、及び電力を節約する。IKE鍵再生成のシナリオ及びIPSEC SA鍵再生成のシナリオの双方における鍵再生成の際に、複数の暗号法一式の場合に、ペイロードサイズを比例的に減少させるであろう。
第4の態様によれば、この出願のある1つの実施形態は、第1のネットワークデバイス及び第2のネットワークデバイスを含むネットワークシステムにおいてセキュリティアソシエーション(SA)の鍵再生成を実行するためのネットワークデバイスを提供する。前記第1のネットワークデバイスと前記第2のネットワークデバイスとの間に、インターネット鍵交換(IKE)及びインターネットプロトコルセキュリティ(IPSec)トンネルが確立され、当該ネットワークデバイスは、前記第2のネットワークデバイスとして構成される。当該ネットワークデバイスは、受信モジュール、決定モジュール、及び送信モジュールを含む。前記受信モジュールは、前記第1のネットワークデバイスから、SAの鍵再生成を実行するための第1の鍵再生成要求を受信するように構成される。前記第1の鍵再生成要求は、第1のセキュリティパラメータインデックス(SPI)を搬送し、前記第1のネットワークデバイスと関連する暗号法一式を搬送しない。前記決定モジュールは、前記第2のネットワークデバイスと関連する暗号法一式に変更があるか否かを決定するように構成される。前記送信モジュールは、前記第1のネットワークデバイスに、第1の鍵再生成応答を送信するように構成される。前記第2のネットワークデバイスと関連する前記暗号構成に変更がないときに、前記第1の鍵再生成応答は、第2のSPIを搬送し、前記第2のネットワークデバイスと関連する暗号法一式を搬送しない。前記SAの鍵再生成は、前記第1のSPI及び前記第2のSPIにしたがって実行される。
上記の技術的解決方法においては、鍵再生成要求及び鍵再生成応答の中で暗号法一式を搬送しないことによって、鍵再生成の場合にペイロードのサイズを減少させることにより、例えば、IKE SA鍵再生成又はIPSec SA鍵再生成のうちのいずれについても、SA鍵再生成の過程において、帯域幅、より多くの処理時間、及び電力を節約する。IKE鍵再生成のシナリオ及びIPSEC SA鍵再生成のシナリオの双方における鍵再生成の際に、複数の暗号法一式の場合に、ペイロードサイズを比例的に減少させるであろう。
第5の態様によれば、この出願のある1つの実施形態は、セキュリティアソシエーション(SA)の鍵再生成を実行するためのネットワークシステムを提供し、当該ネットワークシステムは、上記で説明されているように、この出願の第3の態様にしたがった第1のネットワークデバイス及びこの出願の第4の態様にしたがった第2のネットワークデバイスを含む。
上記の技術的解決方法においては、鍵再生成要求及び鍵再生成応答の中で暗号法一式を搬送しないことによって、鍵再生成の場合にペイロードのサイズを減少させることにより、例えば、IKE SA鍵再生成又はIPSec SA鍵再生成のうちのいずれについても、SA鍵再生成の過程において、帯域幅、より多くの処理時間、及び電力を節約する。IKE鍵再生成のシナリオ及びIPSEC SA鍵再生成のシナリオの双方における鍵再生成の際に、複数の暗号法一式の場合に、ペイロードサイズを比例的に減少させるであろう。
第6の態様によれば、この出願のある1つの実施形態は、第1のネットワークデバイス及び第2のネットワークデバイスを含むネットワークシステムにおいてセキュリティアソシエーション(SA)の鍵再生成を実行するためのネットワークデバイスを提供する。前記第1のネットワークデバイスと前記第2のネットワークデバイスとの間に、インターネット鍵交換(IKE)及びインターネットプロトコルセキュリティ(IPSec)トンネルが確立され、当該ネットワークデバイスは、前記第1のネットワークデバイスとして構成される。当該ネットワークデバイスは、プロセッサ及びメモリを含む。前記メモリは、ソフトウェアの命令を格納するように構成される。前記プロセッサは、前記メモリの中のソフトウェアの前記命令を実行して、当該ネットワークデバイスが、前記第1のネットワークデバイスと関連する暗号法一式に変更があるか否かを決定し、前記第1のネットワークデバイスと関連する前記暗号法一式に変更がないときに、前記第2のネットワークデバイスに、SAの鍵再生成を実行するための第1の鍵再生成要求を送信し、前記第1の鍵再生成要求は、第1のセキュリティパラメータインデックス(SPI)を搬送し、前記第1のネットワークデバイスと関連する暗号法一式を搬送せず、前記第2のネットワークデバイスと関連する暗号法一式に変更がないときに、前記第2のネットワークデバイスと関連する暗号法一式を搬送せずに、第2のSPIを搬送する第1の鍵再生成応答を受信し、前記第1のネットワークデバイスと関連する前記暗号法一式及び前記第2のネットワークデバイスと関連する前記暗号法一式に変更がないときに、前記第1のSPI及び前記第2のSPIにしたがって、前記SAの鍵再生成を実行する、ように構成される。
上記の技術的解決方法においては、鍵再生成要求及び鍵再生成応答の中で暗号法一式を搬送しないことによって、鍵再生成の場合にペイロードのサイズを減少させることにより、例えば、IKE SA鍵再生成又はIPSec SA鍵再生成のうちのいずれについても、SA鍵再生成の過程において、帯域幅、より多くの処理時間、及び電力を節約する。IKE鍵再生成のシナリオ及びIPSEC SA鍵再生成のシナリオの双方における鍵再生成の際に、複数の暗号法一式の場合に、ペイロードサイズを比例的に減少させるであろう。
第7の態様によれば、この出願のある1つの実施形態は、第1のネットワークデバイス及び第2のネットワークデバイスを含むネットワークシステムにおいてセキュリティアソシエーション(SA)の鍵再生成を実行するためのネットワークデバイスを提供する。前記第1のネットワークデバイスと前記第2のネットワークデバイスとの間に、インターネット鍵交換(IKE)及びインターネットプロトコルセキュリティ(IPSec)トンネルが確立され、当該ネットワークデバイスは、前記第2のネットワークデバイスとして構成される。当該ネットワークデバイスは、プロセッサ及びメモリを含む。前記メモリは、ソフトウェアの命令を格納するように構成される。前記プロセッサは、前記メモリの中のソフトウェアの前記命令を実行して、当該ネットワークデバイスが、前記第1のネットワークデバイスから、SAの鍵再生成を実行するための第1の鍵再生成要求を受信し、前記第1の鍵再生成要求は、第1のセキュリティパラメータインデックス(SPI)を搬送し、前記第1のネットワークデバイスと関連する暗号法一式を搬送せず、前記第2のネットワークデバイスと関連する暗号法一式に変更があるか否かを決定し、前記第1のネットワークデバイスに、第1の鍵再生成応答を送信し、前記第2のネットワークデバイスと関連する前記暗号構成に変更がないときに、前記第1の鍵再生成応答は、第2のSPIを搬送し、前記第2のネットワークデバイスと関連する暗号法一式を搬送しない、ように構成される。前記SAの鍵再生成は、前記第1のSPI及び前記第2のSPIにしたがって実行される。
上記の技術的解決方法においては、鍵再生成要求及び鍵再生成応答の中で暗号法一式を搬送しないことによって、鍵再生成の場合にペイロードのサイズを減少させることにより、例えば、IKE SA鍵再生成又はIPSec SA鍵再生成のうちのいずれについても、SA鍵再生成の過程において、帯域幅、より多くの処理時間、及び電力を節約する。IKE鍵再生成のシナリオ及びIPSEC SA鍵再生成のシナリオの双方における鍵再生成の際に、複数の暗号法一式の場合に、ペイロードサイズを比例的に減少させるであろう。
第8の態様によれば、この出願のある1つの実施形態は、セキュリティアソシエーション(SA)の鍵再生成を実行するためのネットワークシステムを提供し、当該ネットワークシステムは、上記で説明されているように、この出願の第6の態様にしたがった第1のネットワークデバイス及びこの出願の第7の態様にしたがった第2のネットワークデバイスを含む。
上記の技術的解決方法においては、鍵再生成要求及び鍵再生成応答の中で暗号法一式を搬送しないことによって、鍵再生成の場合にペイロードのサイズを減少させることにより、例えば、IKE SA鍵再生成又はIPSec SA鍵再生成のうちのいずれについても、SA鍵再生成の過程において、帯域幅、より多くの処理時間、及び電力を節約する。IKE鍵再生成のシナリオ及びIPSEC SA鍵再生成のシナリオの双方における鍵再生成の際に、複数の暗号法一式の場合に、ペイロードサイズを比例的に減少させるであろう。
第9の態様によれば、この出願のある1つの実施形態は、コンピュータ読み取り可能な記憶媒体を提供する。そのコンピュータ読み取り可能な記憶媒体は、上記で説明されているように、第1の態様又は第2の態様にしたがった方法を実行するのに使用されるコンピュータソフトウェア命令を格納するように構成される。
上記の技術的解決方法においては、鍵再生成要求及び鍵再生成応答の中で暗号法一式を搬送しないことによって、鍵再生成の場合にペイロードのサイズを減少させることにより、例えば、IKE SA鍵再生成又はIPSec SA鍵再生成のうちのいずれについても、SA鍵再生成の過程において、帯域幅、より多くの処理時間、及び電力を節約する。IKE鍵再生成のシナリオ及びIPSEC SA鍵再生成のシナリオの双方における鍵再生成の際に、複数の暗号法一式の場合に、ペイロードサイズを比例的に減少させるであろう。
本開示の他の複数の態様及び特徴は、複数の添付の図面と共に本発明の複数の特定の実施形態の以下の説明を検討することにより、当業者には明らかとなるであろう。
複数の添付の図面を参照して、詳細な説明を記載する。それらの複数の図面においては、参照番号のうちの左端の1つ又は複数の数字は、その参照番号が最初に現れる図を特定している。複数の同様の特徴及び構成要素を指すために、それらの複数の図面を通じて、同じ番号を使用する。
従来技術にしたがった複数のSAペイロードのうちのいくつかの構成を図示している。
従来技術にしたがったIKE SA鍵再生成のフローチャートを図示している。
削除要求の構成のある1つの例を図示している。
従来技術にしたがったIPSec SA鍵再生成を図示している。
本開示の複数の実施形態にしたがったイニシエータとレスポンダとの間での軽量鍵再生成のサポートについての交渉のフローチャートを図示している。
通知ペイロードの構成のある1つの例を図示している。
本開示の複数の実施形態にしたがったイニシエータとレスポンダとの間での軽量鍵再生成のサポートについての交渉の他のフローチャートを図示している。
本開示の複数の実施形態にしたがったイニシエータとレスポンダとの間での軽量鍵再生成のサポートについての交渉のさらに別のフローチャートを図示している。
本開示のある1つの実施形態にしたがった軽量鍵再生成アプローチを使用するSAの鍵再生成のフローチャートを図示している。
本開示のある1つの実施形態にしたがった軽量鍵再生成アプローチを使用するIKE SAの鍵再生成のフローチャートを図示している。
IKE SA鍵再生成要求パケットのフォーマットのある1つの例を図示している。
IKEのためのNEW_SPIペイロードのある1つの例を図示している。
IKEのためのLightweight SAペイロードのある1つの例を図示している。
提案非選択通知ペイロードの構成のある1つの例を図示している。
本開示のある1つの実施形態にしたがったある1つの特定のシナリオにおけるIKE SAの鍵再生成のフローチャートを図示している。
本開示の他の実施形態にしたがった軽量鍵再生成アプローチを使用するIKE SAの鍵再生成の他のフローチャートを図示している。
本開示のある1つの実施形態にしたがった軽量鍵再生成アプローチを使用するIPSec SAの鍵再生成のフローチャートを図示している。
IPSec SA鍵再生成要求パケットのフォーマットのある1つの例を図示している。
AHのためのNEW_SPIペイロードのある1つの例を図示している。
IPSec SAのための新たに定義されたペイロードであるLightweight SAの2つの例を図示している。
本開示のある1つの実施形態にしたがったある1つの特定のシナリオにおけるIPSec SAの鍵再生成のフローチャートを図示している。
本開示の他の実施形態にしたがった軽量鍵再生成アプローチを使用するIPSec SAの鍵再生成の他のフローチャートを図示している。
本開示のある1つの実施形態にしたがったSAの鍵再生成を実行するためのイニシエータとして動作するネットワークデバイスの概略的な図を図示している。
本開示のある1つの実施形態にしたがったSAの鍵再生成を実行するためのレスポンダとして動作するネットワークデバイスの概略的な図を図示している。
本開示の他の実施形態にしたがったSAの鍵再生成を実行するためのレスポンダとして動作するネットワークデバイスの概略的な図を図示している。
本開示の複数の実施形態にしたがったSAの鍵再生成を実行するためのイニシエータ又はレスポンダとして動作するネットワークデバイスの概略的な図を図示している。
本開示の複数の実施形態にしたがったSAの鍵再生成を実行するためのネットワークシステムの概略的な図を図示している。
本発明は、プロセス、装置、システム、コンピュータ読み取り可能な記憶媒体等のコンピュータ読み取り可能な媒体、又はコンピュータネットワーク等の数多くの方法によって実装されてもよく、プログラム命令は、例えば、光通信リンク又は電子的な通信リンク等のさまざまなタイプの通信リンクを介して送信される。本明細書における説明においては、これらの複数の実装又は本発明が採用することが可能であるいずれかの他の形態は、技術と称されてもよい。一般的に、開示されている複数のプロセスの複数のステップの順序は、本発明の範囲内で変更されてもよい。
本発明の1つ又は複数の実施形態の詳細な説明は、本発明の複数の原理を説明している複数の添付の図面と共に以下で提供される。本発明は、そのような複数の実施形態と関連して説明されるが、本発明は、いずれかの実施形態に限定されるものではない。本発明の範囲は、特許請求の範囲によってのみ限定され、本発明は、数多くの代替的なもの、修正されたもの、及び等価なものを包含する。本発明の完全な理解を提供するために、数多くの具体的な詳細が以下の説明に記載される。これらの詳細は、例示の目的で提供され、本発明は、これらの具体的な詳細のうちの一部又はすべてを使用することなく、請求項の記載にしたがって実施されてもよい。明確さの目的で、本発明に関連する技術の分野において知られている技術的な内容は、発明が必要以上に不明瞭にならないように、詳細には説明されていない。
以下の詳細な説明においては、本発明の完全な理解を提供するために、数多くの具体的な詳細が説明される。一方で、当業者は、本開示が、これらの具体的な詳細を使用することなく実施されてもよいということを理解するであろう。他の例では、よく知られている方法、手順、及び構成要素、モジュール、ユニット、及び/又は回路は、本発明を不明瞭にしないように詳細には説明されていない。
本発明の複数の実施形態は、この点に関して限定されないが、例えば、"処理すること"、"算出すること"、"決定すること"、"確立すること"、"作成すること"、又は"検査すること"等の語を使用する説明は、コンピュータのレジスタ及び/又はメモリの中の物理的な(例えば、電子的な)量として表されるデータを、コンピュータのレジスタ及び/又はメモリ或いは命令を格納することが可能である他の情報非一時記憶媒体の中の物理的な量として同様に表される他のデータへと処理し及び/又は変換して、操作及び/又はプロセスを実行するコンピュータ、コンピューティングプラットフォーム、コンピューティングシステム、又は他の電子的なコンピューティングデバイスの1つ又は複数の動作及び/又は1つ又は複数のプロセスを指してもよい。
図1に示されているように、鍵再生成フローチャートは、IKE及びIPSEC SAが(例えば、要求側又はイニシエータと呼ばれることがある)第1のネットワークデバイスと(例えば、レスポンダ等の)第2のネットワークデバイスとの間で確立された後に生起する。
本開示の複数の実施形態においては、第1のネットワークデバイス又は第2のネットワークデバイスは、コンピュータ、モバイルデバイス(例えば、携帯電話)、リモート健康モニタリングデバイス、ゲートウェイ、ルータ、サーバ、及びアクセスポイント(AP)デバイスが埋め込まれているセンサ、IPスタックを有するホームデバイス又はパーソナルデバイスのグループのうちのいずれか1つを含んでもよい。特に、それらの複数のネットワークデバイスのうちの1つは、制限された電源、処理能力、又は帯域幅能力を有するデバイスであってもよい。そのような場合には、ペイロードのサイズ及び/又は数を全体的に減少させて、処理電力、時間、そして、ひいては電力消費を節約することが可能であるので、本発明は、特に利点がある。
また、本開示のそれらの複数の実施形態において、ネットワークデバイスのうちの他方のネットワークデバイスは、多数のIKEトンネル/IPSecトンネルをサポートすることが可能であるセキュリティゲートウェイ/ePDG又はCRAN/クラウドベースのデバイスであってもよい。そのような場合に、伝送されるデータを減少させることによって、帯域幅及びパケットフラグメンテーション、及び、その結果としての処理要件を減少させることが可能である。
IKE_SA_INIT交換及びIKE_AUTH交換を含む初期交換(操作102乃至108)を実行した後に、IKE SA及びIPSec SAを確立する(操作110)。これらの初期交換は、通常は、4つのメッセージを含むが、複数のシナリオのうちのいくつかにおいては、その数を増加させてもよい。メッセージの第1の対(IKE_SA_INIT)は、暗号法一式を交渉し、ナンスを交換し、そして、Diffie-Hellman(DH)を実行する。メッセージの第2の対(IKE_AUTH)は、以前のメッセージを認証し、識別情報及び証明書を交換し、暗号法一式及びTraffic Selector(TS)を交渉し、そして、第1のChild SAを確立する。これらのメッセージの部分は、IKE_SA_INIT交換によって確立されている鍵によって、暗号化されるとともに完全性保護される。初期交換の後に続く複数のメッセージは、IKE_SA_INIT交換の中で交渉されてる暗号アルゴリズム及び鍵を使用して、暗号法によって保護される。IKE SA及びIPSec SAの各々について、秘密鍵は、通常は、制限された時間の中で使用され、その制限された時間は、SAの存続期間と呼ばれる場合がある。その存続期間が満了するときに、新たなSAを作成し、そして、その古いSAを削除することにより、そのSAの鍵再生成が実行される。初期交換の詳細な手順については、当業者は、本明細書の中の明示的な開示に反する場合を除き、本明細書に完全に記載されているかのように、すべての目的のために、参照によって組み込まれているRFC7296を参照する。
IKE SA及びIPSec SAを確立した(操作110)後に、IKE SA及びIPSec SAの存続期間のうちのいずれか一方が満了しつつある場合に、第1のネットワークデバイス及び第2のネットワークデバイスがSA鍵再生成手順を実行する。
それらのデバイスの各々は、自身の側で、SAの存続期間を管理する存続期間ポリシーを維持することが可能であるため、第1のネットワークデバイス又は第2のネットワークデバイスのうちのいずれもが、SA鍵再生成要求を開始することが可能であるということを理解すべきである。他の実施形態においては、双方の側は、それらのデバイスが共有しているSAについて同じ存続期間を有してもよい。第1のネットワークデバイス又は第2のネットワークデバイスは、周期的に、SA鍵再生成をトリガしてもよい。他のシナリオにおいては、デバイスは、そのデバイスと関連する各々のSAの将来的な満了を検出し、そして、その次に、そのデバイスがIKE SA又はIPSEC SAの秘密鍵が満了しつつあるということを検出する場合に、SA鍵再生成プロセスを開始してもよい。
名前が示唆しているように、SA鍵再生成は、そのポリシーを変更しない場合に、現在のSAと同じSA属性を有する新たな鍵を使用するSAを作成することを指す。ポリシーの変更は、例えば、エンドユーザが、(また、暗号法一式と称されてもよい)暗号法ポリシーを変更する、及び/又は、それらの1つ又は複数の暗号法一式の存続期間を変更するとき、或いは、チャイルドSAの鍵再生成の場合に、(また、フロー情報と称されてもよい)フローポリシーを変更するとき、であってもよい。フロー情報は、例えば、送信元IPアドレス及び宛先IPアドレス、ポート範囲又はポート番号を含んでもよい。SAの鍵再生成を実行することは、SAのための鍵を再生成する、すなわち、鍵が変更され、確立されたSAの他の要素が変更されてもよく又は変更されなくてもよい、ということを含む。
IKE SAの鍵再生成を開始する第1のネットワークデバイスを例にとってみる。その第1のネットワークデバイスは、第2のネットワークデバイスに、IKE SAの鍵再生成を実行するための鍵再生成要求を送信する。ある1つの実施形態において、CREATE_CHILD_SA交換は、IKE SAの鍵再生成を実行するのに使用される。この交換は、要求/応答の対を含む。その交換は、初期交換が完了した後に、IKE SAのうちの(例えば、第1のネットワークデバイス又は第2のネットワークデバイス等の)いずれの端によって開始されてもよい。SA鍵再生成を開始する端は、イニシエータと考えられてもよく、そのイニシエータのピアサイドは、レスポンダと考えられてもよい。
ある1つの実施形態によれば、IKE SAの鍵再生成を実行することは、少なくとも以下の操作を含んでもよい。
操作112, イニシエータは、レスポンダに、IKE SAの鍵再生成を実行するためのCREATE_CHILD_SA要求を送信する。
CREATE_CHILD_SA要求は、複数のペイロード及び(ペイロードではない)IKEヘッダーであるHDRを含む。ペイロードは、SAペイロード、Niペイロード、及びKEiペイロードを含む。SAペイロードは、例えば、イニシエータがサポートする1つ又は複数の暗号法一式等のSAオファーを含む。それらの暗号法一式は、認証アルゴリズム、暗号化アルゴリズム、及び/又は鍵算出のためのDHグループを含んでもよい。さらに、SAペイロードは、また、SAペイロードのSPIフィールドの中で供給される新たなイニシエータのセキュリティパラメータインデックス(SPI)を含んでもよい。SAペイロードの中の新たなイニシエータSPIは、レスポンダによって取得され、新たな鍵は、レスポンダ側で算出される。Niペイロードは、ナンスを含み、KEiペイロードは、Diffie-Hellman値を含む。本開示において、"暗号法一式"の語は、SAを保護するのに使用されるアルゴリズムのセットを指す。IPSEC SA又はIKE SAの状況によっては、暗号法一式は、また、ある特定の状況では、IPSec提案又はIKE提案と称されてもよい。新たなイニシエータSPIは、イニシエータ側での鍵再生成の後に、新たなIKE SAを識別するのに使用されてもよい。
操作114, レスポンダが、IKE SAの鍵再生成を実行するための要求を受信すると、レスポンダは、イニシエータに、IKE SAの鍵再生成を実行するためのCREATE_CHILD_SA応答を送信する。
CREATE_CHILD_SA応答は、HDR及びペイロードを含み、ペイロードは、SAペイロード、Nrペイロード、及びKErペイロードを含む。SAペイロードは、SAペイロードのSPIフィールドの中に新たなレスポンダSPIを含む。SAペイロードは、また、イニシエータの提示からレスポンダが選択する暗号法一式を含む。Nrペイロードは、ナンスを含み、選択された暗号法一式がそのグループを含む場合には、KErペイロードは、Diffie-Hellman値を含む。新たなレスポンダSPIは、レスポンダ側での鍵再生成の後に、新たなIKE SAを識別するのに使用されてもよい。このように、新たなレスポンダSPI及び新たなイニシエータSPIの組み合わせは、新たなIKE SAを識別するのに使用される。加えて、SAペイロードの中の新たなレスポンダSPIは、イニシエータによって取得され、新たな鍵は、イニシエータ側で算出される。
操作116, 新たなIKE SAが確立される。その新たなIKE SAは、IKE制御パケットを保護するのに使用される。
新たなIKE SA、すなわち、鍵再生成が実行されたIKE SAは、そのIKE SAのチャイルドSAのすべてを引き継ぎ、このことは、古いIKE SAとリンクされている既存のチャイルドSAは、鍵再生成が成功した後に新たなIKE SAに移動されるということを意味する。
操作112及び114に示されているIKE CREATE_CHILD_SAの交換の後に、新たなIKE SAは、新たな鍵及び選択された暗号法一式を使用して生成され、上記で説明されているSAペイロードの中で交換される新たなイニシエータSPI及び新たなレスポンダSPIを使用して識別される。
操作118, イニシエータは、レスポンダに、古いSAを削除するための古いIKE SAの削除の要求を送信する。
古いIKEの削除の要求は、HDR及びDペイロードを含んでもよい。Dペイロードは、削除されるSAを示すプロトコル識別子(ID)等の情報を含んでもよい。SAの削除は、RFC7296にしたがって、イニシエータとレスポンダとの間のINFORMATIONAL交換を通じて実装されてもよい。ある1つの例として、図1Cは、RFC7296にしたがった削除要求の構成のある1つの例を図示している。
操作120, 古いIKE SAの削除の要求を受信すると、レスポンダは、イニシエータに、古いIKE SAの削除の応答を送信する。
古いIKE SAの削除の応答は、HDR及びDペイロードを含んでもよい。Dペイロードは、削除されるSAを示すプロトコルID等の情報を含んでもよい。SAの削除は、RFC7296にしたがって、イニシエータとレスポンダとの間のINFORMATIONAL交換を通じて実装されてもよい。
図2を参照して、図2は、第1のネットワークデバイスが、チャイルドSA鍵再生成又はIPSec SA鍵再生成を開始するある1つの実施形態を提供する。IKE SAの鍵再生成と同じように、CREATE_CHILD_SAの交換は、また、チャイルドSAの鍵再生成を実行するのに使用されてもよい。
その実施形態によれば、IKE SAの鍵再生成を実行することは、少なくとも以下の操作を含んでもよい。
操作202乃至210は、操作102乃至110を参照することが可能である。
操作212, イニシエータは、レスポンダに、チャイルドSAの鍵再生成を実行するためのCREATE_CHILD_SA要求を送信する。
CREATE_CHILD_SA要求は、IKEヘッダーであるHDR及びペイロードを含む。ペイロードは、N個の(REKEY_SA)ペイロード、SAペイロード、Niペイロード、TSi及びTSrペイロード、及び選択的なKEiペイロードを含む。
RFC7296の中で定義されているREKEY_SAペイロードは、既存のチャイルドSAのために鍵再生成が生起しているということを他のピアに通知するのに使用される。鍵再生成を実行されている既存のチャイルドSAのSPIは、REKEY_SAペイロードのSPIフィールドの中に追加され、レスポンダは、含まれているSPIを使用してSAを識別することが可能である。さらに、REKEY_SAペイロードのプロトコルIDフィールドは、鍵再生成を実行されるSAのプロトコルと一致するように、例えば、ESPの場合は3に、AHの場合は2に設定される。
SAペイロードは、例えば、イニシエータがサポートする1つ又は複数の暗号法一式等のSAの提示を含む。SAペイロードは、また、そのSAペイロードのSPIフィールドの中に供給されている新たなイニシエータSPIを含んでもよい。
新たなイニシエータSPIは、鍵再生成の後に、新たなIPSec SAのためのイニシエータの中でインバウンドSPIとして使用され、鍵再生成の後に、新たなIPSec SAのためのレスポンダの中でアウトバウンドSPIとして使用されてもよい。Niペイロードは、ナンスを含み、選択的なKEiペイロードは、Diffie-Hellman値を含む。提案されるChild SAのための複数の提案されるTraffic Selectorは、TSiペイロード及びTSrペイロードの中に含まれる。それらの複数のTraffic Selectorは、鍵再生成を実行されるイニシエータと関連するフロー情報を含み、それらのフロー情報は、そのイニシエータがトラフィック通信のために使用するアドレス範囲(IPv4又はIPv6)、ポート範囲、及びIPプロトコルID等である。
提案がレスポンダに受け入れ可能であると仮定すると、そのレスポンダは、同一のTSペイロードを送り返す。他の場合には、そのレスポンダは、イニシエータが提案するトラフィックのサブセットを選択することを許可される。このことは、例えば、2つの端のフロー構成が更新されているが、一方の端のみが新たな情報を受け取っているときに生起する場合がある。それらの2つの端は、ネットワーク管理者等の複数の異なるエンドユーザによって構成されている場合があるため、エラーが存在しない場合であっても、非互換性が長期間にわたって持続する場合がある。レスポンダが、イニシエータが提案するトラフィックのサブセットを選択するときに、そのレスポンダは、(そのセットがヌルセットにならない限り)それらの複数のTraffic Selectorをイニシエータの提案のうちの一部のサブセットに狭める。
操作214: レスポンダが、要求を受信して、チャイルドSAの鍵再生成を実行すると、そのレスポンダは、イニシエータに、チャイルドSAの鍵再生成を実行するためのCREATE_CHILD_SA応答を送信する。
CREATE_CHILD_SA応答は、HDR及び複数のペイロードを含み、それらの複数のペイロードは、SAペイロード、Nrペイロード、TSi及びTSrペイロード、及び、選択的なKErペイロードを含む。
SAペイロードは、SAペイロードのSPIフィールドの中に新たなレスポンダSPIを含む。新たなレスポンダSPIは、鍵再生成の後に、新たなIPSec SAのためのレスポンダの中でインバウンドSPIとして使用され、鍵再生成の後に、新たなIPSec SAのためのイニシエータの中でアウトバウンドSPIとして使用されてもよい。SAペイロードは、また、イニシエータの提示からレスポンダが選択する暗号法一式を含む。Nrペイロードは、ナンスを含み、選択された暗号法一式がそのグループを含む場合には、KErペイロードは、Diffie-Hellman値を含む。
上記のように、レスポンダは、イニシエータに、同じTSペイロードを送り返してもよく、或いは、また、イニシエータが提案するトラフィックのサブセットを選択して、イニシエータに送り返してもよい。
ある1つの実施形態において、レスポンダは、以下のように狭めることを実行する。
レスポンダのポリシーが、提案されたTraffic Selectorのいかなる部分もそのレスポンダが受け入れることを許可していない場合には、そのレスポンダは、TS_UNACCEPTABLE通知メッセージによって応答する。
レスポンダのポリシーが、TSi及びTSrがカバーするトラフィックのセット全体を許可している場合には、狭めることは必要ではなく、そのレスポンダは、同じTSi値及びTSr値を返してもよい。
レスポンダのポリシーが、TSi及びTSrの第1のセレクタをそのレスポンダが受け入れることを許可している場合には、そのレスポンダは、イニシエータの第1の選択を含むサブセットへと、そのTraffic Selectorを狭めるであろう。
レスポンダのポリシーがTSi及びTSrの第1のセレクタをそのレスポンダが受け入れることを許可していない場合には、そのレスポンダは、TSi及びTSrの受け入れ可能なサブセットへと狭める。
操作216, 新たなIPSec SAが作成される。
新たなIPSec SAが確立された後に、その新たなIPSec SA、すなわち、鍵再生成が実行されたIPSec SAは、鍵再生成が実行されたIPSec SAが関連しているIKE SAに追加され、このことは、IKE SAから対応するチャイルドSAへのリンクが存在しているということを意味する。したがって、鍵再生成の後に作成される新たなチャイルドSAは、IKE SAに追加される。
操作212及び214に示されているIKE CREATE_CHILD_SAの交換の後に、新たなIPSec SAは、新たな鍵及び選択された暗号法一式によって作成され、上記で説明されているように、SAペイロードの中で交換される新たなイニシエータSPI及び新たなレスポンダSPIによって識別される。
操作218, イニシエータは、レスポンダに、古いSAを削除するための古いチャイルドSAの削除の要求を送信する。
古いチャイルドの削除の要求は、HDR及びDペイロードを含んでもよい。Dペイロードは、削除されるSAを示すプロトコルID等の情報を含んでもよい。SAの削除は、RFC7296にしたがって、イニシエータとレスポンダとの間のINFORMATIONAL交換を通じて実装されてもよい。
操作220, 古いチャイルドSAの削除の要求を受信すると、レスポンダは、イニシエータに、古いチャイルドSAの削除の応答を送信する。
古いチャイルドSAの削除の応答は、HDR及びDペイロードを含んでもよい。Dペイロードは、削除されるSAを示すプロトコルID等の情報を含んでもよい。SAの削除は、RFC7296にしたがって、イニシエータとレスポンダとの間のINFORMATIONAL交換を通じて実装されてもよい。
図1及び図2の上記の従来技術の方法から理解することができるように、IKE SAの鍵再生成を実行する時に、たとえ、鍵再生成を実行するSAと関連する(例えば、暗号法一式等の)暗号法ポリシーに変更がない場合であっても、イニシエータとレスポンダとの間の交換は、単一の又は複数の暗号法一式を含むSAペイロードを含む。言い換えると、たとえ、イニシエータ及び/又はレスポンダが、それらと関連する暗号法一式を変更する場合であっても、イニシエータとレスポンダの間の鍵再生成の交換は、依然として、単一の又は複数の暗号法一式を含むSAペイロードを含む。IPSec SA鍵再生成の場合には、鍵再生成の時点で、鍵再生成を実行するSAと関連する暗号法ポリシー及びフローポリシーに変更がない場合であっても、イニシエータとレスポンダの間の交換は、単一の又は複数の暗号法一式を含むSAペイロード及びTSi & TSrペイロードを含む。
SA鍵再生成を周期的にトリガする場合には、SA鍵再生成は、これらのペイロードを処理するために帯域幅及び電力を消費する。ペイロードサイズは、IKE SA及びIPSec SAの双方の場合に複数の暗号法一式に対して比例的に増加するため、その問題は、複数の暗号法一式の場合により深刻となる。
IKEv2メッセージのサイズを小さくすることは、例えば、低電力消費技術を利用するモノのインターネット(IoT)デバイスにとって非常に望ましい。そのようなデバイスのうちのいくつかについては、ネットワークを介して余分なビットを伝送するための電力消費が法外に高くなる。そのようなデバイスの多くは、バッテリーによって給電されるが、(数年となることがよくある)そのデバイスのライフサイクルにわたって機能するバッテリーを再充電する能力又は交換する能力を有していない。このような理由により、そのようなデバイスの電力消費を減少させる作業は非常に重要である。
さらに、大きなUDPメッセージは、また、IPレベルにおいてフラグメント化を引き起こす場合があり、そのようなフラグメント化は、ネットワークアドレス変換器(NAT)との間で良くない相互作用をする場合がある。特に、複数のNATのうちのいくつかは、TCP/UDPポート番号を含まないIPフラグメント(非初期IPフラグメント)を破棄する。複数のIOTデバイスのうちのほとんどは、単一のセットの暗号法一式を有しているか、鍵再生成の時点において選択した暗号法一式を変更することを好まない。
ある1つの例では、CREATE_CHILD_SA交換によってIKE SAの鍵再生成を実行する場合には、SAペイロード(単一のセットの暗号法一式)の最小サイズは、52バイトであるが、一方で、本発明の複数の実施形態においては、これらのペイロードは、SPIを取得するための16バイトのサイズを有する通知ペイロードN(NEW_SPI)によって置き換えられる。したがって、36バイトが節約される。
他の例では、CREATE_CHILD_SA交換によってChild SAの鍵再生成を実行する場合に、SAペイロード40の最小サイズは、バイトであり、各々のTSサイズは、24バイト(2*24=48バイト)であるため、合計サイズ88は、バイトである。本発明の複数の実施形態においては、これらのペイロードは、SPIを取得するための12バイトのサイズを有する通知ペイロードN(NEW_SPI)によって置き換えられ、合計76バイトが節約される。
本開示は、軽量鍵再生成の解決方法を提供して、上記で説明されている問題に対処する。この解決方法においては、暗号法ポリシーに変更がないときに、イニシエータとレスポンダとの間の交換は、IKE鍵再生成手順及びIPSec SA鍵再生成手順のいずれにおいてもSAペイロードを搬送しない。その代わりに、SPIは、(既存のSAペイロードの代わりとなることが可能である)本明細書においては"NEW_SPI通知"と称される新たな通知タイプのペイロード又は本明細書においては"Lightweight SAペイロード"と称される新たなペイロード又はSPIを送信するためのいずれかの他のペイロード等の中で転送される。NEW_SPI通知は、既存のSAペイロードよりもより少ないビットを使用する。伝送されるビットを追加的にさらに節約する際に、フロー情報に変更がないときに、イニシエータとレスポンダとの間の交換は、また、IPSec SA鍵再生成の際にTSペイロードを搬送しない。ある1つの例として、"Lightweight SAペイロード"フォーマットは、SAペイロードヘッダー及び提案ペイロードのみを含んでもよい。このようにして、Sai1及びSAr1において送信されるペイロード等の従来のペイロードと比較して、ペイロードは削減される。
軽量鍵再生成アプローチを実装するために、2つの端は、軽量鍵再生成方法を実行するそれぞれの能力を交換してもよい。この交換は、例えば、上記で説明されているように、IKE又はIPSec SAをセットアップするための初期交換の間であって、且つ、鍵再生成処理の前に実行されてもよい。
本開示のある1つの実施形態によれば、軽量鍵再生成の能力の交換は、2つのピアの間での以下の操作を含んでもよい。
イニシエータは、第2のネットワークデバイスに、そのイニシエータが、例えば、鍵再生成の選択的なペイロードをサポートする等、軽量鍵再生成をサポートしているということを示す通知を送信する。
レスポンダは、そのレスポンダが、例えば、鍵再生成の選択的なペイロードをサポートする等、軽量鍵再生成をサポートしているということを示す応答を送信する。
この初期サポートプロセスを通じて、2つの端は、そのピアが軽量鍵再生成アプローチをサポートしているか否かを互いに知ることが可能である。
図3A乃至図5は、イニシエータとレスポンダとの間の軽量鍵再生成のサポートを交渉するための3つの異なる手法を図示している。それらの3つの手法のすべては、初期交換プロセスを使用して、軽量鍵再生成の交渉を実装する。上記で説明されているように、本開示は、初期交換プロセスのみを使用して、軽量鍵再生成の交渉を実装することには限定されず、本開示を読んだ後に当業者は、他の手法を想定してもよい。
図3Aに図示されている実施形態においては、軽量鍵再生成をサポートする通知は、例えば、イニシエータがレスポンダに送信するIKE_SA_INIT要求メッセージ等のINIT要求の中の通知ペイロードの中で搬送され、したがって、軽量鍵再生成をサポートする確認は、例えば、レスポンダからイニシエータに送信されるIKE_SA_INIT応答メッセージ等のINIT応答の中の通知ペイロードの中で搬送される。ある1つの例として、図3Bは、通知ペイロードの構成を図示しており、その通知ペイロードにおいては、通知メッセージのタイプは、IKEV2_REKEY_OPTIONAL_PAYLOAD_SUPPORTEDであり、そのタイプは、従来の通知ペイロードと比較して、新たな"通知メッセージのタイプ"である。IKEV2_REKEY_OPTIONAL_PAYLOAD_SUPPORTED等の新たな通知メッセージのタイプは、通知ペイロードの中に含まれ、イニシエータ又はレスポンダが軽量鍵再生成をサポートしているということを示す。
図4に図示されている実施形態において、軽量鍵再生成をサポートする通知は、例えば、イニシエータがレスポンダに送信するIKE_SA_AUTH要求メッセージ等のAUTH要求の中の通知ペイロードの中で搬送され、したがって、軽量鍵再生成をサポートする通知は、例えば、レスポンダからイニシエータに送信されるIKE_SA_AUTH応答メッセージ等のAUTH要求の中の通知ペイロードの中で搬送される。通知ペイロードのタイプは、IKEV2_REKEY_OPTIONAL_PAYLOAD_SUPPORTEDペイロードであってもよい。
図5に図示されている実施形態において、軽量鍵再生成をサポートする通知は、例えば、イニシエータがレスポンダに送信するIKE_SA_INIT要求メッセージ等のINIT要求の中の通知ペイロードの中で搬送され、したがって、軽量鍵再生成をサポートする通知は、例えば、レスポンダからイニシエータに送信されるIKE_SA_AUTH応答メッセージ等のAUTH応答の中の通知ペイロードの中で搬送される。通知ペイロードのタイプは、IKEV2_REKEY_OPTIONAL_PAYLOAD_SUPPORTEDペイロードであってもよい。
軽量鍵再生成の能力の交渉は、例えば、IKE INIT又はAUTHの間等の鍵再生成プロセスの前には実行されなくてもよく、このことは、当事者の双方がこの能力に同意しておらず、その結果、イニシエータ又はレスポンダのうちのいずれかが、NEW_SPI又はLight Weight SAペイロードを送信することを許可されるべきではない場合に、他方の当事者は、これを破棄し、そして、エラーとして扱うことが可能であるということを意味するということに留意すべきである。
図6を参照すると、図6は、軽量鍵再生成アプローチを使用するSAの鍵再生成の実行のフローチャートを図示している。
IKE及びIPSec SA(s)がイニシエータとレスポンダの間で確立された後に、IKE及びIPSec SA(s)のうちのいずれか一方の存続期間が、各々の端におけるSA存続期間ポリシーにしたがって、満了に近くなっている場合に、イニシエータは、以下の操作を含んでもよい鍵再生成プロセスを開始する。
操作602, イニシエータは、そのイニシエータと関連する暗号法一式に変更があるか否かを決定する。
この開示において、イニシエータと関連する暗号法一式は、暗号法一式が、イニシエータによってサポートされ、且つ、例えば、SAの鍵再生成状況において鍵再生成を実行されたSA(すなわち、新たなSA)等のイニシエータが確立するある特定のSAのために使用されるということを意味する。
脆弱な暗号法一式と関連するSAを確立した後に、それらのSAのうちのいずれか1つの存続期間が満了に近くなる場合に、イニシエータは、新たなSAを作成し、そして、古いSAのために使用されている(又は、また、古いSAと関連すると称されてもよい)暗号法一式を変更することにより又は変更することなく、(古いSAとも称されてもよい)その鍵再生成を実行されるべきSAを削除することによって、SAの鍵再生成を実行することを望む。言い換えると、そのイニシエータと関連する暗号法一式が変更されないということは、古いSAが使用している暗号法一式が、鍵再生成を実行されるSA(すなわち、新たなSA)のために依然として使用されていてもよいということを意味する。そのイニシエータと関連する暗号法一式が変更されているということは、古いSAが関連している暗号法一式が、イニシエータがサポートしているとともに、新たなSAのために使用される(すなわち、新たなSAと関連する)他の暗号法一式へと変更されるということを意味する。以下の記載は、イニシエータと関連する暗号法一式の変更のためのいくつかの状況を説明する。
ある1つの状況は、イニシエータがサポートする暗号法一式が変更されるという状況である。例えば、イニシエータは、現在、(例えば、脆弱な暗号法一式等の)第1の暗号法一式のみをサポートしている。古いSAを確立した後に、イニシエータによる当該暗号法一式のサポートは、(例えば、イニシエータが、より高いセキュリティ要件を要するより重要な役割を担う等の)何らかの理由により、ネットワーク管理者がユーザインターフェイスを介してイニシエータを構成することによって、(強力な暗号法一式の)第2の暗号法一式へと変更される。暗号法一式を変更した後に、イニシエータが古いSAの鍵再生成を実行することを望む場合に、そのイニシエータは、現時点では、強力な暗号法一式のみをサポートしているため、そのイニシエータは、新たなSAのための暗号法一式を変更する必要がある。
他の状況は、イニシエータがサポートする暗号法一式が変更されないという状況である。例えば、イニシエータは、現在、2つ又はそれ以上の暗号法一式をサポートしている。鍵再生成を実行するときに、イニシエータは、例えば、SAの要件が改善され、その改善により、新たなSAのために使用されるより強力な暗号法一式が必要となる等の何らかの理由により、古いSAと関連する暗号法一式を使用するのではなく、新たなSAのための新たな暗号法一式を使用することを望む。この状況においては、古いSAと関連する第1の暗号法一式は、もはや、新たなSAとは関連していないので、そのイニシエータがレスポンダに送信する鍵再生成要求は、新たなSAのための第2の暗号法一式を搬送する必要がある。その詳細な実装は、図7A乃至図12の説明の中で開示されている。
さらに、他の状況は、イニシエータが、例えば、脆弱な暗号法一式等の第1の暗号法一式のみをサポートしている場合に、そのイニシエータが、古いSAの鍵再生成を実行するときに、何らかの理由により、(例えば、強力な暗号法一式に変更するといったように)第1の暗号法一式を第2の暗号法一式に変更することを望んでいるという状況である。この状況においては、イニシエータは、現時点では、第1の暗号法一式のみをサポートしているので、イニシエータを再構成する必要がある。ネットワーク管理者は、第2の暗号法一式をサポートするように、又は、第1の暗号法一式及び第2の暗号法一式の双方をサポートするように、イニシエータを再構成することを選択してもよい。また、その構成は、イニシエータ又はいくつかの他のデータベース又はデバイスの中に格納される。例えば、イニシエータがサポートする1つ又は複数の暗号法一式とそのイニシエータとの間の対応関係が、イニシエータ又はいくつかの他の場所に格納されてもよい。レスポンダ側での構成プロセスは、上記と同様である。再構成の後に、イニシエータは、そのイニシエータがサポートしている第2の暗号法一式を選択し、そして、SA鍵再生成の交換のための鍵再生成要求の中に、第2の暗号法一式を入れてもよい。
以下の記載は、イニシエータと関連する暗号法一式に変更がない場合のいくつかの状況を説明している。
1つの状況は、イニシエータが、例えば、脆弱な暗号法一式等の第1の暗号法一式のみをサポートし、古いSAと関連する第1の暗号法一式は、依然として、新たなSAと関連しているので、イニシエータが、古いSAの鍵再生成を実行するときに、変更時に第1の暗号法一式を保持する(すなわち、第1の暗号法一式が、依然として、鍵再生成を実行されるSAのために使用される)ことを望み、イニシエータがレスポンダに送信する鍵再生成要求が、新たなSAのための暗号法一式を搬送しないという状況である。
他の状況は、イニシエータが、例えば、(例えば、脆弱な暗号法一式等の)第1の暗号法一式及び(例えば、強力な暗号法一式等の)第2の暗号法一式等の2つ又はそれ以上の暗号法一式をサポートし、イニシエータが、古いSAの鍵再生成を実行するときに、第1の暗号法一式から第2の暗号法一式へと変更することを望まないという状況である。この状況においては、古いSAと関連する第1の暗号法一式は、依然として、新たなSAのために使用されるので、イニシエータがレスポンダに送信する鍵再生成要求は、新たなSAのための暗号法一式を搬送する必要はない。その詳細な実装は、図7A乃至12の説明を参照されたい。
操作604, イニシエータは、イニシエータと関連する暗号法一式に変更がないときに、レスポンダに、SAの鍵再生成を実行するための第1の鍵再生成要求を送信する。
上記で説明されているように、イニシエータと関連する暗号法一式に変更がないということは、古いSAが使用している暗号法一式が、依然として、鍵再生成を実行されるSA(すなわち、新たなSA)のために使用されてもよいということを意味する。イニシエータが新たなSAのための暗号法一式を搬送する必要はない。
イニシエータは、SAを確立した後に、暗号法一式を変更しないか、又は、イニシエータは、暗号法一式を過去に変更し、そして、その変更された暗号法一式を元の暗号法一式に再び変更し、現在の暗号法一式は、SAが確立されたときに使用される暗号法一式と同じになるため、第1の鍵再生成要求は、第1のSPIを搬送し、イニシエータと関連する暗号法一式を搬送しない。
IKE鍵再生成のシナリオにおいては、第1のSPIは、新たなイニシエータSPIである。双方の端におけるSPIの対によって、IKE SAを識別することが可能である。したがって、一方の端が鍵再生成プロセスを開始するときに、その鍵再生成プロセスは、鍵再生成要求の中に新たなSPIを含み、新たなSPIは、鍵再生成の後の新たなIKE SAのためのイニシエータSPIとして使用される。レスポンダが、応答としてIKE鍵再生成に応答するときに、レスポンダは、鍵再生成応答の中に新たなSPIを追加し、その新たなSPIは、鍵再生成の後の新たなIKE SAのためのレスポンダSPIとして使用されるべきである。
IPSec SA鍵再生成シナリオにおいては、第1のSPIは、鍵再生成の後に、新たなIPSec SAのためのイニシエータの中でインバウンドSPIとして使用され、鍵再生成の後に、新たなIPSec SAのためのレスポンダの中でアウトバウンドSPIとして使用される。さらに、第1の鍵再生成要求は、また、上記で説明されているように、N[REKEY_SA]ペイロードの中でSPIを搬送して、鍵再生成を実行されるSAを識別する。
この操作の詳細な実装については、図7乃至図9に図示されている以下のIKE鍵再生成プロセスを参照してもよい。
操作606, レスポンダは、イニシエータに第1の鍵再生成応答を送信する。レスポンダと関連する暗号法一式に変更がないときに、第1の鍵再生成応答は、第2のSPIを搬送し、第2のネットワークデバイスと関連する暗号法一式を搬送しない。
上記で説明されているように、IKE鍵再生成シナリオにおいては、第2のSPIは、新たなレスポンダSPIとなる。レスポンダが応答としてIKE鍵再生成に応答するときに、そのレスポンダは、鍵再生成応答の中に新たなレスポンダSPIを追加し、その新たなレスポンダSPIは、鍵再生成の後に、新たなIKE SAのためのレスポンダSPIとして使用されるべきである。
IPSec SA鍵再生成シナリオにおいては、第2のSPIは、鍵再生成の後に、新たなIPSec SAのためのレスポンダの中でインバウンドSPIとして使用され、鍵再生成の後に、新たなIPSec SAのためのイニシエータの中でアウトバウンドSPIとして使用される。
この操作の詳細な実装については、図8乃至図10に示されているように、以下のIKE鍵再生成プロセスを参照してもよい。
操作608, 第1のネットワークデバイスと関連する暗号法一式及び第2のネットワークデバイスと関連する暗号法一式に変更がないときに、イニシエータによって、第1のSPI及び第2のSPIにしたがって、SAの鍵再生成を実行する。
鍵再生成を実行することは、新たなSAを作成すること、及び、鍵再生成を実行されるべき古いSAを削除することを含む。具体的には、イニシエータは、イニシエータSPI、レスポンダSPI、及び、古いSAのために使用される変更されていない暗号法一式を使用することによって、SAの鍵再生成を実行して、新たなSAのための新たな鍵を取得する。詳細な実装については、図7乃至図9に図示されているように、以下のIKE鍵再生成プロセスを参照してもよい。
図7Aは、本開示のある1つの実施形態にしたがったIKE SAの鍵再生成の実行のフローチャートである。この実施形態においては、イニシエータは、例えば、より高い暗号アルゴリズムセットを有する強力なより高い暗号法一式等の、鍵再生成を実行されるSAを確立するときに使用される暗号法一式を変更しない。
この実施形態においては、2つのシナリオが存在し、第1のシナリオは、レスポンダも、また、暗号法一式を変更しないというシナリオである。第2のシナリオは、レスポンダが暗号法一式を変更することを望むというものである。
この実施形態の第1のシナリオによれば、IKE鍵再生成プロセスは、以下の操作を含む。
操作702, イニシエータは、レスポンダにINIT要求を送信する。INIT要求は、上記で説明されているように、通常のHDRヘッド及び通常のペイロード以外に、通知ペイロードを搬送する。この実施形態においては、通知ペイロードはIKEV2_REKEY_OPTIONAL_PAYLOAD_SUPPORTEDペイロードであり、そのペイロードは、イニシエータが軽量鍵再生成をサポートするということを示す。
操作704, レスポンダは、イニシエータにINIT応答を送信する。INIT応答は、上記で説明されているように、通常のHDRヘッド及び通常のペイロード以外に、通知ペイロードを搬送する。この実施形態においては、通知ペイロードは、IKEV2_REKEY_OPTIONAL_PAYLOAD_SUPPORTEDペイロードであり、そのペイロードは、レスポンダが軽量鍵再生成アプローチをサポートしているということを示す。
上記で説明されている初期交換によれば、操作706及び708を実行した後に、IKE SA及びIPSec SAは、イニシエータとレスポンダとの間で確立される。
図3乃至図5に記載されている軽量鍵再生成の能力を交渉する複数の他の方法も、また、この実施形態に適用されてもよいということを理解すべきである。
操作710, IKE SA及びIPSEC SAが確立され、イニシエータは、周期的にIKE鍵再生成をトリガする。
イニシエータは、IKE SAの存続期間が満了しつつあるか否かを周期的に検出してもよい。上記のように、イニシエータは、イニシエータの側で存続期間ポリシーを維持してもよい。存続期間ポリシーは、複数の異なるSAについて異なる存続期間を設定してもよい。イニシエータは、IKE SAの存続期間が満了しつつあるということを検出するときに、操作712が実行される。
操作712, イニシエータは、レスポンダに、IKE SAの鍵再生成を実行するためのCREATE_CHILD_SA要求を送信する。CREATE_CHILD_SA要求は、HDRヘッド、Niペイロード、及びKEiペイロードを含む。1つ又は複数の暗号法一式を搬送するSAペイロードを搬送する代わりに、CREATE_CHILD_SA要求は、例えば、NEW_SPI通知等の通知ペイロードを搬送する。NEW_SPIペイロードは、新たなイニシエータSPIを搬送し、暗号法一式を搬送しないSPIファイルを有してもよい。図7Bは、鍵再生成要求パケットフォーマットのある1つの例を示す。
代替的に、Lightweight SAペイロード又は他のペイロードは、新たなイニシエータSPIを搬送するのに使用されてもよい。
NEW_SPIは、新たに定義された通知ペイロードであり、その新たに定義された通知ペイロードは、鍵再生成の後に、新たなIKE SAを識別するイニシエータSPIを搬送する。
ある1つの例として、図7Cは、IKEのためのNEW_SPIを図示している。
ある1つの例として、図7Dは、IKEのためのLightweight SAペイロードを図示している。その例においては、Lightweight SAペイロードは、単一の提案ペイロードを含み、変換及び属性を含まない。この構成によれば、IKE鍵再生成の場合に"SPI"の中で言及されている値は、IKE SAのためのイニシエータSPI/レスポンダSPIとして使用される。
714, レスポンダは、イニシエータに、IKE SAの鍵再生成を実行するためのCREATE_CHILD_SA応答を送信する。
CREATE_CHILD_SA応答は、HDRヘッド、Nrペイロード、及びKErペイロードを含む。1つ又は複数の暗号法一式を搬送するSAペイロードを搬送する代わりに、CREATE_CHILD_SA応答は、例えば、NEW_SPI通知等の通知ペイロードを搬送する。NEW_SPIペイロードは、新たなレスポンダSPIを搬送し、暗号法一式を搬送しないSPIファイルを有してもよい。
操作716, 新たなIKE SAが作成される。
具体的には、上記で説明されているように、このシナリオにおいては、イニシエータ及びレスポンダの双方は、自身の暗号法一式を変更しない。イニシエータSPI及びレスポンダSPI、及び、鍵再生成を実行される古いSAのために使用されるもとの暗号法一式にしたがって、新たなIKE SAを作成する。新たなIKE SAは、IKE制御パケットを保護するのに使用される。新たなIKE SA、すなわち、鍵再生成を実行されたIKE SAは、そのIKE SAのチャイルドSAのすべてを引き継ぎ、このことは、古いIKE SAとリンクされる既存のチャイルドSAは、鍵再生成の実行が成功した後に、新たなIKE SAへと移動されるということを意味する。
操作718, イニシエータは、レスポンダに、古いIKE SAを削除するための古いIKE SAの削除の要求を送信する。
古いIKEの削除の要求は、HDR及びDペイロードを含んでもよい。Dペイロードは、削除されるべき古いSAを示すプロトコル識別子(ID)等の情報を含んでもよい。詳細な実装については、操作216を参照してもよい。
操作718, 古いIKE SAの削除の要求を受信すると、レスポンダは、イニシエータに、古いIKE SAの削除の応答を送信する。
古いIKE SAの削除の応答は、HDR及びDペイロードを含んでもよい。Dペイロードは、削除されるSAを示すプロトコルID等の情報を含んでもよい。詳細な実装については、操作218を参照してもよい。
この実施形態において説明されている軽量鍵再生成アプローチを使用することによって、このNEW_SPI通知ペイロードは、例えば、最小で36バイトを節約することが可能であり、複数の暗号法一式によって、節約されるバイトの数を比例的に増加させ、このことは、複雑な検証の処理を減少させ、したがって、IKE鍵再生成のやりとりにおけるSAペイロードの処理を減少させる。例えば、NEW_SPI通知ペイロードのサイズは、12乃至16バイトの範囲にあってもよい。
図8を参照すると、図8は、レスポンダが、(例えば、鍵再生成を実行されるSAを確立するときに使用される暗号法一式等の)そのレスポンダが現在使用している暗号法一式を変更する第2のシナリオを図示している。この状況においては、レスポンダは、操作814において、イニシエータに、NEW_SPI通知又はSAペイロードが変更された暗号法一式を搬送する代わりに、CREATE_CHILD_SA応答の中で提案非選択通知ペイロードを送信してもよい。その非選択通知ペイロードは、NO_PROPOSAL_CHOSENペイロードであってもよく、そのNO_PROPOSAL_CHOSENペイロードは、CREATE_CHILD_SA要求の中で搬送される暗号法一式の中に一致する暗号法一式が存在しないということを示す。その次に、イニシエータがその指示を受信した後に、そのイニシエータは、CREATE_CHILD_SA要求を再送信するが、このときは、更新した暗号法一式を搬送するSAペイロードを搬送して、イニシエータ及びレスポンダがその暗号法一式に関する合意を獲得するまで、そのレスポンダと暗号法一式について再交渉する。暗号法一式の再交渉のプロセスについては、この開示の中で説明されているシナリオのうちのいずれか1つを参照してもよい。その再交渉のある1つの例を以下で説明する。
この例では、操作802乃至812は、上記の操作702乃至712と同じである。しかし、操作814において、CREATE_CHILD_SA応答は、HDRヘッド及び通知ペイロードを搬送する。その通知ペイロードは、NO_PROPOSAL_CHOSENタイプのペイロードであってもよく、そのNO_PROPOSAL_CHOSENタイプのペイロードは、CREATE_CHILD_SA要求の中で搬送される暗号法一式の中に一致する暗号法一式が存在しないということを示す。ある1つの例として、図7Eは、通知メッセージタイプがNO_PROPOSAL_CHOSENである通知ペイロードの構成を図示している。このようにして、本明細書において開示されている他の新たな通知に関しては、従来の通知の構成が使用されるが、新たな通知タイプを有する。その次に、イニシエータがその指示を受信した後に、そのイニシエータは、更新した暗号法一式を搬送するSAペイロードを搬送するCREATE_CHILD_SA要求を再送信して、そのイニシエータ及びレスポンダが暗号法一式に関する合意を獲得するまで、そのレスポンダと暗号法一式について再交渉する。暗号法一式の再交渉のプロセスについては、この開示の中で説明されているシナリオのうちのいずれか1つを参照してもよい。以下では、再交渉のある1つの例を説明する。
その次に、操作816において、イニシエータは、レスポンダに、CREATE_CHILD_SA要求を再送信する。第2のCREATE_CHILD_SA要求は、HDRヘッド、N(REKEY_SA)ペイロード、SAペイロード、Niペイロード、及び選択的なKEiペイロードを含む。Niペイロード及びKeiペイロードの内容については、操作212及び操作712を参照してもよい。SAペイロードは、新たなイニシエータSPI及びイニシエータが提案した1つ又は複数の暗号法一式を搬送するSPIファイルを搬送する。
操作818において、レスポンダは、イニシエータに、CREATE_CHILD_SA応答を送信する。CREATE_CHILD_SA応答は、HDRヘッド、SAペイロード、Nrペイロード、及びKErペイロードを搬送する。
操作820, 新たなIKE SAが作成される。この操作の実装については、上記で説明されている操作716を参照してもよい。
操作820, イニシエータは、レスポンダに、古いIKE SAを削除するための古いIKE SAの削除の要求を送信する。
その古いIKEの削除の要求は、HDR及びDペイロードを含んでもよい。Dペイロードは、削除されるSAを示すプロトコルID等の情報を含んでもよい。詳細な実装については、上記で説明されている操作216及び718を参照してもよい。
操作822, 古いIKE SAの削除の要求を受信すると、レスポンダは、イニシエータに、古いIKE SAの削除の応答を送信する。
古いチャイルドSAの削除の応答は、HDR及びDペイロードを含んでもよい。Dペイロードは、削除されるSAを示すプロトコルID等の情報を含んでもよい。詳細な実装については、上記で説明されている操作218及び720を参照してもよい。
図9は、本開示のある1つの実施形態にしたがったIKE SAの鍵再生成の実行のフローチャートである。この実施形態においては、イニシエータは、暗号法一式を変更する。
この実施形態においては3つのシナリオが存在する。第1のシナリオは、レスポンダが、暗号法一式を変更しないというシナリオである。このシナリオにおいては、例えば、イニシエータは、(例えば、脆弱な暗号法一式及び強力な暗号法一式等の)2つのサポートされている一式を有してもよく、脆弱な暗号法一式から強力な暗号法一式に変更することを望んではいるが、一方で、レスポンダは、脆弱な暗号法一式のみをサポートし、暗号法一式を変更することを望んではいない。この場合には、レスポンダは、イニシエータとの間で暗号法一式について交渉しなくてもよく、軽量鍵再生成アプローチを使用してもよい。例えば、レスポンダは、レスポンダSPIを収容するためのNEW_SPI通知、Lightweight SAペイロード、又はいずれかの他のペイロードを使用することが可能である。
第2のシナリオは、レスポンダが暗号法一式を変更するというシナリオである。このシナリオにおいては、例えば、イニシエータが、(例えば、脆弱な暗号法一式及び強力な暗号法一式等の)2つのサポートする一式を有し、脆弱な暗号法一式から強力な暗号法一式に変更することを望んでいるときに、レスポンダは、また、(鍵再生成を実行されるSAを最初に確立するときに使用される)脆弱な暗号法一式を強力な暗号法一式に変更することを望んでいる。この場合には、レスポンダは、鍵再生成応答の中で、強力な暗号法一式を搬送するSAペイロードを搬送してもよい。
第3のシナリオは、レスポンダが暗号法一式を変更するというシナリオである。このシナリオにおいては、例えば、イニシエータが、(例えば、強力な暗号法一式等の)サポートする一式を1つのみ有し、脆弱な暗号法一式を強力な暗号法一式に変更することを望んでいるときに、レスポンダは、脆弱な暗号法一式のみをサポートする。この場合には、レスポンダは、イニシエータが送信する鍵再生成要求の中で搬送される暗号法一式の中に一致する暗号法一式が存在しないということを示す通知ペイロードを送信する。その次に、イニシエータが指示を受信した後に、そのイニシエータは、鍵再生成要求を再送信するが、このときは、更新した暗号法一式を搬送するSAペイロードを搬送して、イニシエータ及びレスポンダが暗号法一式に関する合意を獲得するまで、レスポンダと暗号法一式について再交渉する。暗号法一式の再交渉のプロセスについては、この開示の中で説明されているシナリオのうちのいずれか1つを参照してもよい。
この実施形態によれば、IKE鍵再生成プロセスは、以下の操作を含む。
操作902乃至910の詳細な実装については、図7において説明されている操作702乃至710を参照してもよい。
操作912, イニシエータは、レスポンダに、IKE SAの鍵再生成を実行するためのCREATE_CHILD_SA要求を送信する。CREATE_CHILD_SA要求は、HDRヘッド、SAペイロード、Niペイロード、及びKEiペイロードを含む。各々のペイロードの中で搬送される情報については、操作112を参照してもよい。この場合には、例えば、SAペイロードは、例えば、脆弱な暗号法一式及び強力な暗号法一式等の2つの暗号法一式を搬送する。
操作914, レスポンダは、イニシエータに、IKE SAの鍵再生成を実行するためのCREATE_CHILD_SA応答を送信する。CREATE_CHILD_SA応答は、HDRヘッド、Nrペイロード、及びKErペイロードを含む。暗号法一式を搬送するSAペイロードを搬送する代わりに、CREATE_CHILD_SA要求は、例えば、NEW_SPI通知等の通知ペイロードを搬送する。NEW_SPIペイロードは、新たなレスポンダSPIを搬送し、暗号法一式を搬送しないSPIファイルを有する。
操作914においては、レスポンダは、選択的な手法として、レスポンダが現在使用している暗号法一式を変更することをそのレスポンダが望まない場合であっても、そのレスポンダが現在使用している(すなわち、SAを確立するときにそのレスポンダが使用した)暗号法一式及び新たなレスポンダSPIを搬送するSAペイロードを搬送するCREATE_CHILD_SA応答を送信してもよいということを理解すべきである。
この実施形態の第2のシナリオによれば、レスポンダが現在使用している暗号法一式を変更することをそのレスポンダが望むときに、例えば、脆弱な暗号法一式から強力な暗号法一式に変更する。CREATE_CHILD_SA応答は、イニシエータがサポートする変更された暗号法一式、すなわち、強力な暗号法一式を搬送するSAペイロードを搬送する。
操作916乃至918の詳細な実装については、図8において説明されている操作716乃至718及び図2において説明されている操作216乃至218を参照してもよい。
この実施形態の第3のシナリオによれば、例えば、イニシエータは、(例えば、強力な暗号法一式等の)1つの暗号法一式のみをサポートし、例えば、脆弱な暗号法一式から強力な一式に暗号法一式へと暗号法一式を変更する。そして、レスポンダは、脆弱な暗号法一式のみをサポートする。このシナリオにおいては、レスポンダにおける暗号法一式は、イニシエータが提案する暗号法一式と一致しない。レスポンダとイニシエータとの間で暗号法一式での一致がないと決定した後に、レスポンダは、操作914において、イニシエータに、SAペイロードの代わりにCREATE_CHILD_SA応答の中で、提案非選択通知ペイロードを送信してもよい。提案非選択通知ペイロードは、NO_PROPOSAL_CHOSENペイロードであってもよく、そのNO_PROPOSAL_CHOSENペイロードは、CREATE_CHILD_SA要求の中で搬送される暗号法一式の中に一致する暗号法一式が存在しないということを示す。その次に、イニシエータがその指示を受信した後に、イニシエータは、更新した暗号法一式を搬送するSAペイロードを搬送するCREATE_CHILD_SA要求を再送信して、イニシエータ及びレスポンダが暗号法一式に関する合意を獲得するまで、レスポンダと暗号法一式について再交渉する。暗号法一式の再交渉のプロセスについては、この開示の中で説明されているシナリオのうちのいずれか1つを参照してもよい。
IKE鍵再生成にNEW_SPI通知ペイロードを導入することによって、例えば、各々のIKE鍵再生成について、最低36バイトを節約することが可能であり、したがって、複雑な検証の処理を減少させるとともにSAペイロードの処理もまた減少させることが可能である。
図10は、本開示のある1つの実施形態にしたがったIPSec SAの鍵再生成の実行のフローチャートである。この実施形態においては、イニシエータは、例えば、より高い暗号アルゴリズムセットを有する強力な暗号法一式等の、鍵再生成を実行されるSAを確立するときに使用される暗号法一式を変更しない。フロー情報に関しては、イニシエータは、フロー情報を変更してもよく又はフロー情報を変更しなくてもよい。イニシエータがフロー情報を変更しないときは、鍵再生成要求は、TSペイロードを搬送する必要はなく、対照的に、イニシエータがフロー情報を変更するときは、鍵再生成要求は、アドレス範囲、ポート範囲、及びIPプロトコルID等の変更されたフロー情報を反映するフロー情報を搬送する。
この実施形態においては、2つのシナリオが存在し、第1のシナリオは、レスポンダがまた暗号法一式を変更しないというシナリオである。第2のシナリオは、レスポンダが暗号法一式を変更するというシナリオである。
IKE SA及びIPSec SAの同時の鍵再生成の場合には、複数の操作(すなわち、IKE_SA_INIT又はAUTH要求メッセージにおけるIKEV2_REKEY_OPTIONAL_PAYLOAD_SUPPORTEDの交渉、及び/又は、"NEW_SPI通知"又は"Lightweight SAペイロード"、或いは、SAの鍵再生成を実行するためのSPIを含むいずれかの他のペイロードの交渉)は、この開示の中で説明されている複数の実施形態と類似したままであるということを理解すべきである。同時の鍵再生成の場合に、好ましくは、メッセージを組み合わせることなく、独立して鍵再生成プロセスを実行する。
この実施形態の第1のシナリオによれば、IPSec鍵再生成プロセスは、以下の操作を含む。
操作1002乃至1010, 操作1002乃至1010の詳細な実装については、図8において説明されている操作802乃至810を参照してもよい。
操作1012, イニシエータは、レスポンダに、チャイルドSAの鍵再生成を実行するためのCREATE_CHILD_SA要求を送信する。
CREATE_CHILD_SA要求は、HDRヘッド、N(REKEY_SA)ペイロード、NEW_SPIペイロード、Niペイロード、及び選択的なKEiペイロードを含み、イニシエータがフロー情報を変更しないときには、いかなるTSペイロードも含まない。N(REKEY_SA)ペイロードは、いずれのチャイルドSAが鍵再生成を実行されるべきであるかを示すSPIを搬送する。Niペイロード及びKEiペイロードの内容については、操作212を参照してもよい。1つ又は複数の暗号法一式を搬送するSAペイロードを搬送する代わりに、CREATE_CHILD_SA要求は、例えば、NEW_SPI通知ペイロード等の通知ペイロードを搬送する。NEW_SPIペイロードは、新たなイニシエータSPIを搬送し、暗号法一式を搬送しないSPIファイルを有する。代替的に、Lightweight SAペイロード又は他のペイロードは、新たなイニシエータSPIを搬送するのに使用されてもよい。
NEW_SPIは、新たに定義されたNOTIFYペイロードであり、その新たに定義されたNOTIFYペイロードは、鍵再生成の後の新たなIPSec SAを識別するイニシエータSPIを搬送する。図10Bは、例えば、IPSec鍵再生成要求の中のNEW_SPI通知ペイロード等の新たなフィールドを示す鍵再生成要求パケットフォーマットのある1つの例を示している。
ある1つの例として、図10Cは、AHのためのNEW_SPIを図示している。
ある1つの例として、図10Dは、IPSec SAのための新たに定義されたペイロードである2種類のLightweight SAを図示している。最上位のLightweight SAペイロードは、単一の提案ペイロードを含み、TRANSFORMS及び属性を含まず、より下位のLightweight SAペイロードは、図10Dに示されているように、SAバンドルを含む。IPSecトンネルを作成するときに、2つの手法が存在する。1つの手法は、AH又はESPのうちのいずれかを使用する手法であり、もう1つの手法は、AH及びESPの双方を使用する手法であり、そのもう1つの手法は、また、SAバンドルと称される。SAバンドルは、ユーザが同時にAH及びESPの双方を使用することを望むときに使用される。
IPSec鍵再生成の場合に"SPI"ファイルの中で言及されている値は、AH/ESP SAのためのインバウンドSPI/アウトバウンドSPIとして使用される。
代替的に、イニシエータが、例えば、鍵再生成の後に、新たなSAのためのIPアドレス範囲等のフロー情報を変更するといったように、フロー構成を変更するとき、CREATE_CHILD_SA要求は、さらに、上記で説明されているペイロード以外に、TSペイロードを搬送してもよい。TSペイロードの内容については、操作212を参照してもよい。
操作1014, レスポンダは、イニシエータに、チャイルドSAの鍵再生成を実行するためのCREATE_CHILD_SA応答を送信する。
CREATE_CHILD_SA応答は、HDRヘッド、Nrペイロード、及び選択的なKErペイロードを含み、その選択的なKErペイロードは、CREATE_CHILD_SA要求がKEiペイロードを搬送しているか否かを条件とする。1つ又は複数の暗号法一式を搬送するSAペイロードを搬送する代わりに、CREATE_CHILD_SA応答は、例えば、NEW_SPI通知等の通知ペイロードを搬送する。NEW_SPIペイロードは、新たなレスポンダSPIを搬送し、暗号法一式を搬送しないSPIファイルを有してもよい。
CREATE_CHILD_SA要求は、イニシエータと関連するフロー情報を搬送するTSペイロードを搬送しないので、レスポンダは、CREATE_CHILD_SA応答の中でTSペイロードを搬送するか否かに関して、以下の2つの選択を有してもよい。
第1の選択は、レスポンダと関連するフロー情報に変更がなく、現在使用されているフロー情報が、鍵再生成の後に、依然として、新たなIPSec SAのために使用されているときに、CREATE_CHILD_SA応答は、レスポンダと関連するTSペイロードを搬送しないということである。
第2の選択は、レスポンダと関連するフロー情報に変更があるときに、CREATE_CHILD_SA応答がTS受け入れ不可能通知を搬送するということである。TS受け入れ不可能通知は、TS_UNACCEPTABLE通知ペイロードであってもよく、そのTS_UNACCEPTABLE通知ペイロードは、イニシエータとレスポンダの間で情報が一致しないということを示すのに使用される。その次に、イニシエータがTS受け入れ不可能通知を受信した後に、そのイニシエータは、CREATE_CHILD_SA要求を再送信し、そのCREATE_CHILD_SA要求は、このときは、更新したフロー情報を搬送するTSペイロードを搬送し、イニシエータ及びレスポンダがフロー情報に関する合意を獲得するまで、レスポンダとフロー情報について再交渉する。フロー情報の再交渉のプロセスについては、この開示の中で説明されている暗号法一式又はフロー情報の交渉のシナリオのうちのいずれか1つを参照してもよい。
暗号法一式の交渉又はフロー情報の交渉のうちのいずれか一方が第1の交渉ターンにおいて失敗するときに、2つの端は、第2の交渉ターンにおいて、暗号法一式の交渉及びフロー情報の交渉の双方について再交渉してもよいということに留意すべきである。その場合には、再送信されたCREATE_CHILD_SA要求は、レスポンダとの間でフロー情報の交渉と共に暗号法一式について再交渉するために、SAペイロードを使用して行われてもよく又はSAペイロードを使用することなく行われてもよい。暗号法一式の詳細については、この開示の中で説明されているIPSec SA暗号法一式のシナリオのうちのいずれか1つを参照してもよい。
暗号法一式の交渉及びフロー情報の交渉は、独立して実行されてもよいということを理解すべきである。その場合には、2つの端は、第1の交渉ターンにおいて、暗号法一式についてすでに獲得している合意を記録してもよい。そして、第2の交渉ターンにおいて再送信されているCREATE_CHILD_SA要求は、SAペイロードの有無にかかわらず、暗号法一式について再交渉しなくてもよい。
イニシエータが、フロー情報を変更し、したがって、CREATE_CHILD_SA要求が、イニシエータと関連する変更されたフロー情報を搬送するTSペイロードを搬送するときに、レスポンダは、CREATE_CHILD_SA応答の中でTSペイロードを搬送するか否かに関して、以下の3つの選択を有してもよい。
第1の選択は、レスポンダと関連するフロー情報に変更がなく、レスポンダと関連する現在使用されているフロー情報が、CREATE_CHILD_SA要求の中で搬送されているとともにイニシエータと関連するフロー情報の中に存在するときに、CREATE_CHILD_SA応答は、TSペイロードを搬送しないということである。
第2の選択は、レスポンダと関連するフロー情報に変更があり、レスポンダが、そのレスポンダと関連するフロー情報として、CREATE_CHILD_SA要求の中で搬送されるとともにイニシエータと関連するフロー情報の中のフロー情報を選択するときに、CREATE_CHILD_SA応答は、TSペイロードを搬送するということである。操作212において説明されているように、レスポンダは、イニシエータが提案するトラフィックのサブセットを選択してもよい、すなわち、イニシエータの提案の何らかのサブセットへと、Traffic Selectorを狭めてもよい。レスポンダは、また、イニシエータに同じTSペイロードを送信してもよい。
第3の選択肢は、CREATE_CHILD_SA要求の中で搬送されるイニシエータが提案したフロー情報とサポートしているフロー情報との間に一致するフロー情報が存在しないときに、CREATE_CHILD_SA応答は、TS受け入れ不可能通知を搬送するということであり、そのTS受け入れ不可能通知は、一致するフロー情報が存在しないということを示す。その次に、イニシエータがその通知を受信した後に、そのイニシエータは、更新されたフロー情報を搬送するTSペイロードを搬送するCREATE_CHILD_SA要求を再送信して、イニシエータ及びレスポンダがフロー情報に関する合意を獲得するまで、レスポンダとフロー情報について再交渉する。フロー情報の再交渉のプロセスについては、必要に応じて、この開示の中で説明されている暗号法一式の交渉又はフロー情報の交渉のシナリオのうちのいずれか1つを参照してもよい。上記で説明されているように、再交渉のプロセスは、暗号法一式の交渉及びフロー情報の交渉を一緒に行ってもよく、又は、暗号法一式の既に獲得されている合意を再交渉することなく、第1の交渉ターンにおいて失敗しているフロー情報の交渉のみを実行してもよい。
操作1016乃至1020の詳細な実装については、図8において説明されている操作716乃至720及び図2において説明されている操作216乃至220を参照してもよい。
IPSec鍵再生成において、このNEW_SPI通知ペイロードは、例えば、最低76バイトを節約することが可能であり、複数の暗号法一式及び/又はTSペイロードによって、節約されるバイト数を比例的に増加させるであろう。このことは、複雑な検証の処理を減少させ、したがって、SAペイロード、TSiペイロード、及びTSrペイロードの処理を減少させる。
図11を参照すると、図11は、例えば、レスポンダが、鍵再生成を実行されるSAを確立するときにレスポンダが現在使用している暗号法一式を変更するといったように、レスポンダが暗号法一式を変更するこの実施形態の第2のシナリオを図示している。
このシナリオにおいては、操作1102乃至1112は、上記と同じ操作である。しかしながら、操作1114においては、CREATE_CHILD_SA応答は、HDRヘッド、提案非選択通知ペイロード、又はTS受け入れ不可能通知ペイロードを搬送する。提案非選択通知ペイロードは、NO_PROPOSAL_CHOSENペイロードであってもよく、そのNO_PROPOSAL_CHOSENペイロードは、CREATE_CHILD_SA要求の中で搬送される暗号法一式の中に一致する暗号法一式が存在しないということを示す。TS受け入れ不可能通知ペイロードは、TS_UNACCEPTABLEペイロードであってもよく、そのTS_UNACCEPTABLEペイロードは、CREATE_CHILD_SA要求の中で搬送されるフロー情報の中に一致するフロー情報が存在しないということを示す。その次に、イニシエータがその指示を受信した後に、そのイニシエータは、更新した暗号法一式を搬送するSAペイロードを搬送するCREATE_CHILD_SA要求を再送信して、イニシエータ及びレスポンダが暗号法一式に関する合意を獲得するまで、レスポンダと暗号法一式について再交渉する。暗号法一式の再交渉のプロセスについては、この開示の中で説明されているシナリオのうちのいずれか1つを参照してもよい。以下では、再交渉のある1つの例を説明する。
操作1116において、イニシエータは、レスポンダに、(第2のCREATE_CHILD_SA要求と呼ばれてもよい)CREATE_CHILD_SA要求を再送信する。
第2のCREATE_CHILD_SA要求は、HDRヘッド、N(REKEY_SA)ペイロード、SAペイロード、Niペイロード、選択的なKEiペイロード、イニシエータがフロー情報を変更するか否かに依存する選択的なTSペイロードを含む。N(REKEY_SA)ペイロードは、いずれのチャイルドSAが鍵再生成を実行されるべきかを示すSPIを搬送する。Niペイロード及びKeiペイロードの内容については、操作212及び操作1012を参照してもよい。SAペイロードは、新たなイニシエータSPI及びイニシエータが提案している1つ又は複数の暗号法一式を搬送するSPIファイルを搬送する。
操作1118において、レスポンダは、イニシエータに、CREATE_CHILD_SA応答を送信する。CREATE_CHILD_SA応答は、HDRヘッド、N(REKEY_SA)ペイロード、NEW_SPI通知ペイロード又はSAペイロード、NRペイロード、(CREATE_CHILD_SA要求がKeiペイロードを搬送しているか否かに依存する)選択的なKEr応答、及び、(レスポンダがレスポンダと関連するフロー情報を変更するか否かに依存する)レスポンダと関連するフロー情報を搬送する選択的なTSペイロードを搬送する。再交渉のプロセスにおいて、暗号法一式の交渉及びフロー情報の交渉は、この開示の中で説明されているように、暗号法一式交渉アプローチ及びフロー情報交渉アプローチのうちのいずれか1つにしたがって実行されてもよいということを理解すべきである。
操作1120, この操作の実装については、上記で説明されている操作216を参照してもよい。
操作1122, イニシエータは、レスポンダに、古いIPSec SAを削除するための古いIPsec SAの削除の要求を送信する。
古いチャイルドの削除の要求は、HDR及びDペイロードを含んでもよい。Dペイロードは、削除されるSAを識別するSPIを含んでもよい。詳細な実装については、操作216を参照してもよい。
操作1124, 古いIPsec SAの削除の要求を受信すると、レスポンダは、イニシエータに、古いIPSec SAの削除の応答を送信する。
古いチャイルドSAの削除の応答は、HDR及びDペイロードを含んでもよい。Dペイロードは、削除されるSAを識別するSPIを含んでもよい。詳細な実装については、操作218を参照してもよい。
上記の再交渉のプロセスは、暗号法一式の交渉及びフロー情報の交渉を一緒に行い、暗号法一式の交渉及びフロー情報の交渉のうちのいずれか一方が失敗するときは、再交渉のプロセスがトリガされ、再交渉のプロセスは、暗号法一式及びフロー情報の双方について再交渉する。上記で説明されているように、暗号法一式の交渉及びフロー情報の交渉は、個別に実行されてもよい。
以下の記載は、第2シナリオにおけるフロー情報の交渉について説明する。
操作1112におけるCREATE_CHILD_SA要求が、イニシエータと関連するフロー情報を搬送するTSペイロードを搬送しないときに、レスポンダは、操作1114におけるCREATE_CHILD_SA応答の中でTSペイロードを搬送するか否かに関して、以下の2つの選択を有してもよい。
第1の選択は、レスポンダと関連するフロー情報に変更がなく、現在使用されているフロー情報が、依然として、鍵再生成の後に、新たなIPSec SAのために使用されているときは、CREATE_CHILD_SA応答は、レスポンダと関連するTSペイロードを搬送しないということである。
第2の選択は、レスポンダと関連するフロー情報に変更があるときに、CREATE_CHILD_SA応答が、TS受け入れ不可能通知を搬送するということである。TS受け入れ不可能通知は、TS_UNACCEPTABLE通知ペイロードであってもよく、そのTS_UNACCEPTABLE通知ペイロードは、イニシエータとレスポンダとの間で情報が一致しないということを示すのに使用される。その次に、イニシエータがTS受け入れ不可能通知を受信した後に、そのイニシエータは、更新したフロー情報を搬送するTSペイロードを搬送するCREATE_CHILD_SA要求を再送信して、イニシエータ及びレスポンダがフロー情報に関する合意を獲得するまで、レスポンダとフロー情報について再交渉する。フロー情報の再交渉のプロセスについては、この開示の中で説明されているように、必要に応じて、暗号法一式の交渉又はフロー情報の交渉のシナリオのうちのいずれか1つを参照してもよい。
暗号法一式の交渉又はフロー情報の交渉のうちのいずれか一方が第1の交渉ターンにおいて失敗するときに、2つの端は、第2の交渉ターンにおいて、暗号法一式の交渉及びフロー情報の交渉の双方について再交渉してもよいということに留意すべきである。その場合には、再送信されたCREATE_CHILD_SA要求は、レスポンダとの間でフロー情報の交渉と共に暗号法一式について再交渉するために、SAペイロードを使用して行われてもよく又はSAペイロードを使用することなく行われてもよい。暗号法一式の詳細については、この開示の中で説明されているように、必要に応じて、IPSec SA暗号法一式のシナリオのうちのいずれか1つを参照してもよい。
暗号法一式の交渉及びフロー情報の交渉は、独立して実行されてもよいということを理解すべきである。その場合には、2つの端は、第1の交渉ターンにおいて、暗号法一式についてすでに獲得している合意を記録してもよい。そして、第2の交渉ターンにおいて再送信されているCREATE_CHILD_SA要求は、SAペイロードの有無にかかわらず、暗号法一式について再交渉しなくてもよい。
更新された暗号法一式又はTS使用する第2の鍵再生成要求の際に、デバイスは、NEW_SPI通知又はLight Weight SAペイロードの中でSPIを再利用することが可能であるか、或いは、新たな暗号法一式を使用する第2の鍵再生成要求の際に新たなSPIを完全に生成することが可能であるか、のいずれかである。このアプローチは、この開示の中で説明されている再交渉のプロセスに適用されてもよい。
イニシエータが、フロー情報を変更し、したがって、CREATE_CHILD_SA要求が、イニシエータと関連する変更されたフロー情報を搬送するTSペイロードを搬送するときに、レスポンダは、CREATE_CHILD_SA応答の中でTSペイロードを搬送するか否かに関して、以下の3つの選択を有してもよい。
第1の選択は、レスポンダと関連するフロー情報に変更がなく、レスポンダと関連する現在使用されているフロー情報が、CREATE_CHILD_SA要求の中で搬送されているとともにイニシエータと関連するフロー情報の中に存在するときに、CREATE_CHILD_SA応答は、TSペイロードを搬送しないということである。
第2の選択は、レスポンダと関連するフロー情報に変更があり、レスポンダが、そのレスポンダと関連するフロー情報として、CREATE_CHILD_SA要求の中で搬送されるとともにイニシエータと関連するフロー情報の中のフロー情報を選択するときに、CREATE_CHILD_SA応答は、TSペイロードを搬送するということである。操作212において説明されているように、レスポンダは、イニシエータが提案するトラフィックのサブセットを選択してもよい、すなわち、イニシエータの提案の何らかのサブセットへと、Traffic Selectorを狭めてもよい。レスポンダは、また、イニシエータに同じTSペイロードを送信してもよい。
第3の選択肢は、CREATE_CHILD_SA要求の中で搬送されるイニシエータが提案したフロー情報とサポートしているフロー情報との間に一致するフロー情報が存在しないときに、CREATE_CHILD_SA応答は、TS受け入れ不可能通知を搬送するということであり、そのTS受け入れ不可能通知は、一致するフロー情報が存在しないということを示す。その次に、イニシエータがその通知を受信した後に、そのイニシエータは、更新されたフロー情報を搬送するTSペイロードを搬送するCREATE_CHILD_SA要求を再送信して、イニシエータ及びレスポンダがフロー情報に関する合意を獲得するまで、レスポンダとフロー情報について再交渉する。フロー情報の再交渉のプロセスについては、必要に応じて、この開示の中で説明されている暗号法一式の交渉又はフロー情報の交渉のシナリオのうちのいずれか1つを参照してもよい。
上記で説明されているように、再交渉のプロセスは、暗号法一式の交渉及びフロー情報の交渉を一緒に行ってもよく、又は、第1の交渉ターンにおいて失敗している交渉のみを実行してもよい。
図12は、本開示のある1つの実施形態にしたがったIPSec SAの鍵再生成の実行のフローチャートである。この実施形態においては、イニシエータは、例えば、脆弱な暗号法一式から、例えば、より高い暗号アルゴリズムセットを使用するより高い暗号法一式等のより強力な暗号法一式に変更するといったように、鍵再生成を実行されるSAを確立するときに使用される暗号法一式を変更する。フロー情報に関しては、イニシエータは、フロー情報を変更してもよく、又は、フロー情報を変更しなくてもよい。イニシエータがフロー情報を変更しない場合には、鍵再生成要求は、TSペイロードを搬送する必要はない。対照的に、イニシエータがフロー情報を変更するときには、鍵再生成要求は、変更されたフロー情報を反映するアドレス範囲、ポート範囲、及びIPプロトコルID等のフロー情報を搬送するであろう。
この実施形態においては3つのシナリオが存在する。第1のシナリオは、レスポンダが、例えば、暗号法一式等の暗号法一式を変更しないというシナリオである。このシナリオにおいては、レスポンダは、イニシエータとの間で暗号法一式について交渉しなくてもよく、軽量鍵再生成アプローチを使用してもよい。例えば、レスポンダは、NEW_SPI通知、Lightweight SAペイロード、又はレスポンダSPIを含む他のペイロードを使用してもよい。第2のシナリオは、レスポンダが暗号法一式を変更するというシナリオである。この場合には、レスポンダは、鍵再生成応答の中で、変更した暗号法一式を搬送するSAペイロードを搬送してもよい。第3のシナリオは、鍵再生成要求の中で搬送される1つ又は複数の暗号法一式が、レスポンダがサポートする暗号法一式と一致しないというシナリオである。この場合には、レスポンダは、通知ペイロードを搬送し、その通知ペイロードは、イニシエータが送信する鍵再生成要求の中で搬送される暗号法一式の中に一致する暗号法一式が存在しないということを示す。その次に、2つの端は、暗号法一式に関する合意を獲得するまで、再度暗号法一式について交渉する。暗号法一式の詳細な交渉については、図9に対応する詳細な説明を参照してもよい。
図12を再び参照すると、図12は、この実施形態にしたがった以下の操作を含むフローチャートを図示している。
操作1202乃至1210の詳細な実装については、図8において説明されている操作802乃至810を参照してもよい。
操作1212, イニシエータは、レスポンダに、IPSec SAの鍵再生成を実行するためのCREATE_CHILD_SA要求を送信する。CREATE_CHILD_SA要求は、HDRヘッド、いずれのチャイルドSAが鍵再生成を実行されるべきであるかを示すSPIを搬送するN(REKEY_SA)ペイロード、1つ又は複数の暗号法一式及び新たなイニシエータSPIを搬送するSAペイロード、Niペイロード、選択的なKEiペイロード、及び(イニシエータがそのイニシエータと関連するフロー情報を変更するか否かに依存する)選択的なTSペイロードを含む。各々のペイロードの中で搬送される詳細な情報については、操作112を参照してもよい。
操作914, レスポンダは、イニシエータに、IPSec SAの鍵再生成を実行するためのCREATE_CHILD_SA応答を送信する。CREATE_CHILD_SA応答は、HDRヘッド、(レスポンダがそのレスポンダと関連する暗号法一式を変更するか否かに依存する)SAペイロード又はNEW_SPI通知ペイロード、Nrペイロード、(CREATE_CHILD_SA要求がKeiペイロードを搬送しているか否かに依存する)選択的なKErペイロード、及び(レスポンダがそのレスポンダと関連するフロー情報を変更するか否かに依存する)選択的なTSペイロードを含む。NEW_SPIペイロードは、新たなレスポンダSPIを搬送し、暗号法一式を搬送しないSPIフィールドを有してもよい。
操作1214においては、レスポンダが、そのレスポンダが現在使用している暗号法一式を変更しない場合であっても、レスポンダは、選択的な手法として、そのレスポンダが現在使用している(すなわち、SAを確立するときにそのレスポンダが使用した)暗号法一式及び新たなレスポンダSPIを搬送するSAペイロードを搬送するCREATE_CHILD_SA応答を送信してもよいということを理解すべきである。
この実施形態の第2のシナリオによれば、レスポンダが、そのレスポンダが現在使用している暗号法一式を変更するときに、CREATE_CHILD_SA応答は、また、イニシエータがサポートする変更された暗号法一式を搬送するSAペイロードを搬送する。
操作1216乃至1218の詳細な実装については、図8において説明されている操作816乃至818及び図2において説明されている操作216乃至218を参照してもよい。
この実施形態の第3のシナリオによれば、CREATE_CHILD_SA要求の中の暗号法一式は、レスポンダが変更することを望む暗号法一式とは一致しない。このシナリオにおいては、レスポンダは、操作1214において、イニシエータに、SAペイロードの代わりに、CREATE_CHILD_SA応答の中で、提案非選択通知ペイロードを送信してもよい。提案非選択通知ペイロードは、NO_PROPOSAL_CHOSENペイロードであってもよく、そのNO_PROPOSAL_CHOSENペイロードは、CREATE_CHILD_SA要求の中で搬送される暗号法一式の中に一致する暗号法一式が存在しないということを示す。その次に、イニシエータがその指示を受信した後に、イニシエータは、更新した暗号法一式を搬送するSAペイロードを搬送するCREATE_CHILD_SA要求を再送信して、イニシエータ及びレスポンダが暗号法一式に関する合意を獲得するまで、レスポンダと暗号法一式について再交渉する。暗号法一式の再交渉のプロセスについては、必要に応じて、この開示の中で説明されているシナリオのうちのいずれか1つを参照してもよい。
以下の記載は、この実施形態におけるフロー情報の交渉を説明する。
操作1212におけるCREATE_CHILD_SA要求が、イニシエータと関連するフロー情報を搬送するTSペイロードを搬送しないときに、レスポンダは、操作1214におけるCREATE_CHILD_SA応答の中でTSペイロードを搬送するか否かに関して、以下の2つの選択を有してもよい。
第1の選択は、レスポンダと関連するフロー情報に変更がなく、現在使用されているフロー情報が、鍵再生成の後に、依然として、新たなIPSec SAのために使用されているときに、CREATE_CHILD_SA応答は、レスポンダと関連するTSペイロードを搬送しないということである。
第2の選択は、レスポンダと関連するフロー情報に変更があるときに、CREATE_CHILD_SA応答が、TS受け入れ不可能通知を搬送するということである。TS受け入れ不可能通知は、TS_UNACCEPTABLE通知ペイロードであってもよく、そのTS_UNACCEPTABLE通知ペイロードは、イニシエータとレスポンダとの間で情報が一致しないということを示すのに使用される。その次に、イニシエータがTS受け入れ不可能通知を受信した後に、そのイニシエータは、更新したフロー情報を搬送するTSペイロードを搬送するCREATE_CHILD_SA要求を再送信して、イニシエータ及びレスポンダがフロー情報に関する合意を獲得するまで、レスポンダとフロー情報について再交渉する。フロー情報の再交渉のプロセスについては、この開示の中で説明されているように、必要に応じて、暗号法一式の交渉又はフロー情報の交渉のアプローチのうちのいずれか1つを参照してもよい。
暗号法一式の交渉又はフロー情報の交渉のうちのいずれか一方が第1の交渉ターンにおいて失敗するときに、2つの端は、第2の交渉ターンにおいて、暗号法一式の交渉及びフロー情報の交渉の双方について再交渉してもよいということに留意すべきである。その場合には、再送信されたCREATE_CHILD_SA要求は、レスポンダとの間でフロー情報の交渉と共に暗号法一式について再交渉するために、SAペイロードを使用して行われてもよく又はSAペイロードを使用することなく行われてもよい。
暗号法一式の交渉及びフロー情報の交渉は、独立して実行されてもよいということを理解すべきである。その場合には、2つの端は、第1の交渉ターンにおいて、暗号法一式についてすでに獲得している合意を記録してもよい。そして、第2の交渉ターンにおいて再送信されているCREATE_CHILD_SA要求は、SAペイロードの有無にかかわらず、暗号法一式について再交渉しなくてもよい。
イニシエータが、フロー情報を変更し、したがって、CREATE_CHILD_SA要求が、イニシエータと関連する変更されたフロー情報を搬送するTSペイロードを搬送するときに、レスポンダは、CREATE_CHILD_SA応答の中でTSペイロードを搬送するか否かに関して、以下の3つの選択を有してもよい。
第1の選択は、レスポンダと関連するフロー情報に変更がなく、レスポンダと関連する現在使用されているフロー情報が、CREATE_CHILD_SA要求の中で搬送されているとともにイニシエータと関連するフロー情報の中に存在するときに、CREATE_CHILD_SA応答は、TSペイロードを搬送しないということである。
第2の選択は、レスポンダと関連するフロー情報に変更があり、レスポンダが、そのレスポンダと関連するフロー情報として、CREATE_CHILD_SA要求の中で搬送されるとともにイニシエータと関連するフロー情報の中のフロー情報を選択するときに、CREATE_CHILD_SA応答は、TSペイロードを搬送するということである。操作212において説明されているように、レスポンダは、イニシエータが提案するトラフィックのサブセットを選択してもよい、すなわち、イニシエータの提案の何らかのサブセットへと、Traffic Selectorを狭めてもよい。レスポンダは、また、イニシエータに同じTSペイロードを送信してもよい。
第3の選択肢は、CREATE_CHILD_SA要求の中で搬送されるイニシエータが提案したフロー情報とサポートしているフロー情報との間に一致するフロー情報が存在しないときに、CREATE_CHILD_SA応答は、TS受け入れ不可能通知を搬送するということであり、そのTS受け入れ不可能通知は、一致するフロー情報が存在しないということを示す。その次に、イニシエータがその通知を受信した後に、そのイニシエータは、更新されたフロー情報を搬送するTSペイロードを搬送するCREATE_CHILD_SA要求を再送信して、イニシエータ及びレスポンダがフロー情報に関する合意を獲得するまで、レスポンダとフロー情報について再交渉する。フロー情報の再交渉のプロセスについては、必要に応じて、この開示の中で説明されている暗号法一式の交渉又はフロー情報の交渉のシナリオのうちのいずれか1つを参照してもよい。
上記で説明されているように、再交渉のプロセスは、暗号法一式の交渉又はフロー情報の交渉を一緒に行ってもよく、或いは、第1の交渉ターンにおいて失敗している交渉のみを実行してもよい。
IPSec鍵再生成において、NEW_SPI通知ペイロードを導入することによって、又は、TSペイロードを搬送しないことによって、各々のIPSec鍵再生成について、IPSec鍵再生成ごとに、例えば、最低76バイトを節約することが可能であり、したがって、複雑な検証の処理を減少させ、また、SAペイロード、TSiペイロード、及びTSrペイロードの処理を減少させる。
図13を参照すると、図13は、この開示のある1つの実施形態にしたがったネットワークデバイス1300の概略的な図を図示している。ネットワークデバイスは、(例えば、上記の実施形態において説明されているイニシエータ等の)第1のネットワークデバイス及び(例えば、上記の実施形態において説明されているレスポンダ等の)第2のネットワークデバイスを含むネットワークシステムにおいてセキュリティアソシエーション(SA)の鍵再生成を実行するように構成され、第1のネットワークデバイスと第2のネットワークデバイスとの間にIKEトンネル及びIPSecトンネルが確立される。この実施形態においては、ネットワークデバイスは、第1のネットワークデバイスとして動作し、ネットワークデバイスは、決定モジュール1302、送信モジュール1304、受信モジュール1306、及び鍵再生成モジュール1308を含む。
決定モジュール1302は、第1のネットワークデバイスと関連する暗号法一式に変更があるか否かを決定するように構成される。送信モジュール1304は、第1のネットワークデバイスと関連する暗号法一式に変更がないときに、第2のネットワークデバイスに、SAの鍵再生成を実行するための第1の鍵再生成要求を送信するように構成され、第1の鍵再生成要求は、第1のSPIを搬送し、第1のネットワークデバイスと関連する暗号法一式を搬送しない。受信モジュール1306は、第2のネットワークデバイスから第1の鍵再生成応答を受信するように構成され、第2のネットワークデバイスと関連する暗号法一式に変更がないときに、第1の鍵再生成応答は、第2のSPIを搬送し、第2のネットワークデバイスと関連する暗号法一式を搬送しない。鍵再生成モジュール1308は、第1のネットワークデバイスと関連する暗号法一式及び第2のネットワークデバイスと関連する暗号法一式に変更がないときに、第1のSPI及び第2のSPIにしたがって、SAの鍵再生成を実行するように構成される。この実施形態のネットワークデバイスにおける各々のモジュールの実装の詳細については、図7及び10の実施形態におけるイニシエータの実装を参照してもよい。
他の実施形態において、ネットワークデバイスは、再交渉モジュール1310をさらに含む。第2のネットワークデバイスと関連する暗号法一式に変更があるときは、第1の鍵再生成応答は、第2のネットワークデバイスからの提案非選択通知を搬送する。再交渉モジュール1310は、交渉された暗号法一式を取得するまで、第2のネットワークデバイスと再交渉するように構成され、鍵再生成モジュール1308は、さらに、再交渉された暗号法一式にしたがって、SAの鍵再生成を実行するように構成される。再交渉モジュール1310は、IPSec SA鍵再生成の場合に、暗号法一式又はフロー情報について再交渉するべきであるか否かを決定するように構成され、再交渉のプロセスは、送信モジュール1304及び受信モジュール1306によって実行されるということを理解すべきである。複数の実施形態のうちのいくつかにおいて、再交渉モジュール1310は、決定モジュール1302に組み込まれてもよい。提案非選択通知のある1つの例は、NO_PROPOSAL_CHOSEN通知ペイロードであってもよい。この実施形態のネットワークデバイスの再交渉の実装の詳細については、図8及び図11の複数の実施形態におけるイニシエータの実装を参照してもよい。
ネットワークデバイス1300は、図1乃至図12の上記の複数の実施形態においてイニシエータが実行する操作を実装することが可能であるということが理解されるであろう。詳細な実装については、上記で説明されている実施形態を参照してもよい。本明細書においては、1つずつ説明する必要はない。
図14を参照すると、図14は、この開示のある1つの実施形態にしたがった他のネットワークデバイス1400の概略的な図を図示している。ネットワークデバイス1400は、(例えば、上記の実施形態において説明されているイニシエータ等の)第1のネットワークデバイス及び(例えば、上記の実施形態において説明されているレスポンダ等の)第2のネットワークデバイスを含むネットワークシステムにおいてセキュリティアソシエーション(SA)の鍵再生成を実行するように構成され、第1のネットワークデバイスと第2のネットワークデバイスとの間にIKEトンネル及びIPSecトンネルが確立される。この実施形態においては、ネットワークデバイスは、第2のネットワークデバイスとして構成され、ネットワークデバイスは、受信モジュール1402、決定モジュール1404、送信モジュール1406、及び鍵再生成モジュール1408を含む。
受信モジュール1402は、第1のネットワークデバイスから、SAの鍵再生成を実行するための第1の鍵再生成要求を受信するように構成され、第1の鍵再生成要求は、第1のSPIを搬送し、第1のネットワークデバイスと関連する暗号法一式を搬送しない。決定モジュール1404は、第2のネットワークデバイスと関連する暗号法一式に変更があるか否かを決定するように構成される。送信モジュール1406は、第1のネットワークデバイスに、第1の鍵再生成応答を送信するように構成され、第2のネットワークデバイスと関連する暗号構成に変更がないときに、第1の鍵再生成応答は、第2のSPIを搬送し、第2のネットワークデバイスと関連する暗号法一式を搬送しない。したがって、鍵再生成モジュール1408は、第1のSPI及び第2のSPIにしたがって、SAの鍵再生成を実行するように構成される。この実施形態のネットワークデバイスにおける各々のモジュールの実装の詳細については、図7及び10の説明を参照してもよい。
ネットワークデバイス1400の他の実施形態において、第2のネットワークデバイスと関連する暗号法一式に変更があるときに、第1の鍵再生成応答は、提案非選択通知を搬送するということである。したがって、受信モジュール1402は、さらに、第1のネットワークデバイスから、SAの鍵再生成を実行するための第2の鍵再生成要求を受信するように構成され、第2の鍵再生成要求は、第1のネットワークデバイスと関連する暗号法一式及び第1のSPIを搬送する。そして、送信モジュール1406は、さらに、第2の鍵再生成要求の中で搬送されるとともに第1のネットワークデバイスと関連する暗号法一式の中に一致する暗号法一式が存在しないということを示す他の提案非選択通知を搬送する第2の鍵再生成応答を送信するように構成される。ネットワークデバイスは、再交渉モジュール1410をさらに含み、再交渉モジュール1410は、交渉された暗号法一式を取得するまで、第1のネットワークデバイスと再交渉するように構成される。したがって、SAの鍵再生成は、さらに、再交渉された暗号法一式にしたがって実行される。再交渉モジュール1410は、IPSec SAの鍵再生成の場合に、暗号法一式又はフロー情報を再交渉するか否かを決定するように構成され、再交渉のプロセスは、送信モジュール1406及び受信モジュール1402によって実行されるということを理解すべきである。複数の実施形態のうちのいくつかにおいて、再交渉モジュール1410は、決定モジュール1404に組み込まれてもよい。この実施形態のネットワークデバイスの再交渉の実装の詳細については、図8及び図11の実施形態におけるイニシエータの実装を参照してもよい。
ネットワークデバイス1400は、図1乃至図12の上記の複数の実施形態においてレスポンダが実行する操作を実装することが可能であるということが理解されるであろう。詳細な実装については、上記で説明されている実施形態を参照してもよい。本明細書においては、1つずつ説明する必要はない。
図15を参照すると、図15は、この開示のある1つの実施形態にしたがった他のネットワークデバイス1500の概略的な図を図示している。ネットワークデバイス1500は、(例えば、上記の実施形態において説明されているイニシエータ等の)第1のネットワークデバイス及び(例えば、上記の実施形態において説明されているレスポンダ等の)第2のネットワークデバイスを含むネットワークシステムにおいてセキュリティアソシエーション(SA)の鍵再生成を実行するように構成され、第1のネットワークデバイスと第2のネットワークデバイスとの間にIKEトンネル及びIPSecトンネルが確立される。この実施形態においては、ネットワークデバイスは、第2のネットワークデバイスとして構成され、ネットワークデバイスは、受信モジュール1502、決定モジュール1504、送信モジュール1506、及び鍵再生成モジュール1508を含む。
受信モジュール1502は、第1のネットワークデバイスから、SAの鍵再生成を実行するための第1の鍵再生成要求を受信するように構成され、第1の鍵再生成要求は、第1のネットワークデバイスと関連する暗号法一式及び第1のSPIを搬送する。決定モジュール1504は、第2のネットワークデバイスと関連する暗号法一式に変更があるか否かを決定するように構成される。送信モジュール1506は、第1のネットワークデバイスに、第1の鍵再生成応答を送信するように構成され、第2のネットワークデバイスと関連する暗号法一式に変更がないときに、第1の鍵再生成応答は、第2のSPIを搬送し、第2のネットワークデバイスと関連する暗号法一式を搬送しない。鍵再生成モジュールは、第1のSPI及び第2のSPIにしたがって、SAの鍵再生成を実行するように構成される。鍵再生成の実装については、例えば、図6乃至12における上記の詳細な説明を参照してもよい。
ネットワークデバイス1500の他の実施形態において、第1の鍵再生成応答は、提案非選択通知を搬送し、その提案非選択通知は、第1の鍵再生成要求の中で搬送されるとともに第1のネットワークデバイスと関連する暗号法一式の中に一致する暗号法一式が存在しないということを示すということである。この場合には、ネットワークデバイス1500は、交渉された暗号法一式を取得するまで、第1のネットワークデバイスと再交渉するように構成される再交渉モジュール1510をさらに含む。したがって、SAは、さらに、交渉された暗号法一式にしたがって、鍵再生成を実行される。当業者は、再交渉モジュール1510が、IPSec SA鍵再生成の場合に、暗号法一式又はフロー情報について再交渉するか否かを決定するように構成され、再交渉のプロセスは、送信モジュール1506及び受信モジュール1502によって実行されるということを理解するであろう。複数の実施形態のうちのいくつかにおいて、再交渉モジュール1510は、決定モジュール1504に組み込まれてもよい。上記の実施形態のネットワークデバイス1500における再交渉の実装の詳細については、図9及び図12の実施形態におけるレスポンダの実装を参照してもよい。
当業者は、ネットワークデバイス1500が、図1乃至図12の上記の複数の実施形態においてレスポンダが実行する操作を実装することが可能であるということが理解するであろう。詳細な実装については、上記で説明されている実施形態を参照してもよい。本明細書においては、1つずつ説明する必要はない。
図16を参照すると、図16は、この開示のある1つの実施形態にしたがった他のネットワークデバイス1600の概略的な図を図示している。ネットワークデバイス1600は、(例えば、上記の実施形態において説明されているイニシエータ等の)第1のネットワークデバイス及び(例えば、上記の実施形態において説明されているレスポンダ等の)第2のネットワークデバイスを含むネットワークシステムにおいてセキュリティアソシエーション(SA)の鍵再生成を実行するように構成され、第1のネットワークデバイスと第2のネットワークデバイスとの間にIKEトンネル及びIPSecトンネルが確立される。複数の実施形態のうちのいくつかにおいて、ネットワークデバイス1600は、図1乃至12の実施形態において説明されているように、イニシエータとして動作してもよく、図1乃至12の実施形態において説明されているイニシエータの操作を実行してもよい。他の実施形態においては、ネットワークデバイス1600は、図1乃至12の実施形態において説明されているようにレスポンダとして動作してもよく、図1乃至12の実施形態において説明されているレスポンダの操作を実行してもよい。
ネットワークデバイスは、プロセッサ1602、プロセッサ1602に結合されるメモリ1604、トランシーバー(Tx/Rx)1606、及びTx/Rx1606に結合されるポート1608を含む。プロセッサ1602は、汎用プロセッサとして実装されてもよく、或いは、1つ又は複数の特定用途向け集積回路(ASIC)及び/又はディジタル信号プロセッサ(DSP)の部分であってもよい。プロセッサ1602は、単一のプロセス又は複数のプロセッサを指してもよい。メモリ1604は、例えば、ランダムアクセスメモリ(RAM)等のコンテンツを一時的に格納するためのキャッシュを含んでもよい。追加的に、メモリ1604は、例えば、読み取り専用メモリ(ROM)等の長期間記憶装置を含んでもよい。イニシエータとして動作するときに、プロセッサ1602は、図1乃至12の複数の実施形態において説明されているイニシエータの操作を実行するように構成される。レスポンダとして動作するときに、プロセッサ1602は、図1乃至12の複数の実施形態において説明されているレスポンダの操作を実行するように構成される。
さらに、ある1つの実施形態において、メモリ1604は、図13の複数の実施形態において説明されている複数のモジュール等の複数のソフトウェアモジュールを含んでもよい。他の実施形態においては、メモリ1604は、図14の複数の実施形態において説明されている複数のモジュール等の複数のソフトウェアモジュールを含んでもよい。さらなる実施形態においては、メモリ1604は、図15の複数の実施形態において説明されている複数のモジュール等の複数のソフトウェアモジュールを含んでもよい。
プロセッサ1602は、複数のソフトウェアモジュールの複数の命令を実行することによって、複数の操作を実行することが可能である。複数の実施形態のうちのいくつかにおいて、モジュールがある1つの操作を実行するように構成されるときに、そのことは、実際には、プロセッサ1602が、モジュールの中で複数の命令を実行して、その操作を実行するように構成されるということを意味してもよい。プロセッサ1602は、メモリ1604の中の複数の命令を実行することによって、図1乃至12において説明されているイニシエータ又はレスポンダが実行する操作のすべてを完全に又は部分的に実行することが可能である。
図17を参照すると、図17は、ネットワークシステム1700の概略的な図を図示している。ネットワークシステム1700は、少なくとも第1のネットワークデバイス1702(すなわち、イニシエータ)及び第2のネットワークデバイス1704(すなわち、レスポンダ)を含んでもよい。第1のネットワークデバイス1702は、図13の実施形態において説明されているネットワークデバイス1300であってもよい。第2のネットワークデバイス1704は、図14及び15の実施形態において説明されているネットワークデバイス1400又はネットワークデバイス1500であってもよい。他の実施形態においては、第1のネットワークデバイスは、ネットワークデバイス1600であってもよく、そのネットワークデバイス1600は、図1乃至12の複数の実施形態において説明されているイニシエータとして動作し、そして、図1乃至12の複数の実施形態において説明されているイニシエータの操作を実行する。また、第2のネットワークデバイスは、ネットワークデバイス1600であってもよく、そのネットワークデバイス1600は、図1乃至12の複数の実施形態において説明されているレスポンダとして動作し、そして、図1乃至12の複数の実施形態において説明されているレスポンダの操作を実行する。
当業者は、この開示を読んだ後に、本開示の実装のためにいずれかの既知の又は新たなアルゴリズムを使用してもよいということを理解することが可能である。しかしながら、この開示は、いずれかの既知の又は新たなアルゴリズムを使用するか否かにかかわらず、上記で言及している利点及び技術的進歩を達成する方法を提供するということに留意すべきである。
当業者は、この開示を読んだ後に、この明細書の中で開示されている複数の実施形態において説明されている複数の例に関して、電子的なハードウェアによって、又は、コンピュータソフトウェア及び電子的なハードウェアの組み合わせによって、複数のユニット及び複数のアルゴリズムのステップを実装してもよいということを認識することが可能である。複数の機能がハードウェアによって実行されるか又はソフトウェアによって実行されるかは、特定の発明及び技術的解決方法の設計上の制約条件に依存する。この開示を読んだ後に、当業者は、複数の異なる方法を使用して、各々の特定の発明について説明されている複数の機能を実装してもよいが、その実装は、本開示の範囲を超えるものであると解釈されるべきではない。
本開示によって提供されるいくつかの実施形態において、開示されているシステム及び方法は、他の方式によって実装されてもよいということを理解すべきである。例えば、説明されているネットワークデバイスの実施形態は、例示的なものであるにすぎない。例えば、ユニットの分割は、論理的且つ機能的な分割であるにすぎず、実際の実装においては他の分割であってもよい。例えば、複数のユニット又はモジュールを組み合わせ又は一体化して、他のシステムとしてもよく、或いは、いくつかの特徴を無視してもよく、又は、実行しなくてもよい。加えて、いくつかのインターフェイスを使用して、示され又は説明されている相互の結合、直接的な結合、又は通信接続を実装してもよい。電子的な形態、機械的な形態、又は他の形態によって、複数の装置又は複数のユニットの間の間接的な結合又は通信接続を実装してもよい。
それらの複数の機能が、ソフトウェア機能ユニットの形態で実装され、そして、独立した製品として販売され又は使用されるときに、それらの複数の機能は、コンピュータ読み取り可能な記憶媒体の中に格納されてもよい。それらの複数の機能は、コンピュータプログラム製品を形成するコンピュータコードで表現されてもよく、それらのコードは、それらの複数の機能を実行するように適切なハードウェアに指示してもよい。そのような理解に基づいて、本開示の複数の技術的解決方法は、本質的に、或いは、先行技術に寄与する部分又はそれらの複数の技術的解決方法の一部は、ソフトウェア製品の形態で実装されてもよい。コンピュータソフトウェア製品は、記憶媒体の中に格納され、そして、いくつかの命令を含み、それらのいくつかの命令は、本開示のそれらの複数の実施形態において説明されている複数の方法の複数のステップのすべて又は一部を実行するように、(パーソナルコンピュータ、サーバ、又はネットワークノード、すなわち、プロセッサであってもよい)コンピュータノードに指示する。上記の記憶媒体は、プログラムコードを格納することが可能であるUSBフラッシュドライブ、取り外し可能なハードディスク、読み取り専用メモリ(Read-Only Memory, ROM)、ランダムアクセスメモリ(Random Access Memory, RAM)、磁気ディスク、又は光ディスク等のいずれかの媒体を含む。
互いに通信している複数のデバイスは、特に明記しない限り、互いに連続的に通信している必要はない。加えて、互いに通信している複数のデバイスは、1つ又は複数の手段を通じて直接的に又は間接的に通信してもよい。
単一のデバイス又は物品が、本明細書において説明されるときに、単一のデバイス/物品の代わりに、(それらが協働するか否かにかかわらず)1つよりも多くのデバイス/物品を使用してもよいということが容易に明らかとなるであろう。同様に、(それらが協働するか否かにかかわらず)1つよりも多くのデバイス又は物品が、本明細書において説明される場合に、1つよりも多くのデバイス又は物品の代わりに、単一のデバイス/物品を使用してもよく、或いは、示された数のデバイス又はプログラムの代わりに、異なる数のデバイス/物品を使用してもよいということが容易に明らかとなるであろう。あるデバイスの機能及び/又は特徴は、代替的に、そのような機能/特徴を有するものとして明示的に説明されてはいない1つ又は複数の他のデバイスによって具体化されてもよい。したがって、本発明の他の実施形態は、そのデバイス自体を含む必要はない。
[関連出願への相互参照]
この出願は、2018年11月15日に出願された"セキュリティアソシエーションSAの鍵再生成"と題するインド特許出願第IN201831042965号に基づく優先権を主張し、その内容は、その全体が参照により本明細書に組み込まれる。
本明細書における開示は、一般的に、遠隔通信に関し、より具体的には、インターネットセキュリティプロトコルに関し、そして、さらにいっそう具体的には、制限された電力、帯域幅、及び/又は処理能力を有するモバイルデバイス等のためのセキュリティアソシエーションを鍵再生成するための方法、デバイス、システムに関する。
インターネット鍵交換バージョン2(IKEv2)は、RFC7296によって定義されるプロトコルであり、IKEv2は、本明細書における明示的な開示に反する場合を除き、本明細書に完全に記載されているかのように、すべての目的のために参照により本明細書に組み込まれている。本明細書において使用される複数の語は、本明細書における明示的な開示に反する場合を除き、RFC7296によって与えられる意味を有する。
IKEv2は、IPSecプロトコル一式によってセキュリティアソシエーション(SA)をセットアップするのに使用される。セキュリティアソシエーションSAは、IKEトンネル又はIPsecトンネルであってもよい。インターネットプロトコルセキュリティ(IPsec)は、ネットワークを介して送信されるデータのパケットを認証し及び暗号化するネットワークプロトコル一式である。
IKEメッセージフローは、要求及びその要求に続く応答を含む。信頼性を保証することは、要求側の責任である。タイムアウト間隔の中でその応答を受信しない場合には、要求側は、その要求を再送信する必要がある(又は、その接続を放棄する必要がある)。IKEセッションの要求側とレスポンダとの間の最初の要求/応答メッセージ対(IKE_SA_INIT)は、IKE_SAのためのセキュリティパラメータを交渉し、ノンスを送信し、そして、複数のDiffie-Hellman値を送信する。2番目の要求/応答メッセージ対(IKE_AUTH)は、複数の識別子を送信し、それらの2つの識別子に対応する秘密の知識を証明し、そして、最初の(及び、最初のみのことが多い)認証ヘッダー(AH)及び/又はカプセル化セキュリティペイロード(ESP) CHILD_SAのためのSAをセットアップする。
IKEv2のIKE鍵再生成手順は、RFC7296によって定義され、RFC7296は、本明細書における明示的な開示に反する場合を除き、本明細書に完全に記載されているかのように、すべての目的のために参照により本明細書に組み込まれている。本明細書において使用される複数の語は、本明細書における明示的な開示に反する場合を除き、RFC7296によって与えられる意味を有する。
定義によれば、鍵再生成は、SAの期限が切れる前に、期限が切れるそのSAの代わりとなる新たなSAを作成することである。
例えば、要求側とレスポンダとの間のIKE鍵再生成のやりとりは、1つ又は複数のSAペイロードを搬送し、それらのSAペイロードは、それら自体が1つ又は複数の提案ペイロードを含む。各々の提案は、暗号法一式の単一のセット(例えば、単一の又は複数の暗号法一式)を含む。通常は、これらの一式は、鍵再生成の時点においては変更されない。(例えば、暗号法一式の単一セットの場合に)SAペイロードの最小サイズは、通常、52バイトである。IKE鍵再生成の場合には、最小の可能なサイズは、44バイトである。この最小の可能なサイズは、44バイトのSAペイロードサイズ及び40バイトの提案サイズを含んでもよい。その最小値は、選択されそしてSAペイロードの中で送信される暗号法一式のタイプ及び数によって決定される。
SAペイロード構造は、通常、SAペイロード、提案、及び、変換及び属性を含む。SAペイロードの内側には、プロトコルID及びSPIを含む1つ又は1つよりも多くの提案ペイロードが存在し、提案ペイロードの内側には、暗号アルゴリズムを含む変換及び選択的に鍵の長さを含む属性が存在するであろう。例えば、複数の属性を指定することによって、さらにある特定の提案を定義すると、SAペイロードのサイズを増加させるであろう。当業者は、従来のSAペイロードがRFC7296の3.3節において詳細に開示されているということを理解するであろう。
例えば、要求側とレスポンダとの間のIPSec鍵再生成のやりとりは、また、暗号法一式(例えば、単一の又は複数の暗号法一式)を含むSAペイロード及びそれらとともに(TSiペイロード及びTSrペイロード等の)TSペイロードを搬送する。ほとんどの場合に、これらのペイロードは、IKE鍵再生成手順と同様に、鍵再生成の時点においては変更されない。通常、SAペイロードの最小サイズは、40バイトであり、各々のTSサイズは、24バイト(2*24=48バイト)である。
図1Aは、従来のSAペイロードの構造の複数の例のうちのいくつかを提供する。最初のSAペイロードは、属性を含まず、2番目のSAペイロードは、属性を含み、それらの2つのSAペイロードの各々は、1つの提案を含む。3番目のSAペイロードは、各々が属性を含む2つの提案を含む。
ペイロードサイズは、IKE及び/又はIPSec SAの鍵再生成を実行する際に、複数の暗号法一式に対して比例的に増加する。この鍵再生成は、周期的にトリガされる。各々の鍵再生成は、帯域幅及び電力を消費して、これらのペイロードを処理する。
セキュリティアソシエーションの鍵再生成のための方法、デバイス、及びシステムに関連する概念を紹介するためにこの要約を提供する。さらに、既知のSA鍵再生成プロセスにおいて交換される既存のタイプのメッセージを変更する。さらに、SA鍵再生成プロセスのための新たなメッセージを導入する。この開示は、IKEv2を参照して議論されるが、他の鍵再生成メカニズムにも等しく本発明を適用することが可能であるというということが理解されるであろう。
第1の態様によれば、この出願のある1つの実施形態は、第1のネットワークデバイス及び第2のネットワークデバイスを含むネットワークシステムにおいてセキュリティアソシエーション(SA)の鍵再生成を実行するための方法であって、前記第1のネットワークデバイスと前記第2のネットワークデバイスとの間に、インターネット鍵交換(IKE)トンネル及びインターネットプロトコルセキュリティ(IPSec)トンネルが確立される、方法を提供する。当該方法において、前記第1のネットワークデバイスは、前記第1のネットワークデバイスと関連する暗号法一式に変更があるか否かを決定し、そして、その決定の結果が、前記第1のネットワークデバイスと関連する前記暗号法一式に変更がないということであるときに、前記第2のネットワークデバイスに、SAの鍵再生成を実行するための第1の鍵再生成要求を送信する。前記第1の鍵再生成要求は、第1のセキュリティパラメータインデックス(SPI)を搬送し、前記第1のネットワークデバイスと関連する暗号法一式を搬送しない。その次に、前記第1のネットワークデバイスは、前記第1のネットワークデバイスと関連する前記暗号法一式及び前記第2のネットワークデバイスと関連する前記暗号法一式に変更がないときに、前記第1のSPI及び前記第2のSPIにしたがって、前記SAの鍵再生成を実行する。具体的には、前記第1のネットワークデバイスは、前記第1のSPI、前記第2のSPI、及び鍵再生成を実行するべき前記SAのために使用される前記暗号法一式にしたがって、前記SAの鍵再生成を実行する。
上記の技術的解決方法においては、鍵再生成要求及び鍵再生成応答の中で暗号法一式を搬送しないことによって、鍵再生成の場合にペイロードのサイズを減少させることにより、例えば、IKE SA鍵再生成又はIPSec SA鍵再生成のうちのいずれについても、SA鍵再生成の過程において、帯域幅、より多くの処理時間、及び電力を節約する。
第1の態様に関して、第1の可能な実装において、前記SAが前記IKE SAのチャイルドSAである前記IPSec SAである場合に、前記第1のネットワークデバイスと関連するフロー情報に変更があるときは、前記第1の鍵再生成要求は、前記第1のネットワークデバイスと関連するフロー情報を搬送するTSペイロードを搬送しない。前記第2のネットワークデバイスと関連するフロー情報に変更がないときは、前記第1の鍵再生成応答は、前記第2のネットワークデバイスと関連するフロー情報を搬送するTSペイロードを搬送しない。したがって、第1のネットワークデバイスは、第1のネットワークデバイスと関連するフロー情報及び第2のネットワークデバイスと関連するフロー情報を変更することなく、SAの鍵再生成を実行する。
上記のIPSEC鍵再生成のシナリオにおいては、鍵再生成要求及び鍵再生成応答の中でTSペイロード(TSiペイロード及びTSrペイロード)を搬送しないことによって、さらに、ペイロードを減少させる。IPSEC SAにおける複数の暗号法一式について、ペイロードサイズを比例的に減少させるであろう。軽量ペイロードは、さらに、IPSec鍵再生成の際に、帯域幅、処理時間、及び電力を節約することが可能である。
第1の態様に関して、第2の可能な実装において、前記SAが前記IKE SAであり、前記第1の鍵再生成要求が、前記IKE SAの鍵再生成を実行するためのCREATE_CHILD_SA要求であり、前記CREATE_CHILD_SA要求が、前記第1のSPIを搬送するNEW_SPI通知ペイロードを搬送するか、又は、前記第1のSPIを搬送するLightweight SAペイロードを搬送し、そして、前記第1の鍵再生成応答が、前記IKE SAの鍵再生成を実行するためのCREATE_CHILD_SA応答であるときに、前記CREATE_CHILD_SA応答は、前記第2のSPIを搬送する他のNEW_SPI通知ペイロードを搬送するか、又は、前記第2のSPIを搬送する他のLightweight SAペイロードを搬送する。したがって、前記SAが、前記IKE SAのチャイルドSAである前記IPSec SAであり、前記第1の鍵再生成要求が、チャイルドSAの鍵再生成を実行するためのCREATE_CHILD_SA要求であり、前記CREATE_CHILD_SA要求が、前記第1のSPIを搬送するNEW_SPI通知ペイロードを搬送するか、又は、前記第1のSPIを搬送するLightweight SAペイロードを搬送し、そして、前記第1の鍵再生成応答が、前記チャイルドSAの鍵再生成を実行するためのCREATE_CHILD_SA応答であるときに、前記CREATE_CHILD_SA応答は、前記第2のSPIを搬送する前記NEW_SPI通知ペイロードを搬送するか、又は、前記第2のSPIを搬送する他のLightweight SAペイロードを搬送する。
この実施形態において説明されている軽量鍵再生成アプローチを使用することによって、このNEW_SPI通知ペイロード又はLightweight SAペイロードは、例えば、最低36バイトを節約することが可能であり、複数の暗号法一式において、節約されるバイトの数を比例的に増加させ、このことは、複雑な検証の処理を減少させ、したがって、IKE鍵再生成又はIPSec鍵再生成のやりとりにおけるSAペイロードの処理を減少させる。例えば、NEW_SPI通知ペイロードのサイズは、12乃至16バイトの範囲にあってもよい。
第2の態様によれば、この出願のある1つの実施形態は、第1のネットワークデバイス及び第2のネットワークデバイスを含むネットワークシステムに適用されるセキュリティアソシエーション(SA)の鍵再生成を実行するための方法であって、前記第2のネットワークデバイスと第1のネットワークデバイスとの間に、インターネット鍵交換(IKE)及びインターネットプロトコルセキュリティ(IPSec)トンネルが確立される方法を提供する。当該方法において、前記第2のネットワークデバイスは、前記第1のネットワークデバイスから、SAの鍵再生成を実行するための第1の鍵再生成要求を受信する。前記第1の鍵再生成要求は、第1のセキュリティパラメータインデックス(SPI)を搬送し、第1のネットワークデバイスと関連する暗号法一式を搬送しない。前記第2のネットワークデバイスは、前記第2のネットワークデバイスと関連する暗号法一式に変更があるか否かを決定する。前記第2のネットワークが、前記第2のネットワークデバイスと関連する前記暗号法一式に変更がないということを決定するときに、前記第2のネットワークデバイスは、前記第2のネットワークデバイスと関連する暗号法一式を搬送することなく、第2のSPIを搬送する第1の鍵再生成応答を送信する。そして、前記第1のSPI及び前記第2のSPIにしたがって、前記SAの鍵再生成を実行する。
上記の技術的解決方法においては、鍵再生成要求及び鍵再生成応答の中で暗号法一式を搬送しないことによって、鍵再生成の場合にペイロードのサイズを減少させることにより、例えば、IKE SA鍵再生成又はIPSec SA鍵再生成のうちのいずれについても、SA鍵再生成の過程において、帯域幅、より多くの処理時間、及び電力を節約する。
第2の態様に関して、第1の可能な実装において、前記SAがIKE SAのチャイルドSAである前記IPSec SAである場合に、前記第1のネットワークデバイスと関連するフロー情報に変更があるときは、前記第1の鍵再生成要求は、前記第1のネットワークデバイスと関連するフロー情報を搬送するTSペイロードを搬送しない。前記第2のネットワークデバイスと関連するフロー情報に変更がないときは、前記第1の鍵再生成応答は、前記第2のネットワークデバイスと関連するフロー情報を搬送するTSペイロードを搬送しない。したがって、第1のネットワークデバイスと関連するフロー情報及び第2のネットワークデバイスと関連するフロー情報を変更することにより、SAの鍵再生成を実行する。
上記のIPSEC鍵再生成のシナリオにおいては、鍵再生成要求及び鍵再生成応答の中でTSペイロード(TSiペイロード及びTSrペイロード)を搬送しないことによって、さらに、ペイロードを減少させる。IPSEC SAにおける複数の暗号法一式について、ペイロードサイズを比例的に減少させるであろう。軽量ペイロードは、さらに、IPSec鍵再生成の際に、帯域幅、処理時間、及び電力を節約することが可能である。
第3の態様によれば、この出願のある1つの実施形態は、第1のネットワークデバイス及び第2のネットワークデバイスを含むネットワークシステムにおいてセキュリティアソシエーション(SA)の鍵再生成を実行するためのネットワークデバイスを提供する。前記第1のネットワークデバイスと前記第2のネットワークデバイスとの間に、インターネット鍵交換(IKE)及びインターネットプロトコルセキュリティ(IPSec)トンネルが確立され、当該ネットワークデバイスは、前記第1のネットワークデバイスとして構成される。当該ネットワークデバイスは、決定モジュール、送信モジュール、受信モジュール、及び鍵再生成モジュールを含む。前記決定モジュールは、前記第1のネットワークデバイスと関連する暗号法一式に変更があるか否かを決定するように構成される。前記送信モジュールは、前記第1のネットワークデバイスと関連する前記暗号法一式に変更がないときに、前記第2のネットワークデバイスに、SAの鍵再生成を実行するための第1の鍵再生成要求を送信するように構成され、前記第1の鍵再生成要求は、第1のセキュリティパラメータインデックス(SPI)を搬送し、前記第1のネットワークデバイスと関連する暗号法一式を搬送しない。前記受信モジュールは、前記第2のネットワークデバイスから第1の鍵再生成応答を受信するように構成される。前記第2のネットワークデバイスと関連する暗号法一式に変更がないときに、前記第1の鍵再生成応答は、第2のSPIを搬送し、前記第2のネットワークデバイスと関連する暗号法一式を搬送しない。鍵再生成モジュールは、前記第1のネットワークデバイスと関連する前記暗号法一式及び前記第2のネットワークデバイスと関連する前記暗号法一式に変更がないときに、前記第1のSPI及び前記第2のSPIにしたがって、前記SAの鍵再生成を実行するように構成される。
上記の技術的解決方法においては、鍵再生成要求及び鍵再生成応答の中で暗号法一式を搬送しないことによって、鍵再生成の場合にペイロードのサイズを減少させることにより、例えば、IKE SA鍵再生成又はIPSec SA鍵再生成のうちのいずれについても、SA鍵再生成の過程において、帯域幅、より多くの処理時間、及び電力を節約する。IKE鍵再生成のシナリオ及びIPSEC SA鍵再生成のシナリオの双方における鍵再生成の際に、複数の暗号法一式の場合に、ペイロードサイズを比例的に減少させるであろう。
第4の態様によれば、この出願のある1つの実施形態は、第1のネットワークデバイス及び第2のネットワークデバイスを含むネットワークシステムにおいてセキュリティアソシエーション(SA)の鍵再生成を実行するためのネットワークデバイスを提供する。前記第1のネットワークデバイスと前記第2のネットワークデバイスとの間に、インターネット鍵交換(IKE)及びインターネットプロトコルセキュリティ(IPSec)トンネルが確立され、当該ネットワークデバイスは、前記第2のネットワークデバイスとして構成される。当該ネットワークデバイスは、受信モジュール、決定モジュール、及び送信モジュールを含む。前記受信モジュールは、前記第1のネットワークデバイスから、SAの鍵再生成を実行するための第1の鍵再生成要求を受信するように構成される。前記第1の鍵再生成要求は、第1のセキュリティパラメータインデックス(SPI)を搬送し、前記第1のネットワークデバイスと関連する暗号法一式を搬送しない。前記決定モジュールは、前記第2のネットワークデバイスと関連する暗号法一式に変更があるか否かを決定するように構成される。前記送信モジュールは、前記第1のネットワークデバイスに、第1の鍵再生成応答を送信するように構成される。前記第2のネットワークデバイスと関連する前記暗号構成に変更がないときに、前記第1の鍵再生成応答は、第2のSPIを搬送し、前記第2のネットワークデバイスと関連する暗号法一式を搬送しない。前記SAの鍵再生成は、前記第1のSPI及び前記第2のSPIにしたがって実行される。
上記の技術的解決方法においては、鍵再生成要求及び鍵再生成応答の中で暗号法一式を搬送しないことによって、鍵再生成の場合にペイロードのサイズを減少させることにより、例えば、IKE SA鍵再生成又はIPSec SA鍵再生成のうちのいずれについても、SA鍵再生成の過程において、帯域幅、より多くの処理時間、及び電力を節約する。IKE鍵再生成のシナリオ及びIPSEC SA鍵再生成のシナリオの双方における鍵再生成の際に、複数の暗号法一式の場合に、ペイロードサイズを比例的に減少させるであろう。
第5の態様によれば、この出願のある1つの実施形態は、セキュリティアソシエーション(SA)の鍵再生成を実行するためのネットワークシステムを提供し、当該ネットワークシステムは、上記で説明されているように、この出願の第3の態様にしたがった第1のネットワークデバイス及びこの出願の第4の態様にしたがった第2のネットワークデバイスを含む。
上記の技術的解決方法においては、鍵再生成要求及び鍵再生成応答の中で暗号法一式を搬送しないことによって、鍵再生成の場合にペイロードのサイズを減少させることにより、例えば、IKE SA鍵再生成又はIPSec SA鍵再生成のうちのいずれについても、SA鍵再生成の過程において、帯域幅、より多くの処理時間、及び電力を節約する。IKE鍵再生成のシナリオ及びIPSEC SA鍵再生成のシナリオの双方における鍵再生成の際に、複数の暗号法一式の場合に、ペイロードサイズを比例的に減少させるであろう。
第6の態様によれば、この出願のある1つの実施形態は、第1のネットワークデバイス及び第2のネットワークデバイスを含むネットワークシステムにおいてセキュリティアソシエーション(SA)の鍵再生成を実行するためのネットワークデバイスを提供する。前記第1のネットワークデバイスと前記第2のネットワークデバイスとの間に、インターネット鍵交換(IKE)及びインターネットプロトコルセキュリティ(IPSec)トンネルが確立され、当該ネットワークデバイスは、前記第1のネットワークデバイスとして構成される。当該ネットワークデバイスは、プロセッサ及びメモリを含む。前記メモリは、ソフトウェアの命令を格納するように構成される。前記プロセッサは、前記メモリの中のソフトウェアの前記命令を実行して、当該ネットワークデバイスが、前記第1のネットワークデバイスと関連する暗号法一式に変更があるか否かを決定し、前記第1のネットワークデバイスと関連する前記暗号法一式に変更がないときに、前記第2のネットワークデバイスに、SAの鍵再生成を実行するための第1の鍵再生成要求を送信し、前記第1の鍵再生成要求は、第1のセキュリティパラメータインデックス(SPI)を搬送し、前記第1のネットワークデバイスと関連する暗号法一式を搬送せず、前記第2のネットワークデバイスと関連する暗号法一式に変更がないときに、前記第2のネットワークデバイスと関連する暗号法一式を搬送せずに、第2のSPIを搬送する第1の鍵再生成応答を受信し、前記第1のネットワークデバイスと関連する前記暗号法一式及び前記第2のネットワークデバイスと関連する前記暗号法一式に変更がないときに、前記第1のSPI及び前記第2のSPIにしたがって、前記SAの鍵再生成を実行する、ように構成される。
上記の技術的解決方法においては、鍵再生成要求及び鍵再生成応答の中で暗号法一式を搬送しないことによって、鍵再生成の場合にペイロードのサイズを減少させることにより、例えば、IKE SA鍵再生成又はIPSec SA鍵再生成のうちのいずれについても、SA鍵再生成の過程において、帯域幅、より多くの処理時間、及び電力を節約する。IKE鍵再生成のシナリオ及びIPSEC SA鍵再生成のシナリオの双方における鍵再生成の際に、複数の暗号法一式の場合に、ペイロードサイズを比例的に減少させるであろう。
第7の態様によれば、この出願のある1つの実施形態は、第1のネットワークデバイス及び第2のネットワークデバイスを含むネットワークシステムにおいてセキュリティアソシエーション(SA)の鍵再生成を実行するためのネットワークデバイスを提供する。前記第1のネットワークデバイスと前記第2のネットワークデバイスとの間に、インターネット鍵交換(IKE)及びインターネットプロトコルセキュリティ(IPSec)トンネルが確立され、当該ネットワークデバイスは、前記第2のネットワークデバイスとして構成される。当該ネットワークデバイスは、プロセッサ及びメモリを含む。前記メモリは、ソフトウェアの命令を格納するように構成される。前記プロセッサは、前記メモリの中のソフトウェアの前記命令を実行して、当該ネットワークデバイスが、前記第1のネットワークデバイスから、SAの鍵再生成を実行するための第1の鍵再生成要求を受信し、前記第1の鍵再生成要求は、第1のセキュリティパラメータインデックス(SPI)を搬送し、前記第1のネットワークデバイスと関連する暗号法一式を搬送せず、前記第2のネットワークデバイスと関連する暗号法一式に変更があるか否かを決定し、前記第1のネットワークデバイスに、第1の鍵再生成応答を送信し、前記第2のネットワークデバイスと関連する前記暗号構成に変更がないときに、前記第1の鍵再生成応答は、第2のSPIを搬送し、前記第2のネットワークデバイスと関連する暗号法一式を搬送しない、ように構成される。前記SAの鍵再生成は、前記第1のSPI及び前記第2のSPIにしたがって実行される。
上記の技術的解決方法においては、鍵再生成要求及び鍵再生成応答の中で暗号法一式を搬送しないことによって、鍵再生成の場合にペイロードのサイズを減少させることにより、例えば、IKE SA鍵再生成又はIPSec SA鍵再生成のうちのいずれについても、SA鍵再生成の過程において、帯域幅、より多くの処理時間、及び電力を節約する。IKE鍵再生成のシナリオ及びIPSEC SA鍵再生成のシナリオの双方における鍵再生成の際に、複数の暗号法一式の場合に、ペイロードサイズを比例的に減少させるであろう。
第8の態様によれば、この出願のある1つの実施形態は、セキュリティアソシエーション(SA)の鍵再生成を実行するためのネットワークシステムを提供し、当該ネットワークシステムは、上記で説明されているように、この出願の第6の態様にしたがった第1のネットワークデバイス及びこの出願の第7の態様にしたがった第2のネットワークデバイスを含む。
上記の技術的解決方法においては、鍵再生成要求及び鍵再生成応答の中で暗号法一式を搬送しないことによって、鍵再生成の場合にペイロードのサイズを減少させることにより、例えば、IKE SA鍵再生成又はIPSec SA鍵再生成のうちのいずれについても、SA鍵再生成の過程において、帯域幅、より多くの処理時間、及び電力を節約する。IKE鍵再生成のシナリオ及びIPSEC SA鍵再生成のシナリオの双方における鍵再生成の際に、複数の暗号法一式の場合に、ペイロードサイズを比例的に減少させるであろう。
第9の態様によれば、この出願のある1つの実施形態は、コンピュータ読み取り可能な記憶媒体を提供する。そのコンピュータ読み取り可能な記憶媒体は、上記で説明されているように、第1の態様又は第2の態様にしたがった方法を実行するのに使用されるコンピュータソフトウェア命令を格納するように構成される。
上記の技術的解決方法においては、鍵再生成要求及び鍵再生成応答の中で暗号法一式を搬送しないことによって、鍵再生成の場合にペイロードのサイズを減少させることにより、例えば、IKE SA鍵再生成又はIPSec SA鍵再生成のうちのいずれについても、SA鍵再生成の過程において、帯域幅、より多くの処理時間、及び電力を節約する。IKE鍵再生成のシナリオ及びIPSEC SA鍵再生成のシナリオの双方における鍵再生成の際に、複数の暗号法一式の場合に、ペイロードサイズを比例的に減少させるであろう。
本開示の他の複数の態様及び特徴は、複数の添付の図面と共に本発明の複数の特定の実施形態の以下の説明を検討することにより、当業者には明らかとなるであろう。
複数の添付の図面を参照して、詳細な説明を記載する。それらの複数の図面においては、参照番号のうちの左端の1つ又は複数の数字は、その参照番号が最初に現れる図を特定している。複数の同様の特徴及び構成要素を指すために、それらの複数の図面を通じて、同じ番号を使用する。
従来技術にしたがった複数のSAペイロードのうちのいくつかの構成を図示している。
従来技術にしたがったIKE SA鍵再生成のフローチャートを図示している。
削除要求の構成のある1つの例を図示している。
従来技術にしたがったIPSec SA鍵再生成を図示している。
本開示の複数の実施形態にしたがったイニシエータとレスポンダとの間での軽量鍵再生成のサポートについての交渉のフローチャートを図示している。
通知ペイロードの構成のある1つの例を図示している。
本開示の複数の実施形態にしたがったイニシエータとレスポンダとの間での軽量鍵再生成のサポートについての交渉の他のフローチャートを図示している。
本開示の複数の実施形態にしたがったイニシエータとレスポンダとの間での軽量鍵再生成のサポートについての交渉のさらに別のフローチャートを図示している。
本開示のある1つの実施形態にしたがった軽量鍵再生成アプローチを使用するSAの鍵再生成のフローチャートを図示している。
本開示のある1つの実施形態にしたがった軽量鍵再生成アプローチを使用するIKE SAの鍵再生成のフローチャートを図示している。
IKE SA鍵再生成要求パケットのフォーマットのある1つの例を図示している。
IKEのためのNEW_SPIペイロードのある1つの例を図示している。
IKEのためのLightweight SAペイロードのある1つの例を図示している。
提案非選択通知ペイロードの構成のある1つの例を図示している。
本開示のある1つの実施形態にしたがったある1つの特定のシナリオにおけるIKE SAの鍵再生成のフローチャートを図示している。
本開示の他の実施形態にしたがった軽量鍵再生成アプローチを使用するIKE SAの鍵再生成の他のフローチャートを図示している。
本開示のある1つの実施形態にしたがった軽量鍵再生成アプローチを使用するIPSec SAの鍵再生成のフローチャートを図示している。
IPSec SA鍵再生成要求パケットのフォーマットのある1つの例を図示している。
AHのためのNEW_SPIペイロードのある1つの例を図示している。
IPSec SAのための新たに定義されたペイロードであるLightweight SAの2つの例を図示している。
本開示のある1つの実施形態にしたがったある1つの特定のシナリオにおけるIPSec SAの鍵再生成のフローチャートを図示している。
本開示の他の実施形態にしたがった軽量鍵再生成アプローチを使用するIPSec SAの鍵再生成の他のフローチャートを図示している。
本開示のある1つの実施形態にしたがったSAの鍵再生成を実行するためのイニシエータとして動作するネットワークデバイスの概略的な図を図示している。
本開示のある1つの実施形態にしたがったSAの鍵再生成を実行するためのレスポンダとして動作するネットワークデバイスの概略的な図を図示している。
本開示の他の実施形態にしたがったSAの鍵再生成を実行するためのレスポンダとして動作するネットワークデバイスの概略的な図を図示している。
本開示の複数の実施形態にしたがったSAの鍵再生成を実行するためのイニシエータ又はレスポンダとして動作するネットワークデバイスの概略的な図を図示している。
本開示の複数の実施形態にしたがったSAの鍵再生成を実行するためのネットワークシステムの概略的な図を図示している。
本発明は、プロセス、装置、システム、コンピュータ読み取り可能な記憶媒体等のコンピュータ読み取り可能な媒体、又はコンピュータネットワーク等の数多くの方法によって実装されてもよく、プログラム命令は、例えば、光通信リンク又は電子的な通信リンク等のさまざまなタイプの通信リンクを介して送信される。本明細書における説明においては、これらの複数の実装又は本発明が採用することが可能であるいずれかの他の形態は、技術と称されてもよい。一般的に、開示されている複数のプロセスの複数のステップの順序は、本発明の範囲内で変更されてもよい。
本発明の1つ又は複数の実施形態の詳細な説明は、本発明の複数の原理を説明している複数の添付の図面と共に以下で提供される。本発明は、そのような複数の実施形態と関連して説明されるが、本発明は、いずれかの実施形態に限定されるものではない。本発明の範囲は、特許請求の範囲によってのみ限定され、本発明は、数多くの代替的なもの、修正されたもの、及び等価なものを包含する。本発明の完全な理解を提供するために、数多くの具体的な詳細が以下の説明に記載される。これらの詳細は、例示の目的で提供され、本発明は、これらの具体的な詳細のうちの一部又はすべてを使用することなく、請求項の記載にしたがって実施されてもよい。明確さの目的で、本発明に関連する技術の分野において知られている技術的な内容は、発明が必要以上に不明瞭にならないように、詳細には説明されていない。
以下の詳細な説明においては、本発明の完全な理解を提供するために、数多くの具体的な詳細が説明される。一方で、当業者は、本開示が、これらの具体的な詳細を使用することなく実施されてもよいということを理解するであろう。他の例では、よく知られている方法、手順、及び構成要素、モジュール、ユニット、及び/又は回路は、本発明を不明瞭にしないように詳細には説明されていない。
本発明の複数の実施形態は、この点に関して限定されないが、例えば、"処理すること"、"算出すること"、"決定すること"、"確立すること"、"作成すること"、又は"検査すること"等の語を使用する説明は、コンピュータのレジスタ及び/又はメモリの中の物理的な(例えば、電子的な)量として表されるデータを、コンピュータのレジスタ及び/又はメモリ或いは命令を格納することが可能である他の情報非一時記憶媒体の中の物理的な量として同様に表される他のデータへと処理し及び/又は変換して、操作及び/又はプロセスを実行するコンピュータ、コンピューティングプラットフォーム、コンピューティングシステム、又は他の電子的なコンピューティングデバイスの1つ又は複数の動作及び/又は1つ又は複数のプロセスを指してもよい。
図1に示されているように、鍵再生成フローチャートは、IKE及びIPSEC SAが(例えば、要求側又はイニシエータと呼ばれることがある)第1のネットワークデバイスと(例えば、レスポンダ等の)第2のネットワークデバイスとの間で確立された後に生起する。
本開示の複数の実施形態においては、第1のネットワークデバイス又は第2のネットワークデバイスは、コンピュータ、モバイルデバイス(例えば、携帯電話)、リモート健康モニタリングデバイス、ゲートウェイ、ルータ、サーバ、及びアクセスポイント(AP)デバイスが埋め込まれているセンサ、IPスタックを有するホームデバイス又はパーソナルデバイスのグループのうちのいずれか1つを含んでもよい。特に、それらの複数のネットワークデバイスのうちの1つは、制限された電源、処理能力、又は帯域幅能力を有するデバイスであってもよい。そのような場合には、ペイロードのサイズ及び/又は数を全体的に減少させて、処理電力、時間、そして、ひいては電力消費を節約することが可能であるので、本発明は、特に利点がある。
また、本開示のそれらの複数の実施形態において、ネットワークデバイスのうちの他方のネットワークデバイスは、多数のIKEトンネル/IPSecトンネルをサポートすることが可能であるセキュリティゲートウェイ/ePDG又はCRAN/クラウドベースのデバイスであってもよい。そのような場合に、伝送されるデータを減少させることによって、帯域幅及びパケットフラグメンテーション、及び、その結果としての処理要件を減少させることが可能である。
IKE_SA_INIT交換及びIKE_AUTH交換を含む初期交換(操作102乃至108)を実行した後に、IKE SA及びIPSec SAを確立する(操作110)。これらの初期交換は、通常は、4つのメッセージを含むが、複数のシナリオのうちのいくつかにおいては、その数を増加させてもよい。メッセージの第1の対(IKE_SA_INIT)は、暗号法一式を交渉し、ナンスを交換し、そして、Diffie-Hellman(DH)を実行する。メッセージの第2の対(IKE_AUTH)は、以前のメッセージを認証し、識別情報及び証明書を交換し、暗号法一式及びTraffic Selector(TS)を交渉し、そして、第1のChild SAを確立する。これらのメッセージの部分は、IKE_SA_INIT交換によって確立されている鍵によって、暗号化されるとともに完全性保護される。初期交換の後に続く複数のメッセージは、IKE_SA_INIT交換の中で交渉されてる暗号アルゴリズム及び鍵を使用して、暗号法によって保護される。IKE SA及びIPSec SAの各々について、秘密鍵は、通常は、制限された時間の中で使用され、その制限された時間は、SAの存続期間と呼ばれる場合がある。その存続期間が満了するときに、新たなSAを作成し、そして、その古いSAを削除することにより、そのSAの鍵再生成が実行される。初期交換の詳細な手順については、当業者は、本明細書の中の明示的な開示に反する場合を除き、本明細書に完全に記載されているかのように、すべての目的のために、参照によって組み込まれているRFC7296を参照する。
IKE SA及びIPSec SAを確立した(操作110)後に、IKE SA及びIPSec SAの存続期間のうちのいずれか一方が満了しつつある場合に、第1のネットワークデバイス及び第2のネットワークデバイスがSA鍵再生成手順を実行する。
それらのデバイスの各々は、自身の側で、SAの存続期間を管理する存続期間ポリシーを維持することが可能であるため、第1のネットワークデバイス又は第2のネットワークデバイスのうちのいずれもが、SA鍵再生成要求を開始することが可能であるということを理解すべきである。他の実施形態においては、双方の側は、それらのデバイスが共有しているSAについて同じ存続期間を有してもよい。第1のネットワークデバイス又は第2のネットワークデバイスは、周期的に、SA鍵再生成をトリガしてもよい。他のシナリオにおいては、デバイスは、そのデバイスと関連する各々のSAの将来的な満了を検出し、そして、その次に、そのデバイスがIKE SA又はIPSEC SAの秘密鍵が満了しつつあるということを検出する場合に、SA鍵再生成プロセスを開始してもよい。
名前が示唆しているように、SA鍵再生成は、そのポリシーを変更しない場合に、現在のSAと同じSA属性を有する新たな鍵を使用するSAを作成することを指す。ポリシーの変更は、例えば、エンドユーザが、(また、暗号法一式と称されてもよい)暗号法ポリシーを変更する、及び/又は、それらの1つ又は複数の暗号法一式の存続期間を変更するとき、或いは、チャイルドSAの鍵再生成の場合に、(また、フロー情報と称されてもよい)フローポリシーを変更するとき、であってもよい。フロー情報は、例えば、送信元IPアドレス及び宛先IPアドレス、ポート範囲又はポート番号を含んでもよい。SAの鍵再生成を実行することは、SAのための鍵を再生成する、すなわち、鍵が変更され、確立されたSAの他の要素が変更されてもよく又は変更されなくてもよい、ということを含む。
IKE SAの鍵再生成を開始する第1のネットワークデバイスを例にとってみる。その第1のネットワークデバイスは、第2のネットワークデバイスに、IKE SAの鍵再生成を実行するための鍵再生成要求を送信する。ある1つの実施形態において、CREATE_CHILD_SA交換は、IKE SAの鍵再生成を実行するのに使用される。この交換は、要求/応答の対を含む。その交換は、初期交換が完了した後に、IKE SAのうちの(例えば、第1のネットワークデバイス又は第2のネットワークデバイス等の)いずれの端によって開始されてもよい。SA鍵再生成を開始する端は、イニシエータと考えられてもよく、そのイニシエータのピアサイドは、レスポンダと考えられてもよい。
ある1つの実施形態によれば、IKE SAの鍵再生成を実行することは、少なくとも以下の操作を含んでもよい。
操作112, イニシエータは、レスポンダに、IKE SAの鍵再生成を実行するためのCREATE_CHILD_SA要求を送信する。
CREATE_CHILD_SA要求は、複数のペイロード及び(ペイロードではない)IKEヘッダーであるHDRを含む。ペイロードは、SAペイロード、Niペイロード、及びKEiペイロードを含む。SAペイロードは、例えば、イニシエータがサポートする1つ又は複数の暗号法一式等のSAオファーを含む。それらの暗号法一式は、認証アルゴリズム、暗号化アルゴリズム、及び/又は鍵算出のためのDHグループを含んでもよい。さらに、SAペイロードは、また、SAペイロードのSPIフィールドの中で供給される新たなイニシエータのセキュリティパラメータインデックス(SPI)を含んでもよい。SAペイロードの中の新たなイニシエータSPIは、レスポンダによって取得され、新たな鍵は、レスポンダ側で算出される。Niペイロードは、ナンスを含み、KEiペイロードは、Diffie-Hellman値を含む。本開示において、"暗号法一式"の語は、SAを保護するのに使用されるアルゴリズムのセットを指す。IPSEC SA又はIKE SAの状況によっては、暗号法一式は、また、ある特定の状況では、IPSec提案又はIKE提案と称されてもよい。新たなイニシエータSPIは、イニシエータ側での鍵再生成の後に、新たなIKE SAを識別するのに使用されてもよい。
操作114, レスポンダが、IKE SAの鍵再生成を実行するための要求を受信すると、レスポンダは、イニシエータに、IKE SAの鍵再生成を実行するためのCREATE_CHILD_SA応答を送信する。
CREATE_CHILD_SA応答は、HDR及びペイロードを含み、ペイロードは、SAペイロード、Nrペイロード、及びKErペイロードを含む。SAペイロードは、SAペイロードのSPIフィールドの中に新たなレスポンダSPIを含む。SAペイロードは、また、イニシエータの提示からレスポンダが選択する暗号法一式を含む。Nrペイロードは、ナンスを含み、選択された暗号法一式がそのグループを含む場合には、KErペイロードは、Diffie-Hellman値を含む。新たなレスポンダSPIは、レスポンダ側での鍵再生成の後に、新たなIKE SAを識別するのに使用されてもよい。このように、新たなレスポンダSPI及び新たなイニシエータSPIの組み合わせは、新たなIKE SAを識別するのに使用される。加えて、SAペイロードの中の新たなレスポンダSPIは、イニシエータによって取得され、新たな鍵は、イニシエータ側で算出される。
操作116, 新たなIKE SAが確立される。その新たなIKE SAは、IKE制御パケットを保護するのに使用される。
新たなIKE SA、すなわち、鍵再生成が実行されたIKE SAは、そのIKE SAのチャイルドSAのすべてを引き継ぎ、このことは、古いIKE SAとリンクされている既存のチャイルドSAは、鍵再生成が成功した後に新たなIKE SAに移動されるということを意味する。
操作112及び114に示されているIKE CREATE_CHILD_SAの交換の後に、新たなIKE SAは、新たな鍵及び選択された暗号法一式を使用して生成され、上記で説明されているSAペイロードの中で交換される新たなイニシエータSPI及び新たなレスポンダSPIを使用して識別される。
操作118, イニシエータは、レスポンダに、古いSAを削除するための古いIKE SAの削除の要求を送信する。
古いIKE SAの削除の要求は、HDR及びDペイロードを含んでもよい。Dペイロードは、削除されるSAを示すプロトコル識別子(ID)等の情報を含んでもよい。SAの削除は、RFC7296にしたがって、イニシエータとレスポンダとの間のINFORMATIONAL交換を通じて実装されてもよい。ある1つの例として、図1Cは、RFC7296にしたがった削除要求の構成のある1つの例を図示している。
操作120, 古いIKE SAの削除の要求を受信すると、レスポンダは、イニシエータに、古いIKE SAの削除の応答を送信する。
古いIKE SAの削除の応答は、HDR及びDペイロードを含んでもよい。Dペイロードは、削除されるSAを示すプロトコルID等の情報を含んでもよい。SAの削除は、RFC7296にしたがって、イニシエータとレスポンダとの間のINFORMATIONAL交換を通じて実装されてもよい。
図2を参照して、図2は、第1のネットワークデバイスが、チャイルドSA鍵再生成又はIPSec SA鍵再生成を開始するある1つの実施形態を提供する。IKE SAの鍵再生成と同じように、CREATE_CHILD_SAの交換は、また、チャイルドSAの鍵再生成を実行するのに使用されてもよい。
その実施形態によれば、IKE SAの鍵再生成を実行することは、少なくとも以下の操作を含んでもよい。
操作202乃至210は、操作102乃至110を参照することが可能である。
操作212, イニシエータは、レスポンダに、チャイルドSAの鍵再生成を実行するためのCREATE_CHILD_SA要求を送信する。
CREATE_CHILD_SA要求は、IKEヘッダーであるHDR及びペイロードを含む。ペイロードは、N個の(REKEY_SA)ペイロード、SAペイロード、Niペイロード、TSi及びTSrペイロード、及び選択的なKEiペイロードを含む。
RFC7296の中で定義されているREKEY_SAペイロードは、既存のチャイルドSAのために鍵再生成が生起しているということを他のピアに通知するのに使用される。鍵再生成を実行されている既存のチャイルドSAのSPIは、REKEY_SAペイロードのSPIフィールドの中に追加され、レスポンダは、含まれているSPIを使用してSAを識別することが可能である。さらに、REKEY_SAペイロードのプロトコルIDフィールドは、鍵再生成を実行されるSAのプロトコルと一致するように、例えば、ESPの場合は3に、AHの場合は2に設定される。
SAペイロードは、例えば、イニシエータがサポートする1つ又は複数の暗号法一式等のSAの提示を含む。SAペイロードは、また、そのSAペイロードのSPIフィールドの中に供給されている新たなイニシエータSPIを含んでもよい。
新たなイニシエータSPIは、鍵再生成の後に、新たなIPSec SAのためのイニシエータの中でインバウンドSPIとして使用され、鍵再生成の後に、新たなIPSec SAのためのレスポンダの中でアウトバウンドSPIとして使用されてもよい。Niペイロードは、ナンスを含み、選択的なKEiペイロードは、Diffie-Hellman値を含む。提案されるChild SAのための複数の提案されるTraffic Selectorは、TSiペイロード及びTSrペイロードの中に含まれる。それらの複数のTraffic Selectorは、鍵再生成を実行されるイニシエータと関連するフロー情報を含み、それらのフロー情報は、そのイニシエータがトラフィック通信のために使用するアドレス範囲(IPv4又はIPv6)、ポート範囲、及びIPプロトコルID等である。
提案がレスポンダに受け入れ可能であると仮定すると、そのレスポンダは、同一のTSペイロードを送り返す。他の場合には、そのレスポンダは、イニシエータが提案するトラフィックのサブセットを選択することを許可される。このことは、例えば、2つの端のフロー構成が更新されているが、一方の端のみが新たな情報を受け取っているときに生起する場合がある。それらの2つの端は、ネットワーク管理者等の複数の異なるエンドユーザによって構成されている場合があるため、エラーが存在しない場合であっても、非互換性が長期間にわたって持続する場合がある。レスポンダが、イニシエータが提案するトラフィックのサブセットを選択するときに、そのレスポンダは、(そのセットがヌルセットにならない限り)それらの複数のTraffic Selectorをイニシエータの提案のうちの一部のサブセットに狭める。
操作214: レスポンダが、要求を受信して、チャイルドSAの鍵再生成を実行すると、そのレスポンダは、イニシエータに、チャイルドSAの鍵再生成を実行するためのCREATE_CHILD_SA応答を送信する。
CREATE_CHILD_SA応答は、HDR及び複数のペイロードを含み、それらの複数のペイロードは、SAペイロード、Nrペイロード、TSi及びTSrペイロード、及び、選択的なKErペイロードを含む。
SAペイロードは、SAペイロードのSPIフィールドの中に新たなレスポンダSPIを含む。新たなレスポンダSPIは、鍵再生成の後に、新たなIPSec SAのためのレスポンダの中でインバウンドSPIとして使用され、鍵再生成の後に、新たなIPSec SAのためのイニシエータの中でアウトバウンドSPIとして使用されてもよい。SAペイロードは、また、イニシエータの提示からレスポンダが選択する暗号法一式を含む。Nrペイロードは、ナンスを含み、選択された暗号法一式がそのグループを含む場合には、KErペイロードは、Diffie-Hellman値を含む。
上記のように、レスポンダは、イニシエータに、同じTSペイロードを送り返してもよく、或いは、また、イニシエータが提案するトラフィックのサブセットを選択して、イニシエータに送り返してもよい。
ある1つの実施形態において、レスポンダは、以下のように狭めることを実行する。
レスポンダのポリシーが、提案されたTraffic Selectorのいかなる部分もそのレスポンダが受け入れることを許可していない場合には、そのレスポンダは、TS_UNACCEPTABLE通知メッセージによって応答する。
レスポンダのポリシーが、TSi及びTSrがカバーするトラフィックのセット全体を許可している場合には、狭めることは必要ではなく、そのレスポンダは、同じTSi値及びTSr値を返してもよい。
レスポンダのポリシーが、TSi及びTSrの第1のセレクタをそのレスポンダが受け入れることを許可している場合には、そのレスポンダは、イニシエータの第1の選択を含むサブセットへと、そのTraffic Selectorを狭めるであろう。
レスポンダのポリシーがTSi及びTSrの第1のセレクタをそのレスポンダが受け入れることを許可していない場合には、そのレスポンダは、TSi及びTSrの受け入れ可能なサブセットへと狭める。
操作216, 新たなIPSec SAが作成される。
新たなIPSec SAが確立された後に、その新たなIPSec SA、すなわち、鍵再生成が実行されたIPSec SAは、鍵再生成が実行されたIPSec SAが関連しているIKE SAに追加され、このことは、IKE SAから対応するチャイルドSAへのリンクが存在しているということを意味する。したがって、鍵再生成の後に作成される新たなチャイルドSAは、IKE SAに追加される。
操作212及び214に示されているIKE CREATE_CHILD_SAの交換の後に、新たなIPSec SAは、新たな鍵及び選択された暗号法一式によって作成され、上記で説明されているように、SAペイロードの中で交換される新たなイニシエータSPI及び新たなレスポンダSPIによって識別される。
操作218, イニシエータは、レスポンダに、古いチャイルドSAを削除するための古いチャイルドSAの削除の要求を送信する。
古いチャイルドSAの削除の要求は、HDR及びDペイロードを含んでもよい。Dペイロードは、削除されるSAを示すプロトコルID等の情報を含んでもよい。SAの削除は、RFC7296にしたがって、イニシエータとレスポンダとの間のINFORMATIONAL交換を通じて実装されてもよい。
操作220, 古いチャイルドSAの削除の要求を受信すると、レスポンダは、イニシエータに、古いチャイルドSAの削除の応答を送信する。
古いチャイルドSAの削除の応答は、HDR及びDペイロードを含んでもよい。Dペイロードは、削除されるSAを示すプロトコルID等の情報を含んでもよい。SAの削除は、RFC7296にしたがって、イニシエータとレスポンダとの間のINFORMATIONAL交換を通じて実装されてもよい。
図1及び図2の上記の従来技術の方法から理解することができるように、IKE SAの鍵再生成を実行する時に、たとえ、鍵再生成を実行するSAと関連する(例えば、暗号法一式等の)暗号法ポリシーに変更がない場合であっても、イニシエータとレスポンダとの間の交換は、単一の又は複数の暗号法一式を含むSAペイロードを含む。言い換えると、たとえ、イニシエータ及び/又はレスポンダが、それらと関連する暗号法一式を変更する場合であっても、イニシエータとレスポンダの間の鍵再生成の交換は、依然として、単一の又は複数の暗号法一式を含むSAペイロードを含む。IPSec SA鍵再生成の場合には、鍵再生成の時点で、鍵再生成を実行するSAと関連する暗号法ポリシー及びフローポリシーに変更がない場合であっても、イニシエータとレスポンダの間の交換は、単一の又は複数の暗号法一式を含むSAペイロード及びTSi & TSrペイロードを含む。
SA鍵再生成を周期的にトリガする場合には、SA鍵再生成は、これらのペイロードを処理するために帯域幅及び電力を消費する。ペイロードサイズは、IKE SA及びIPSec SAの双方の場合に複数の暗号法一式に対して比例的に増加するため、その問題は、複数の暗号法一式の場合により深刻となる。
IKEv2メッセージのサイズを小さくすることは、例えば、低電力消費技術を利用するモノのインターネット(IoT)デバイスにとって非常に望ましい。そのようなデバイスのうちのいくつかについては、ネットワークを介して余分なビットを伝送するための電力消費が法外に高くなる。そのようなデバイスの多くは、バッテリーによって給電されるが、(数年となることがよくある)そのデバイスのライフサイクルにわたって機能するバッテリーを再充電する能力又は交換する能力を有していない。このような理由により、そのようなデバイスの電力消費を減少させる作業は非常に重要である。
さらに、大きなUDPメッセージは、また、IPレベルにおいてフラグメント化を引き起こす場合があり、そのようなフラグメント化は、ネットワークアドレス変換器(NAT)との間で良くない相互作用をする場合がある。特に、複数のNATのうちのいくつかは、TCP/UDPポート番号を含まないIPフラグメント(非初期IPフラグメント)を破棄する。複数のIOTデバイスのうちのほとんどは、単一のセットの暗号法一式を有しているか、鍵再生成の時点において選択した暗号法一式を変更することを好まない。
ある1つの例では、CREATE_CHILD_SA交換によってIKE SAの鍵再生成を実行する場合には、SAペイロード(単一のセットの暗号法一式)の最小サイズは、52バイトであるが、一方で、本発明の複数の実施形態においては、これらのペイロードは、SPIを取得するための16バイトのサイズを有する通知ペイロードN(NEW_SPI)によって置き換えられる。したがって、36バイトが節約される。
他の例では、CREATE_CHILD_SA交換によってChild SAの鍵再生成を実行する場合に、SAペイロードの最小サイズは、40バイトであり、各々のTSサイズは、24バイト(2*24=48バイト)であるため、合計サイズは、88バイトである。本発明の複数の実施形態においては、これらのペイロードは、SPIを取得するための12バイトのサイズを有する通知ペイロードN(NEW_SPI)によって置き換えられ、合計76バイトが節約される。
本開示は、軽量鍵再生成の解決方法を提供して、上記で説明されている問題に対処する。この解決方法においては、暗号法ポリシーに変更がないときに、イニシエータとレスポンダとの間の交換は、IKE鍵再生成手順及びIPSec SA鍵再生成手順のいずれにおいてもSAペイロードを搬送しない。その代わりに、SPIは、(既存のSAペイロードの代わりとなることが可能である)本明細書においては"NEW_SPI通知"と称される新たな通知タイプのペイロード又は本明細書においては"Lightweight SAペイロード"と称される新たなペイロード又はSPIを送信するためのいずれかの他のペイロード等の中で転送される。NEW_SPI通知は、既存のSAペイロードよりもより少ないビットを使用する。伝送されるビットを追加的にさらに節約する際に、フロー情報に変更がないときに、イニシエータとレスポンダとの間の交換は、また、IPSec SA鍵再生成の際にTSペイロードを搬送しない。ある1つの例として、"Lightweight SAペイロード"フォーマットは、SAペイロードヘッダー及び提案ペイロードのみを含んでもよい。このようにして、Sai1及びSAr1において送信されるペイロード等の従来のペイロードと比較して、ペイロードは削減される。
軽量鍵再生成アプローチを実装するために、2つの端は、軽量鍵再生成方法を実行するそれぞれの能力を交換してもよい。この交換は、例えば、上記で説明されているように、IKE又はIPSec SAをセットアップするための初期交換の間であって、且つ、鍵再生成処理の前に実行されてもよい。
本開示のある1つの実施形態によれば、軽量鍵再生成の能力の交換は、2つのピアの間での以下の操作を含んでもよい。
イニシエータは、第2のネットワークデバイスに、そのイニシエータが、例えば、鍵再生成の選択的なペイロードをサポートする等、軽量鍵再生成をサポートしているということを示す通知を送信する。
レスポンダは、そのレスポンダが、例えば、鍵再生成の選択的なペイロードをサポートする等、軽量鍵再生成をサポートしているということを示す応答を送信する。
この初期サポートプロセスを通じて、2つの端は、そのピアが軽量鍵再生成アプローチをサポートしているか否かを互いに知ることが可能である。
図3A乃至図5は、イニシエータとレスポンダとの間の軽量鍵再生成のサポートを交渉するための3つの異なる手法を図示している。それらの3つの手法のすべては、初期交換プロセスを使用して、軽量鍵再生成の交渉を実装する。上記で説明されているように、本開示は、初期交換プロセスのみを使用して、軽量鍵再生成の交渉を実装することには限定されず、本開示を読んだ後に当業者は、他の手法を想定してもよい。
図3Aに図示されている実施形態においては、軽量鍵再生成をサポートする通知は、例えば、イニシエータがレスポンダに送信するIKE_SA_INIT要求メッセージ等のINIT要求の中の通知ペイロードの中で搬送され、したがって、軽量鍵再生成をサポートする確認は、例えば、レスポンダからイニシエータに送信されるIKE_SA_INIT応答メッセージ等のINIT応答の中の通知ペイロードの中で搬送される。ある1つの例として、図3Bは、通知ペイロードの構成を図示しており、その通知ペイロードにおいては、通知メッセージのタイプは、IKEV2_REKEY_OPTIONAL_PAYLOAD_SUPPORTEDであり、そのタイプは、従来の通知ペイロードと比較して、新たな"通知メッセージのタイプ"である。IKEV2_REKEY_OPTIONAL_PAYLOAD_SUPPORTED等の新たな通知メッセージのタイプは、通知ペイロードの中に含まれ、イニシエータ又はレスポンダが軽量鍵再生成をサポートしているということを示す。
図4に図示されている実施形態において、軽量鍵再生成をサポートする通知は、例えば、イニシエータがレスポンダに送信するIKE_SA_AUTH要求メッセージ等のAUTH要求の中の通知ペイロードの中で搬送され、したがって、軽量鍵再生成をサポートする通知は、例えば、レスポンダからイニシエータに送信されるIKE_SA_AUTH応答メッセージ等のAUTH応答の中の通知ペイロードの中で搬送される。通知ペイロードのタイプは、IKEV2_REKEY_OPTIONAL_PAYLOAD_SUPPORTEDペイロードであってもよい。
図5に図示されている実施形態において、軽量鍵再生成をサポートする通知は、例えば、イニシエータがレスポンダに送信するIKE_SA_INIT要求メッセージ等のINIT要求の中の通知ペイロードの中で搬送され、したがって、軽量鍵再生成をサポートする通知は、例えば、レスポンダからイニシエータに送信されるIKE_SA_AUTH応答メッセージ等のAUTH応答の中の通知ペイロードの中で搬送される。通知ペイロードのタイプは、IKEV2_REKEY_OPTIONAL_PAYLOAD_SUPPORTEDペイロードであってもよい。
軽量鍵再生成の能力の交渉は、例えば、IKE INIT又はAUTHの間等の鍵再生成プロセスの前には実行されなくてもよく、このことは、当事者の双方がこの能力に同意しておらず、その結果、イニシエータ又はレスポンダのうちのいずれかが、NEW_SPI又はLight Weight SAペイロードを送信することを許可されるべきではない場合に、他方の当事者は、これを破棄し、そして、エラーとして扱うことが可能であるということを意味するということに留意すべきである。
図6を参照すると、図6は、軽量鍵再生成アプローチを使用するSAの鍵再生成の実行のフローチャートを図示している。
IKE及びIPSec SA(s)がイニシエータとレスポンダの間で確立された後に、IKE及びIPSec SA(s)のうちのいずれか一方の存続期間が、各々の端におけるSA存続期間ポリシーにしたがって、満了に近くなっている場合に、イニシエータは、以下の操作を含んでもよい鍵再生成プロセスを開始する。
操作602, イニシエータは、そのイニシエータと関連する暗号法一式に変更があるか否かを決定する。
この開示において、イニシエータと関連する暗号法一式は、暗号法一式が、イニシエータによってサポートされ、且つ、例えば、SAの鍵再生成状況において鍵再生成を実行されたSA(すなわち、新たなSA)等のイニシエータが確立するある特定のSAのために使用されるということを意味する。
脆弱な暗号法一式と関連するSAを確立した後に、それらのSAのうちのいずれか1つの存続期間が満了に近くなる場合に、イニシエータは、新たなSAを作成し、そして、古いSAのために使用されている(又は、また、古いSAと関連すると称されてもよい)暗号法一式を変更することにより又は変更することなく、(古いSAとも称されてもよい)その鍵再生成を実行されるべきSAを削除することによって、SAの鍵再生成を実行することを望む。言い換えると、そのイニシエータと関連する暗号法一式が変更されないということは、古いSAが使用している暗号法一式が、鍵再生成を実行されるSA(すなわち、新たなSA)のために依然として使用されていてもよいということを意味する。そのイニシエータと関連する暗号法一式が変更されているということは、古いSAが関連している暗号法一式が、イニシエータがサポートしているとともに、新たなSAのために使用される(すなわち、新たなSAと関連する)他の暗号法一式へと変更されるということを意味する。以下の記載は、イニシエータと関連する暗号法一式の変更のためのいくつかの状況を説明する。
ある1つの状況は、イニシエータがサポートする暗号法一式が変更されるという状況である。例えば、イニシエータは、現在、(例えば、脆弱な暗号法一式等の)第1の暗号法一式のみをサポートしている。古いSAを確立した後に、イニシエータによる当該暗号法一式のサポートは、(例えば、イニシエータが、より高いセキュリティ要件を要するより重要な役割を担う等の)何らかの理由により、ネットワーク管理者がユーザインターフェイスを介してイニシエータを構成することによって、(強力な暗号法一式の)第2の暗号法一式へと変更される。暗号法一式を変更した後に、イニシエータが古いSAの鍵再生成を実行することを望む場合に、そのイニシエータは、現時点では、強力な暗号法一式のみをサポートしているため、そのイニシエータは、新たなSAのための暗号法一式を変更する必要がある。
他の状況は、イニシエータがサポートする暗号法一式が変更されないという状況である。例えば、イニシエータは、現在、2つ又はそれ以上の暗号法一式をサポートしている。鍵再生成を実行するときに、イニシエータは、例えば、SAの要件が改善され、その改善により、新たなSAのために使用されるより強力な暗号法一式が必要となる等の何らかの理由により、古いSAと関連する暗号法一式を使用するのではなく、新たなSAのための新たな暗号法一式を使用することを望む。この状況においては、古いSAと関連する第1の暗号法一式は、もはや、新たなSAとは関連していないので、そのイニシエータがレスポンダに送信する鍵再生成要求は、新たなSAのための第2の暗号法一式を搬送する必要がある。その詳細な実装は、図7A乃至図12の説明の中で開示されている。
さらに、他の状況は、イニシエータが、例えば、脆弱な暗号法一式等の第1の暗号法一式のみをサポートしている場合に、そのイニシエータが、古いSAの鍵再生成を実行するときに、何らかの理由により、(例えば、強力な暗号法一式に変更するといったように)第1の暗号法一式を第2の暗号法一式に変更することを望んでいるという状況である。この状況においては、イニシエータは、現時点では、第1の暗号法一式のみをサポートしているので、イニシエータを再構成する必要がある。ネットワーク管理者は、第2の暗号法一式をサポートするように、又は、第1の暗号法一式及び第2の暗号法一式の双方をサポートするように、イニシエータを再構成することを選択してもよい。また、その構成は、イニシエータ又はいくつかの他のデータベース又はデバイスの中に格納される。例えば、イニシエータがサポートする1つ又は複数の暗号法一式とそのイニシエータとの間の対応関係が、イニシエータ又はいくつかの他の場所に格納されてもよい。レスポンダ側での構成プロセスは、上記と同様である。再構成の後に、イニシエータは、そのイニシエータがサポートしている第2の暗号法一式を選択し、そして、SA鍵再生成の交換のための鍵再生成要求の中に、第2の暗号法一式を入れてもよい。
以下の記載は、イニシエータと関連する暗号法一式に変更がない場合のいくつかの状況を説明している。
1つの状況は、イニシエータが、例えば、脆弱な暗号法一式等の第1の暗号法一式のみをサポートし、古いSAと関連する第1の暗号法一式は、依然として、新たなSAと関連しているので、イニシエータが、古いSAの鍵再生成を実行するときに、変更時に第1の暗号法一式を保持する(すなわち、第1の暗号法一式が、依然として、鍵再生成を実行されるSAのために使用される)ことを望み、イニシエータがレスポンダに送信する鍵再生成要求が、新たなSAのための暗号法一式を搬送しないという状況である。
他の状況は、イニシエータが、例えば、(例えば、脆弱な暗号法一式等の)第1の暗号法一式及び(例えば、強力な暗号法一式等の)第2の暗号法一式等の2つ又はそれ以上の暗号法一式をサポートし、イニシエータが、古いSAの鍵再生成を実行するときに、第1の暗号法一式から第2の暗号法一式へと変更することを望まないという状況である。この状況においては、古いSAと関連する第1の暗号法一式は、依然として、新たなSAのために使用されるので、イニシエータがレスポンダに送信する鍵再生成要求は、新たなSAのための暗号法一式を搬送する必要はない。その詳細な実装は、図7A乃至12の説明を参照されたい。
操作604, イニシエータは、イニシエータと関連する暗号法一式に変更がないときに、レスポンダに、SAの鍵再生成を実行するための第1の鍵再生成要求を送信する。
上記で説明されているように、イニシエータと関連する暗号法一式に変更がないということは、古いSAが使用している暗号法一式が、依然として、鍵再生成を実行されるSA(すなわち、新たなSA)のために使用されてもよいということを意味する。イニシエータが新たなSAのための暗号法一式を搬送する必要はない。
イニシエータは、SAを確立した後に、暗号法一式を変更しないか、又は、イニシエータは、暗号法一式を過去に変更し、そして、その変更された暗号法一式を元の暗号法一式に再び変更し、現在の暗号法一式は、SAが確立されたときに使用される暗号法一式と同じになるため、第1の鍵再生成要求は、第1のSPIを搬送し、イニシエータと関連する暗号法一式を搬送しない。
IKE鍵再生成のシナリオにおいては、第1のSPIは、新たなイニシエータSPIである。双方の端におけるSPIの対によって、IKE SAを識別することが可能である。したがって、一方の端が鍵再生成プロセスを開始するときに、その鍵再生成プロセスは、鍵再生成要求の中に新たなSPIを含み、新たなSPIは、鍵再生成の後の新たなIKE SAのためのイニシエータSPIとして使用される。レスポンダが、応答としてIKE鍵再生成に応答するときに、レスポンダは、鍵再生成応答の中に新たなSPIを追加し、その新たなSPIは、鍵再生成の後の新たなIKE SAのためのレスポンダSPIとして使用されるべきである。
IPSec SA鍵再生成シナリオにおいては、第1のSPIは、鍵再生成の後に、新たなIPSec SAのためのイニシエータの中でインバウンドSPIとして使用され、鍵再生成の後に、新たなIPSec SAのためのレスポンダの中でアウトバウンドSPIとして使用される。さらに、第1の鍵再生成要求は、また、上記で説明されているように、N[REKEY_SA]ペイロードの中でSPIを搬送して、鍵再生成を実行されるSAを識別する。
この操作の詳細な実装については、図7乃至図9に図示されている以下のIKE鍵再生成プロセスを参照してもよい。
操作606, レスポンダは、イニシエータに第1の鍵再生成応答を送信する。レスポンダと関連する暗号法一式に変更がないときに、第1の鍵再生成応答は、第2のSPIを搬送し、レスポンダと関連する暗号法一式を搬送しない。
上記で説明されているように、IKE鍵再生成シナリオにおいては、第2のSPIは、新たなレスポンダSPIとなる。レスポンダが応答としてIKE鍵再生成に応答するときに、そのレスポンダは、鍵再生成応答の中に新たなレスポンダSPIを追加し、その新たなレスポンダSPIは、鍵再生成の後に、新たなIKE SAのためのレスポンダSPIとして使用されるべきである。
IPSec SA鍵再生成シナリオにおいては、第2のSPIは、鍵再生成の後に、新たなIPSec SAのためのレスポンダの中でインバウンドSPIとして使用され、鍵再生成の後に、新たなIPSec SAのためのイニシエータの中でアウトバウンドSPIとして使用される。
この操作の詳細な実装については、図8乃至図10に示されているように、以下のIKE鍵再生成プロセスを参照してもよい。
操作608, イニシエータと関連する暗号法一式及びレスポンダと関連する暗号法一式に変更がないときに、イニシエータによって、第1のSPI及び第2のSPIにしたがって、SAの鍵再生成を実行する。
鍵再生成を実行することは、新たなSAを作成すること、及び、鍵再生成を実行されるべき古いSAを削除することを含む。具体的には、イニシエータは、イニシエータSPI、レスポンダSPI、及び、古いSAのために使用される変更されていない暗号法一式を使用することによって、SAの鍵再生成を実行して、新たなSAのための新たな鍵を取得する。詳細な実装については、図7乃至図9に図示されているように、以下のIKE鍵再生成プロセスを参照してもよい。
図7Aは、本開示のある1つの実施形態にしたがったIKE SAの鍵再生成の実行のフローチャートである。この実施形態においては、イニシエータは、例えば、より高い暗号アルゴリズムセットを有する強力なより高い暗号法一式等の、鍵再生成を実行されるSAを確立するときに使用される暗号法一式を変更しない。
この実施形態においては、2つのシナリオが存在し、第1のシナリオは、レスポンダも、また、暗号法一式を変更しないというシナリオである。第2のシナリオは、レスポンダが暗号法一式を変更することを望むというものである。
この実施形態の第1のシナリオによれば、IKE鍵再生成プロセスは、以下の操作を含む。
操作702, イニシエータは、レスポンダにINIT要求を送信する。INIT要求は、上記で説明されているように、通常のHDRヘッド及び通常のペイロード以外に、通知ペイロードを搬送する。この実施形態においては、通知ペイロードはIKEV2_REKEY_OPTIONAL_PAYLOAD_SUPPORTEDペイロードであり、そのペイロードは、イニシエータが軽量鍵再生成をサポートするということを示す。
操作704, レスポンダは、イニシエータにINIT応答を送信する。INIT応答は、上記で説明されているように、通常のHDRヘッド及び通常のペイロード以外に、通知ペイロードを搬送する。この実施形態においては、通知ペイロードは、IKEV2_REKEY_OPTIONAL_PAYLOAD_SUPPORTEDペイロードであり、そのペイロードは、レスポンダが軽量鍵再生成アプローチをサポートしているということを示す。
上記で説明されている初期交換によれば、操作706及び708を実行した後に、IKE SA及びIPSec SAは、イニシエータとレスポンダとの間で確立される。
図3乃至図5に記載されている軽量鍵再生成の能力を交渉する複数の他の方法も、また、この実施形態に適用されてもよいということを理解すべきである。
操作710, IKE SA及びIPSEC SAが確立され、イニシエータは、周期的にIKE鍵再生成をトリガする。
イニシエータは、IKE SAの存続期間が満了しつつあるか否かを周期的に検出してもよい。上記のように、イニシエータは、イニシエータの側で存続期間ポリシーを維持してもよい。存続期間ポリシーは、複数の異なるSAについて異なる存続期間を設定してもよい。イニシエータは、IKE SAの存続期間が満了しつつあるということを検出するときに、操作712が実行される。
操作712, イニシエータは、レスポンダに、IKE SAの鍵再生成を実行するためのCREATE_CHILD_SA要求を送信する。CREATE_CHILD_SA要求は、HDRヘッド、Niペイロード、及びKEiペイロードを含む。1つ又は複数の暗号法一式を搬送するSAペイロードを搬送する代わりに、CREATE_CHILD_SA要求は、例えば、NEW_SPI通知等の通知ペイロードを搬送する。NEW_SPIペイロードは、新たなイニシエータSPIを搬送し、暗号法一式を搬送しないSPIフィールドを有してもよい。図7Bは、鍵再生成要求パケットフォーマットのある1つの例を示す。
代替的に、Lightweight SAペイロード又は他のペイロードは、新たなイニシエータSPIを搬送するのに使用されてもよい。
NEW_SPIは、新たに定義された通知ペイロードであり、その新たに定義された通知ペイロードは、鍵再生成の後に、新たなIKE SAを識別するイニシエータSPIを搬送する。
ある1つの例として、図7Cは、IKEのためのNEW_SPIを図示している。
ある1つの例として、図7Dは、IKEのためのLightweight SAペイロードを図示している。その例においては、Lightweight SAペイロードは、単一の提案ペイロードを含み、変換及び属性を含まない。この構成によれば、IKE鍵再生成の場合に"SPI"の中で言及されている値は、IKE SAのためのイニシエータSPI/レスポンダSPIとして使用される。
操作714, レスポンダは、イニシエータに、IKE SAの鍵再生成を実行するためのCREATE_CHILD_SA応答を送信する。
CREATE_CHILD_SA応答は、HDRヘッド、Nrペイロード、及びKErペイロードを含む。1つ又は複数の暗号法一式を搬送するSAペイロードを搬送する代わりに、CREATE_CHILD_SA応答は、例えば、NEW_SPI通知等の通知ペイローを搬送する。NEW_SPIペイロードは、新たなレスポンダSPIを搬送し、暗号法一式を搬送しないSPIフィールドを有してもよい。
操作716, 新たなIKE SAが作成される。
具体的には、上記で説明されているように、このシナリオにおいては、イニシエータ及びレスポンダの双方は、自身の暗号法一式を変更しない。イニシエータSPI及びレスポンダSPI、及び、鍵再生成を実行される古いSAのために使用されるもとの暗号法一式にしたがって、新たなIKE SAを作成する。新たなIKE SAは、IKE制御パケットを保護するのに使用される。新たなIKE SA、すなわち、鍵再生成を実行されたIKE SAは、そのIKE SAのチャイルドSAのすべてを引き継ぎ、このことは、古いIKE SAとリンクされる既存のチャイルドSAは、鍵再生成の実行が成功した後に、新たなIKE SAへと移動されるということを意味する。
操作718, イニシエータは、レスポンダに、古いIKE SAを削除するための古いIKE SAの削除の要求を送信する。
古いIKEの削除の要求は、HDR及びDペイロードを含んでもよい。Dペイロードは、削除されるべき古いSAを示すプロトコル識別子(ID)等の情報を含んでもよい。詳細な実装については、操作216を参照してもよい。
操作718, 古いIKE SAの削除の要求を受信すると、レスポンダは、イニシエータに、古いIKE SAの削除の応答を送信する。
古いIKE SAの削除の応答は、HDR及びDペイロードを含んでもよい。Dペイロードは、削除されるSAを示すプロトコルID等の情報を含んでもよい。詳細な実装については、操作218を参照してもよい。
この実施形態において説明されている軽量鍵再生成アプローチを使用することによって、このNEW_SPI通知ペイロードは、例えば、最小で36バイトを節約することが可能であり、複数の暗号法一式によって、節約されるバイトの数を比例的に増加させ、このことは、複雑な検証の処理を減少させ、したがって、IKE鍵再生成のやりとりにおけるSAペイロードの処理を減少させる。例えば、NEW_SPI通知ペイロードのサイズは、12乃至16バイトの範囲にあってもよい。
図8を参照すると、図8は、レスポンダが、(例えば、鍵再生成を実行されるSAを確立するときに使用される暗号法一式等の)そのレスポンダが現在使用している暗号法一式を変更する第2のシナリオを図示している。この状況においては、レスポンダは、操作814において、イニシエータに、NEW_SPI通知又はSAペイロードが変更された暗号法一式を搬送する代わりに、CREATE_CHILD_SA応答の中で提案非選択通知ペイロードを送信してもよい。その非選択通知ペイロードは、NO_PROPOSAL_CHOSENペイロードであってもよく、そのNO_PROPOSAL_CHOSENペイロードは、CREATE_CHILD_SA要求の中で搬送される暗号法一式の中に一致する暗号法一式が存在しないということを示す。その次に、イニシエータがその指示を受信した後に、そのイニシエータは、CREATE_CHILD_SA要求を再送信するが、このときは、更新した暗号法一式を搬送するSAペイロードを搬送して、イニシエータ及びレスポンダがその暗号法一式に関する合意を獲得するまで、そのレスポンダと暗号法一式について再交渉する。暗号法一式の再交渉のプロセスについては、この開示の中で説明されているシナリオのうちのいずれか1つを参照してもよい。その再交渉のある1つの例を以下で説明する。
この例では、操作802乃至812は、上記の操作702乃至712と同じである。しかし、操作814において、CREATE_CHILD_SA応答は、HDRヘッド及び通知ペイロードを搬送する。その通知ペイロードは、NO_PROPOSAL_CHOSENタイプのペイロードであってもよく、そのNO_PROPOSAL_CHOSENタイプのペイロードは、CREATE_CHILD_SA要求の中で搬送される暗号法一式の中に一致する暗号法一式が存在しないということを示す。ある1つの例として、図7Eは、通知メッセージタイプがNO_PROPOSAL_CHOSENである通知ペイロードの構成を図示している。このようにして、本明細書において開示されている他の新たな通知に関しては、従来の通知の構成が使用されるが、新たな通知タイプを有する。その次に、イニシエータがその指示を受信した後に、そのイニシエータは、更新した暗号法一式を搬送するSAペイロードを搬送するCREATE_CHILD_SA要求を再送信して、そのイニシエータ及びレスポンダが暗号法一式に関する合意を獲得するまで、そのレスポンダと暗号法一式について再交渉する。暗号法一式の再交渉のプロセスについては、この開示の中で説明されているシナリオのうちのいずれか1つを参照してもよい。以下では、再交渉のある1つの例を説明する。
その次に、操作816において、イニシエータは、レスポンダに、CREATE_CHILD_SA要求を再送信する。第2のCREATE_CHILD_SA要求は、HDRヘッド、N(REKEY_SA)ペイロード、SAペイロード、Niペイロード、及び選択的なKEiペイロードを含む。Niペイロード及びKeiペイロードの内容については、操作212及び操作712を参照してもよい。SAペイロードは、新たなイニシエータSPI及びイニシエータが提案した1つ又は複数の暗号法一式を搬送するSPIフィールドを搬送する。
操作818において、レスポンダは、イニシエータに、CREATE_CHILD_SA応答を送信する。CREATE_CHILD_SA応答は、HDRヘッド、SAペイロード、Nrペイロード、及びKErペイロードを搬送する。
操作820, 新たなIKE SAが作成される。この操作の実装については、上記で説明されている操作716を参照してもよい。
操作822, イニシエータは、レスポンダに、古いIKE SAを削除するための古いIKE SAの削除の要求を送信する。
その古いIKEの削除の要求は、HDR及びDペイロードを含んでもよい。Dペイロードは、削除されるSAを示すプロトコルID等の情報を含んでもよい。詳細な実装については、上記で説明されている操作216及び718を参照してもよい。
操作824, 古いIKE SAの削除の要求を受信すると、レスポンダは、イニシエータに、古いIKE SAの削除の応答を送信する。
古いチャイルドSAの削除の応答は、HDR及びDペイロードを含んでもよい。Dペイロードは、削除されるSAを示すプロトコルID等の情報を含んでもよい。詳細な実装については、上記で説明されている操作218及び720を参照してもよい。
図9は、本開示のある1つの実施形態にしたがったIKE SAの鍵再生成の実行のフローチャートである。この実施形態においては、イニシエータは、暗号法一式を変更する。
この実施形態においては3つのシナリオが存在する。第1のシナリオは、レスポンダが、暗号法一式を変更しないというシナリオである。このシナリオにおいては、例えば、イニシエータは、(例えば、脆弱な暗号法一式及び強力な暗号法一式等の)2つのサポートされている一式を有してもよく、脆弱な暗号法一式から強力な暗号法一式に変更することを望んではいるが、一方で、レスポンダは、脆弱な暗号法一式のみをサポートし、暗号法一式を変更することを望んではいない。この場合には、レスポンダは、イニシエータとの間で暗号法一式について交渉しなくてもよく、軽量鍵再生成アプローチを使用してもよい。例えば、レスポンダは、レスポンダSPIを収容するためのNEW_SPI通知、Lightweight SAペイロード、又はいずれかの他のペイロードを使用することが可能である。
第2のシナリオは、レスポンダが暗号法一式を変更するというシナリオである。このシナリオにおいては、例えば、イニシエータが、(例えば、脆弱な暗号法一式及び強力な暗号法一式等の)2つのサポートする一式を有し、脆弱な暗号法一式から強力な暗号法一式に変更することを望んでいるときに、レスポンダは、また、(鍵再生成を実行されるSAを最初に確立するときに使用される)脆弱な暗号法一式を強力な暗号法一式に変更することを望んでいる。この場合には、レスポンダは、鍵再生成応答の中で、強力な暗号法一式を搬送するSAペイロードを搬送してもよい。
第3のシナリオは、レスポンダが暗号法一式を変更するというシナリオである。このシナリオにおいては、例えば、イニシエータが、(例えば、強力な暗号法一式等の)サポートする一式を1つのみ有し、脆弱な暗号法一式を強力な暗号法一式に変更することを望んでいるときに、レスポンダは、脆弱な暗号法一式のみをサポートする。この場合には、レスポンダは、イニシエータが送信する鍵再生成要求の中で搬送される暗号法一式の中に一致する暗号法一式が存在しないということを示す通知ペイロードを送信する。その次に、イニシエータが指示を受信した後に、そのイニシエータは、鍵再生成要求を再送信するが、このときは、更新した暗号法一式を搬送するSAペイロードを搬送して、イニシエータ及びレスポンダが暗号法一式に関する合意を獲得するまで、レスポンダと暗号法一式について再交渉する。暗号法一式の再交渉のプロセスについては、この開示の中で説明されているシナリオのうちのいずれか1つを参照してもよい。
この実施形態によれば、IKE鍵再生成プロセスは、以下の操作を含む。
操作902乃至910の詳細な実装については、図7において説明されている操作702乃至710を参照してもよい。
操作912, イニシエータは、レスポンダに、IKE SAの鍵再生成を実行するためのCREATE_CHILD_SA要求を送信する。CREATE_CHILD_SA要求は、HDRヘッド、SAペイロード、Niペイロード、及びKEiペイロードを含む。各々のペイロードの中で搬送される情報については、操作112を参照してもよい。この場合には、例えば、SAペイロードは、例えば、脆弱な暗号法一式及び強力な暗号法一式等の2つの暗号法一式を搬送する。
操作914, レスポンダは、イニシエータに、IKE SAの鍵再生成を実行するためのCREATE_CHILD_SA応答を送信する。CREATE_CHILD_SA応答は、HDRヘッド、Nrペイロード、及びKErペイロードを含む。暗号法一式を搬送するSAペイロードを搬送する代わりに、CREATE_CHILD_SA要求は、例えば、NEW_SPI通知等の通知ペイロードを搬送する。NEW_SPIペイロードは、新たなレスポンダSPIを搬送し、暗号法一式を搬送しないSPIフィールドを有する。
操作914においては、レスポンダは、選択的な手法として、レスポンダが現在使用している暗号法一式を変更することをそのレスポンダが望まない場合であっても、そのレスポンダが現在使用している(すなわち、SAを確立するときにそのレスポンダが使用した)暗号法一式及び新たなレスポンダSPIを搬送するSAペイロードを搬送するCREATE_CHILD_SA応答を送信してもよいということを理解すべきである。
この実施形態の第2のシナリオによれば、レスポンダが現在使用している暗号法一式を変更することをそのレスポンダが望むときに、例えば、脆弱な暗号法一式から強力な暗号法一式に変更する。CREATE_CHILD_SA応答は、イニシエータがサポートする変更された暗号法一式、すなわち、強力な暗号法一式を搬送するSAペイロードを搬送する。
操作916乃至918の詳細な実装については、図8において説明されている操作716乃至718及び図2において説明されている操作216乃至218を参照してもよい。
この実施形態の第3のシナリオによれば、例えば、イニシエータは、(例えば、強力な暗号法一式等の)1つの暗号法一式のみをサポートし、例えば、脆弱な暗号法一式から強力な一式に暗号法一式へと暗号法一式を変更する。そして、レスポンダは、脆弱な暗号法一式のみをサポートする。このシナリオにおいては、レスポンダにおける暗号法一式は、イニシエータが提案する暗号法一式と一致しない。レスポンダとイニシエータとの間で暗号法一式での一致がないと決定した後に、レスポンダは、操作914において、イニシエータに、SAペイロードの代わりにCREATE_CHILD_SA応答の中で、提案非選択通知ペイロードを送信してもよい。提案非選択通知ペイロードは、NO_PROPOSAL_CHOSENペイロードであってもよく、そのNO_PROPOSAL_CHOSENペイロードは、CREATE_CHILD_SA要求の中で搬送される暗号法一式の中に一致する暗号法一式が存在しないということを示す。その次に、イニシエータがその指示を受信した後に、イニシエータは、更新した暗号法一式を搬送するSAペイロードを搬送するCREATE_CHILD_SA要求を再送信して、イニシエータ及びレスポンダが暗号法一式に関する合意を獲得するまで、レスポンダと暗号法一式について再交渉する。暗号法一式の再交渉のプロセスについては、この開示の中で説明されているシナリオのうちのいずれか1つを参照してもよい。
IKE鍵再生成にNEW_SPI通知ペイロードを導入することによって、例えば、各々のIKE鍵再生成について、最低36バイトを節約することが可能であり、したがって、複雑な検証の処理を減少させるとともにSAペイロードの処理もまた減少させることが可能である。
図10は、本開示のある1つの実施形態にしたがったIPSec SAの鍵再生成の実行のフローチャートである。この実施形態においては、イニシエータは、例えば、より高い暗号アルゴリズムセットを有する強力な暗号法一式等の、鍵再生成を実行されるSAを確立するときに使用される暗号法一式を変更しない。フロー情報に関しては、イニシエータは、フロー情報を変更してもよく又はフロー情報を変更しなくてもよい。イニシエータがフロー情報を変更しないときは、鍵再生成要求は、TSペイロードを搬送する必要はなく、対照的に、イニシエータがフロー情報を変更するときは、鍵再生成要求は、アドレス範囲、ポート範囲、及びIPプロトコルID等の変更されたフロー情報を反映するフロー情報を搬送する。
この実施形態においては、2つのシナリオが存在し、第1のシナリオは、レスポンダがまた暗号法一式を変更しないというシナリオである。第2のシナリオは、レスポンダが暗号法一式を変更するというシナリオである。
IKE SA及びIPSec SAの同時の鍵再生成の場合には、複数の操作(すなわち、IKE_SA_INIT又はAUTH要求メッセージにおけるIKEV2_REKEY_OPTIONAL_PAYLOAD_SUPPORTEDの交渉、及び/又は、"NEW_SPI通知"又は"Lightweight SAペイロード"、或いは、SAの鍵再生成を実行するためのSPIを含むいずれかの他のペイロードの交渉)は、この開示の中で説明されている複数の実施形態と類似したままであるということを理解すべきである。同時の鍵再生成の場合に、好ましくは、メッセージを組み合わせることなく、独立して鍵再生成プロセスを実行する。
この実施形態の第1のシナリオによれば、IPSec鍵再生成プロセスは、以下の操作を含む。
操作1002乃至1010, 操作1002乃至1010の詳細な実装については、図8において説明されている操作802乃至810を参照してもよい。
操作1012, イニシエータは、レスポンダに、チャイルドSAの鍵再生成を実行するためのCREATE_CHILD_SA要求を送信する。
CREATE_CHILD_SA要求は、HDRヘッド、N(REKEY_SA)ペイロード、NEW_SPIペイロード、Niペイロード、及び選択的なKEiペイロードを含み、イニシエータがフロー情報を変更しないときには、いかなるTSペイロードも含まない。N(REKEY_SA)ペイロードは、いずれのチャイルドSAが鍵再生成を実行されるべきであるかを示すSPIを搬送する。Niペイロード及びKEiペイロードの内容については、操作212を参照してもよい。1つ又は複数の暗号法一式を搬送するSAペイロードを搬送する代わりに、CREATE_CHILD_SA要求は、例えば、NEW_SPI通知ペイロード等の通知ペイロードを搬送する。NEW_SPIペイロードは、新たなイニシエータSPIを搬送し、暗号法一式を搬送しないSPIフィールドを有する。代替的に、Lightweight SAペイロード又は他のペイロードは、新たなイニシエータSPIを搬送するのに使用されてもよい。
NEW_SPIは、新たに定義されたNOTIFYペイロードであり、その新たに定義されたNOTIFYペイロードは、鍵再生成の後の新たなIPSec SAを識別するイニシエータSPIを搬送する。図10Bは、例えば、IPSec鍵再生成要求の中のNEW_SPI通知ペイロード等の新たなフィールドを示す鍵再生成要求パケットフォーマットのある1つの例を示している。
ある1つの例として、図10Cは、AHのためのNEW_SPIを図示している。
ある1つの例として、図10Dは、IPSec SAのための新たに定義されたペイロードである2種類のLightweight SAを図示している。最上位のLightweight SAペイロードは、単一の提案ペイロードを含み、TRANSFORMS及び属性を含まず、より下位のLightweight SAペイロードは、図10Dに示されているように、SAバンドルを含む。IPSecトンネルを作成するときに、2つの手法が存在する。1つの手法は、AH又はESPのうちのいずれかを使用する手法であり、もう1つの手法は、AH及びESPの双方を使用する手法であり、そのもう1つの手法は、また、SAバンドルと称される。SAバンドルは、ユーザが同時にAH及びESPの双方を使用することを望むときに使用される。
IPSec鍵再生成の場合に"SPI"ファイルの中で言及されている値は、AH/ESP SAのためのインバウンドSPI/アウトバウンドSPIとして使用される。
代替的に、イニシエータが、例えば、鍵再生成の後に、新たなSAのためのIPアドレス範囲等のフロー情報を変更するといったように、フロー構成を変更するとき、CREATE_CHILD_SA要求は、さらに、上記で説明されているペイロード以外に、TSペイロードを搬送してもよい。TSペイロードの内容については、操作212を参照してもよい。
操作1014, レスポンダは、イニシエータに、チャイルドSAの鍵再生成を実行するためのCREATE_CHILD_SA応答を送信する。
CREATE_CHILD_SA応答は、HDRヘッド、Nrペイロード、及び選択的なKErペイロードを含み、その選択的なKErペイロードは、CREATE_CHILD_SA要求がKEiペイロードを搬送しているか否かを条件とする。1つ又は複数の暗号法一式を搬送するSAペイロードを搬送する代わりに、CREATE_CHILD_SA応答は、例えば、NEW_SPI通知等の通知ペイロードを搬送する。NEW_SPIペイロードは、新たなレスポンダSPIを搬送し、暗号法一式を搬送しないSPIフィールドを有してもよい。
CREATE_CHILD_SA要求は、イニシエータと関連するフロー情報を搬送するTSペイロードを搬送しないので、レスポンダは、CREATE_CHILD_SA応答の中でTSペイロードを搬送するか否かに関して、以下の2つの選択を有してもよい。
第1の選択は、レスポンダと関連するフロー情報に変更がなく、現在使用されているフロー情報が、鍵再生成の後に、依然として、新たなIPSec SAのために使用されているときに、CREATE_CHILD_SA応答は、レスポンダと関連するTSペイロードを搬送しないということである。
第2の選択は、レスポンダと関連するフロー情報に変更があるときに、CREATE_CHILD_SA応答がTS受け入れ不可能通知を搬送するということである。TS受け入れ不可能通知は、TS_UNACCEPTABLE通知ペイロードであってもよく、そのTS_UNACCEPTABLE通知ペイロードは、イニシエータとレスポンダの間で情報が一致しないということを示すのに使用される。その次に、イニシエータがTS受け入れ不可能通知を受信した後に、そのイニシエータは、CREATE_CHILD_SA要求を再送信し、そのCREATE_CHILD_SA要求は、このときは、更新したフロー情報を搬送するTSペイロードを搬送し、イニシエータ及びレスポンダがフロー情報に関する合意を獲得するまで、レスポンダとフロー情報について再交渉する。フロー情報の再交渉のプロセスについては、この開示の中で説明されている暗号法一式又はフロー情報の交渉のシナリオのうちのいずれか1つを参照してもよい。
暗号法一式の交渉又はフロー情報の交渉のうちのいずれか一方が第1の交渉ターンにおいて失敗するときに、2つの端は、第2の交渉ターンにおいて、暗号法一式の交渉及びフロー情報の交渉の双方について再交渉してもよいということに留意すべきである。その場合には、再送信されたCREATE_CHILD_SA要求は、レスポンダとの間でフロー情報の交渉と共に暗号法一式について再交渉するために、SAペイロードを使用して行われてもよく又はSAペイロードを使用することなく行われてもよい。暗号法一式の詳細については、この開示の中で説明されているIPSec SA暗号法一式のシナリオのうちのいずれか1つを参照してもよい。
暗号法一式の交渉及びフロー情報の交渉は、独立して実行されてもよいということを理解すべきである。その場合には、2つの端は、第1の交渉ターンにおいて、暗号法一式についてすでに獲得している合意を記録してもよい。そして、第2の交渉ターンにおいて再送信されているCREATE_CHILD_SA要求は、SAペイロードの有無にかかわらず、暗号法一式について再交渉しなくてもよい。
イニシエータが、フロー情報を変更し、したがって、CREATE_CHILD_SA要求が、イニシエータと関連する変更されたフロー情報を搬送するTSペイロードを搬送するときに、レスポンダは、CREATE_CHILD_SA応答の中でTSペイロードを搬送するか否かに関して、以下の3つの選択を有してもよい。
第1の選択は、レスポンダと関連するフロー情報に変更がなく、レスポンダと関連する現在使用されているフロー情報が、CREATE_CHILD_SA要求の中で搬送されているとともにイニシエータと関連するフロー情報の中に存在するときに、CREATE_CHILD_SA応答は、TSペイロードを搬送しないということである。
第2の選択は、レスポンダと関連するフロー情報に変更があり、レスポンダが、そのレスポンダと関連するフロー情報として、CREATE_CHILD_SA要求の中で搬送されるとともにイニシエータと関連するフロー情報の中のフロー情報を選択するときに、CREATE_CHILD_SA応答は、TSペイロードを搬送するということである。操作212において説明されているように、レスポンダは、イニシエータが提案するトラフィックのサブセットを選択してもよい、すなわち、イニシエータの提案の何らかのサブセットへと、Traffic Selectorを狭めてもよい。レスポンダは、また、イニシエータに同じTSペイロードを送信してもよい。
第3の選択肢は、CREATE_CHILD_SA要求の中で搬送されるイニシエータが提案したフロー情報とサポートしているフロー情報との間に一致するフロー情報が存在しないときに、CREATE_CHILD_SA応答は、TS受け入れ不可能通知を搬送するということであり、そのTS受け入れ不可能通知は、一致するフロー情報が存在しないということを示す。その次に、イニシエータがその通知を受信した後に、そのイニシエータは、更新されたフロー情報を搬送するTSペイロードを搬送するCREATE_CHILD_SA要求を再送信して、イニシエータ及びレスポンダがフロー情報に関する合意を獲得するまで、レスポンダとフロー情報について再交渉する。フロー情報の再交渉のプロセスについては、必要に応じて、この開示の中で説明されている暗号法一式の交渉又はフロー情報の交渉のシナリオのうちのいずれか1つを参照してもよい。上記で説明されているように、再交渉のプロセスは、暗号法一式の交渉及びフロー情報の交渉を一緒に行ってもよく、又は、暗号法一式の既に獲得されている合意を再交渉することなく、第1の交渉ターンにおいて失敗しているフロー情報の交渉のみを実行してもよい。
操作1016乃至1020の詳細な実装については、図8において説明されている操作716乃至720及び図2において説明されている操作216乃至220を参照してもよい。
IPSec鍵再生成において、このNEW_SPI通知ペイロードは、例えば、最低76バイトを節約することが可能であり、複数の暗号法一式及び/又はTSペイロードによって、節約されるバイト数を比例的に増加させるであろう。このことは、複雑な検証の処理を減少させ、したがって、SAペイロード、TSiペイロード、及びTSrペイロードの処理を減少させる。
図11を参照すると、図11は、例えば、レスポンダが、鍵再生成を実行されるSAを確立するときにレスポンダが現在使用している暗号法一式を変更するといったように、レスポンダが暗号法一式を変更するこの実施形態の第2のシナリオを図示している。
このシナリオにおいては、操作1102乃至1112は、上記と同じ操作である。しかしながら、操作1114においては、CREATE_CHILD_SA応答は、HDRヘッド、提案非選択通知ペイロード、又はTS受け入れ不可能通知ペイロードを搬送する。提案非選択通知ペイロードは、NO_PROPOSAL_CHOSENペイロードであってもよく、そのNO_PROPOSAL_CHOSENペイロードは、CREATE_CHILD_SA要求の中で搬送される暗号法一式の中に一致する暗号法一式が存在しないということを示す。TS受け入れ不可能通知ペイロードは、TS_UNACCEPTABLEペイロードであってもよく、そのTS_UNACCEPTABLEペイロードは、CREATE_CHILD_SA要求の中で搬送されるフロー情報の中に一致するフロー情報が存在しないということを示す。その次に、イニシエータがその指示を受信した後に、そのイニシエータは、更新した暗号法一式を搬送するSAペイロードを搬送するCREATE_CHILD_SA要求を再送信して、イニシエータ及びレスポンダが暗号法一式に関する合意を獲得するまで、レスポンダと暗号法一式について再交渉する。暗号法一式の再交渉のプロセスについては、この開示の中で説明されているシナリオのうちのいずれか1つを参照してもよい。以下では、再交渉のある1つの例を説明する。
操作1116において、イニシエータは、レスポンダに、(第2のCREATE_CHILD_SA要求と呼ばれてもよい)CREATE_CHILD_SA要求を再送信する。
第2のCREATE_CHILD_SA要求は、HDRヘッド、N(REKEY_SA)ペイロード、SAペイロード、Niペイロード、選択的なKEiペイロード、イニシエータがフロー情報を変更するか否かに依存する選択的なTSペイロードを含む。N(REKEY_SA)ペイロードは、いずれのチャイルドSAが鍵再生成を実行されるべきかを示すSPIを搬送する。Niペイロード及びKeiペイロードの内容については、操作212及び操作1012を参照してもよい。SAペイロードは、新たなイニシエータSPI及びイニシエータが提案している1つ又は複数の暗号法一式を搬送するSPIフィールドを搬送する。
操作1118において、レスポンダは、イニシエータに、CREATE_CHILD_SA応答を送信する。CREATE_CHILD_SA応答は、HDRヘッド、N(REKEY_SA)ペイロード、NEW_SPI通知ペイロード又はSAペイロード、NRペイロード、(CREATE_CHILD_SA要求がKeiペイロードを搬送しているか否かに依存する)選択的なKEr応答、及び、(レスポンダがレスポンダと関連するフロー情報を変更するか否かに依存する)レスポンダと関連するフロー情報を搬送する選択的なTSペイロードを搬送する。再交渉のプロセスにおいて、暗号法一式の交渉及びフロー情報の交渉は、この開示の中で説明されているように、暗号法一式交渉アプローチ及びフロー情報交渉アプローチのうちのいずれか1つにしたがって実行されてもよいということを理解すべきである。
操作1120, この操作の実装については、上記で説明されている操作216を参照してもよい。
操作1122, イニシエータは、レスポンダに、古いIPSec SAを削除するための古いIPsec SAの削除の要求を送信する。
古いチャイルドの削除の要求は、HDR及びDペイロードを含んでもよい。Dペイロードは、削除されるSAを識別するSPIを含んでもよい。詳細な実装については、操作216を参照してもよい。
操作1124, 古いIPsec SAの削除の要求を受信すると、レスポンダは、イニシエータに、古いIPSec SAの削除の応答を送信する。
古いチャイルドSAの削除の応答は、HDR及びDペイロードを含んでもよい。Dペイロードは、削除されるSAを識別するSPIを含んでもよい。詳細な実装については、操作218を参照してもよい。
上記の再交渉のプロセスは、暗号法一式の交渉及びフロー情報の交渉を一緒に行い、暗号法一式の交渉及びフロー情報の交渉のうちのいずれか一方が失敗するときは、再交渉のプロセスがトリガされ、再交渉のプロセスは、暗号法一式及びフロー情報の双方について再交渉する。上記で説明されているように、暗号法一式の交渉及びフロー情報の交渉は、個別に実行されてもよい。
以下の記載は、第2シナリオにおけるフロー情報の交渉について説明する。
操作1112におけるCREATE_CHILD_SA要求が、イニシエータと関連するフロー情報を搬送するTSペイロードを搬送しないときに、レスポンダは、操作1114におけるCREATE_CHILD_SA応答の中でTSペイロードを搬送するか否かに関して、以下の2つの選択を有してもよい。
第1の選択は、レスポンダと関連するフロー情報に変更がなく、現在使用されているフロー情報が、依然として、鍵再生成の後に、新たなIPSec SAのために使用されているときは、CREATE_CHILD_SA応答は、レスポンダと関連するTSペイロードを搬送しないということである。
第2の選択は、レスポンダと関連するフロー情報に変更があるときに、CREATE_CHILD_SA応答が、TS受け入れ不可能通知を搬送するということである。TS受け入れ不可能通知は、TS_UNACCEPTABLE通知ペイロードであってもよく、そのTS_UNACCEPTABLE通知ペイロードは、イニシエータとレスポンダとの間で情報が一致しないということを示すのに使用される。その次に、イニシエータがTS受け入れ不可能通知を受信した後に、そのイニシエータは、更新したフロー情報を搬送するTSペイロードを搬送するCREATE_CHILD_SA要求を再送信して、イニシエータ及びレスポンダがフロー情報に関する合意を獲得するまで、レスポンダとフロー情報について再交渉する。フロー情報の再交渉のプロセスについては、この開示の中で説明されているように、必要に応じて、暗号法一式の交渉又はフロー情報の交渉のシナリオのうちのいずれか1つを参照してもよい。
暗号法一式の交渉又はフロー情報の交渉のうちのいずれか一方が第1の交渉ターンにおいて失敗するときに、2つの端は、第2の交渉ターンにおいて、暗号法一式の交渉及びフロー情報の交渉の双方について再交渉してもよいということに留意すべきである。その場合には、再送信されたCREATE_CHILD_SA要求は、レスポンダとの間でフロー情報の交渉と共に暗号法一式について再交渉するために、SAペイロードを使用して行われてもよく又はSAペイロードを使用することなく行われてもよい。暗号法一式の詳細については、この開示の中で説明されているように、必要に応じて、IPSec SA暗号法一式のシナリオのうちのいずれか1つを参照してもよい。
暗号法一式の交渉及びフロー情報の交渉は、独立して実行されてもよいということを理解すべきである。その場合には、2つの端は、第1の交渉ターンにおいて、暗号法一式についてすでに獲得している合意を記録してもよい。そして、第2の交渉ターンにおいて再送信されているCREATE_CHILD_SA要求は、SAペイロードの有無にかかわらず、暗号法一式について再交渉しなくてもよい。
更新された暗号法一式又はTS使用する第2の鍵再生成要求の際に、デバイスは、NEW_SPI通知又はLight Weight SAペイロードの中でSPIを再利用することが可能であるか、或いは、新たな暗号法一式を使用する第2の鍵再生成要求の際に新たなSPIを完全に生成することが可能であるか、のいずれかである。このアプローチは、この開示の中で説明されている再交渉のプロセスに適用されてもよい。
イニシエータが、フロー情報を変更し、したがって、CREATE_CHILD_SA要求が、イニシエータと関連する変更されたフロー情報を搬送するTSペイロードを搬送するときに、レスポンダは、CREATE_CHILD_SA応答の中でTSペイロードを搬送するか否かに関して、以下の3つの選択を有してもよい。
第1の選択は、レスポンダと関連するフロー情報に変更がなく、レスポンダと関連する現在使用されているフロー情報が、CREATE_CHILD_SA要求の中で搬送されているとともにイニシエータと関連するフロー情報の中に存在するときに、CREATE_CHILD_SA応答は、TSペイロードを搬送しないということである。
第2の選択は、レスポンダと関連するフロー情報に変更があり、レスポンダが、そのレスポンダと関連するフロー情報として、CREATE_CHILD_SA要求の中で搬送されるとともにイニシエータと関連するフロー情報の中のフロー情報を選択するときに、CREATE_CHILD_SA応答は、TSペイロードを搬送するということである。操作212において説明されているように、レスポンダは、イニシエータが提案するトラフィックのサブセットを選択してもよい、すなわち、イニシエータの提案の何らかのサブセットへと、Traffic Selectorを狭めてもよい。レスポンダは、また、イニシエータに同じTSペイロードを送信してもよい。
第3の選択肢は、CREATE_CHILD_SA要求の中で搬送されるイニシエータが提案したフロー情報とサポートしているフロー情報との間に一致するフロー情報が存在しないときに、CREATE_CHILD_SA応答は、TS受け入れ不可能通知を搬送するということであり、そのTS受け入れ不可能通知は、一致するフロー情報が存在しないということを示す。その次に、イニシエータがその通知を受信した後に、そのイニシエータは、更新されたフロー情報を搬送するTSペイロードを搬送するCREATE_CHILD_SA要求を再送信して、イニシエータ及びレスポンダがフロー情報に関する合意を獲得するまで、レスポンダとフロー情報について再交渉する。フロー情報の再交渉のプロセスについては、必要に応じて、この開示の中で説明されている暗号法一式の交渉又はフロー情報の交渉のシナリオのうちのいずれか1つを参照してもよい。
上記で説明されているように、再交渉のプロセスは、暗号法一式の交渉及びフロー情報の交渉を一緒に行ってもよく、又は、第1の交渉ターンにおいて失敗している交渉のみを実行してもよい。
図12は、本開示のある1つの実施形態にしたがったIPSec SAの鍵再生成の実行のフローチャートである。この実施形態においては、イニシエータは、例えば、脆弱な暗号法一式から、例えば、より高い暗号アルゴリズムセットを使用するより高い暗号法一式等のより強力な暗号法一式に変更するといったように、鍵再生成を実行されるSAを確立するときに使用される暗号法一式を変更する。フロー情報に関しては、イニシエータは、フロー情報を変更してもよく、又は、フロー情報を変更しなくてもよい。イニシエータがフロー情報を変更しない場合には、鍵再生成要求は、TSペイロードを搬送する必要はない。対照的に、イニシエータがフロー情報を変更するときには、鍵再生成要求は、変更されたフロー情報を反映するアドレス範囲、ポート範囲、及びIPプロトコルID等のフロー情報を搬送するであろう。
この実施形態においては3つのシナリオが存在する。第1のシナリオは、レスポンダが、例えば、暗号法一式等の暗号法一式を変更しないというシナリオである。このシナリオにおいては、レスポンダは、イニシエータとの間で暗号法一式について交渉しなくてもよく、軽量鍵再生成アプローチを使用してもよい。例えば、レスポンダは、NEW_SPI通知、Lightweight SAペイロード、又はレスポンダSPIを含む他のペイロードを使用してもよい。第2のシナリオは、レスポンダが暗号法一式を変更するというシナリオである。この場合には、レスポンダは、鍵再生成応答の中で、変更した暗号法一式を搬送するSAペイロードを搬送してもよい。第3のシナリオは、鍵再生成要求の中で搬送される1つ又は複数の暗号法一式が、レスポンダがサポートする暗号法一式と一致しないというシナリオである。この場合には、レスポンダは、通知ペイロードを搬送し、その通知ペイロードは、イニシエータが送信する鍵再生成要求の中で搬送される暗号法一式の中に一致する暗号法一式が存在しないということを示す。その次に、2つの端は、暗号法一式に関する合意を獲得するまで、再度暗号法一式について交渉する。暗号法一式の詳細な交渉については、図9に対応する詳細な説明を参照してもよい。
図12を再び参照すると、図12は、この実施形態にしたがった以下の操作を含むフローチャートを図示している。
操作1202乃至1210の詳細な実装については、図8において説明されている操作802乃至810を参照してもよい。
操作1212, イニシエータは、レスポンダに、IPSec SAの鍵再生成を実行するためのCREATE_CHILD_SA要求を送信する。CREATE_CHILD_SA要求は、HDRヘッド、いずれのチャイルドSAが鍵再生成を実行されるべきであるかを示すSPIを搬送するN(REKEY_SA)ペイロード、1つ又は複数の暗号法一式及び新たなイニシエータSPIを搬送するSAペイロード、Niペイロード、選択的なKEiペイロード、及び(イニシエータがそのイニシエータと関連するフロー情報を変更するか否かに依存する)選択的なTSペイロードを含む。各々のペイロードの中で搬送される詳細な情報については、操作112を参照してもよい。
操作1214, レスポンダは、イニシエータに、IPSec SAの鍵再生成を実行するためのCREATE_CHILD_SA応答を送信する。CREATE_CHILD_SA応答は、HDRヘッド、(レスポンダがそのレスポンダと関連する暗号法一式を変更するか否かに依存する)SAペイロード又はNEW_SPI通知ペイロード、Nrペイロード、(CREATE_CHILD_SA要求がKeiペイロードを搬送しているか否かに依存する)選択的なKErペイロード、及び(レスポンダがそのレスポンダと関連するフロー情報を変更するか否かに依存する)選択的なTSペイロードを含む。NEW_SPIペイロードは、新たなレスポンダSPIを搬送し、暗号法一式を搬送しないSPIフィールドを有してもよい。
操作1214においては、レスポンダが、そのレスポンダが現在使用している暗号法一式を変更しない場合であっても、レスポンダは、選択的な手法として、そのレスポンダが現在使用している(すなわち、SAを確立するときにそのレスポンダが使用した)暗号法一式及び新たなレスポンダSPIを搬送するSAペイロードを搬送するCREATE_CHILD_SA応答を送信してもよいということを理解すべきである。
この実施形態の第2のシナリオによれば、レスポンダが、そのレスポンダが現在使用している暗号法一式を変更するときに、CREATE_CHILD_SA応答は、また、イニシエータがサポートする変更された暗号法一式を搬送するSAペイロードを搬送する。
操作1216乃至1218の詳細な実装については、図8において説明されている操作816乃至818及び図2において説明されている操作216乃至218を参照してもよい。
この実施形態の第3のシナリオによれば、CREATE_CHILD_SA要求の中の暗号法一式は、レスポンダが変更することを望む暗号法一式とは一致しない。このシナリオにおいては、レスポンダは、操作1214において、イニシエータに、SAペイロードの代わりに、CREATE_CHILD_SA応答の中で、提案非選択通知ペイロードを送信してもよい。提案非選択通知ペイロードは、NO_PROPOSAL_CHOSENペイロードであってもよく、そのNO_PROPOSAL_CHOSENペイロードは、CREATE_CHILD_SA要求の中で搬送される暗号法一式の中に一致する暗号法一式が存在しないということを示す。その次に、イニシエータがその指示を受信した後に、イニシエータは、更新した暗号法一式を搬送するSAペイロードを搬送するCREATE_CHILD_SA要求を再送信して、イニシエータ及びレスポンダが暗号法一式に関する合意を獲得するまで、レスポンダと暗号法一式について再交渉する。暗号法一式の再交渉のプロセスについては、必要に応じて、この開示の中で説明されているシナリオのうちのいずれか1つを参照してもよい。
以下の記載は、この実施形態におけるフロー情報の交渉を説明する。
操作1212におけるCREATE_CHILD_SA要求が、イニシエータと関連するフロー情報を搬送するTSペイロードを搬送しないときに、レスポンダは、操作1214におけるCREATE_CHILD_SA応答の中でTSペイロードを搬送するか否かに関して、以下の2つの選択を有してもよい。
第1の選択は、レスポンダと関連するフロー情報に変更がなく、現在使用されているフロー情報が、鍵再生成の後に、依然として、新たなIPSec SAのために使用されているときに、CREATE_CHILD_SA応答は、レスポンダと関連するTSペイロードを搬送しないということである。
第2の選択は、レスポンダと関連するフロー情報に変更があるときに、CREATE_CHILD_SA応答が、TS受け入れ不可能通知を搬送するということである。TS受け入れ不可能通知は、TS_UNACCEPTABLE通知ペイロードであってもよく、そのTS_UNACCEPTABLE通知ペイロードは、イニシエータとレスポンダとの間で情報が一致しないということを示すのに使用される。その次に、イニシエータがTS受け入れ不可能通知を受信した後に、そのイニシエータは、更新したフロー情報を搬送するTSペイロードを搬送するCREATE_CHILD_SA要求を再送信して、イニシエータ及びレスポンダがフロー情報に関する合意を獲得するまで、レスポンダとフロー情報について再交渉する。フロー情報の再交渉のプロセスについては、この開示の中で説明されているように、必要に応じて、暗号法一式の交渉又はフロー情報の交渉のアプローチのうちのいずれか1つを参照してもよい。
暗号法一式の交渉又はフロー情報の交渉のうちのいずれか一方が第1の交渉ターンにおいて失敗するときに、2つの端は、第2の交渉ターンにおいて、暗号法一式の交渉及びフロー情報の交渉の双方について再交渉してもよいということに留意すべきである。その場合には、再送信されたCREATE_CHILD_SA要求は、レスポンダとの間でフロー情報の交渉と共に暗号法一式について再交渉するために、SAペイロードを使用して行われてもよく又はSAペイロードを使用することなく行われてもよい。
暗号法一式の交渉及びフロー情報の交渉は、独立して実行されてもよいということを理解すべきである。その場合には、2つの端は、第1の交渉ターンにおいて、暗号法一式についてすでに獲得している合意を記録してもよい。そして、第2の交渉ターンにおいて再送信されているCREATE_CHILD_SA要求は、SAペイロードの有無にかかわらず、暗号法一式について再交渉しなくてもよい。
イニシエータが、フロー情報を変更し、したがって、CREATE_CHILD_SA要求が、イニシエータと関連する変更されたフロー情報を搬送するTSペイロードを搬送するときに、レスポンダは、CREATE_CHILD_SA応答の中でTSペイロードを搬送するか否かに関して、以下の3つの選択を有してもよい。
第1の選択は、レスポンダと関連するフロー情報に変更がなく、レスポンダと関連する現在使用されているフロー情報が、CREATE_CHILD_SA要求の中で搬送されているとともにイニシエータと関連するフロー情報の中に存在するときに、CREATE_CHILD_SA応答は、TSペイロードを搬送しないということである。
第2の選択は、レスポンダと関連するフロー情報に変更があり、レスポンダが、そのレスポンダと関連するフロー情報として、CREATE_CHILD_SA要求の中で搬送されるとともにイニシエータと関連するフロー情報の中のフロー情報を選択するときに、CREATE_CHILD_SA応答は、TSペイロードを搬送するということである。操作212において説明されているように、レスポンダは、イニシエータが提案するトラフィックのサブセットを選択してもよい、すなわち、イニシエータの提案の何らかのサブセットへと、Traffic Selectorを狭めてもよい。レスポンダは、また、イニシエータに同じTSペイロードを送信してもよい。
第3の選択肢は、CREATE_CHILD_SA要求の中で搬送されるイニシエータが提案したフロー情報とサポートしているフロー情報との間に一致するフロー情報が存在しないときに、CREATE_CHILD_SA応答は、TS受け入れ不可能通知を搬送するということであり、そのTS受け入れ不可能通知は、一致するフロー情報が存在しないということを示す。その次に、イニシエータがその通知を受信した後に、そのイニシエータは、更新されたフロー情報を搬送するTSペイロードを搬送するCREATE_CHILD_SA要求を再送信して、イニシエータ及びレスポンダがフロー情報に関する合意を獲得するまで、レスポンダとフロー情報について再交渉する。フロー情報の再交渉のプロセスについては、必要に応じて、この開示の中で説明されている暗号法一式の交渉又はフロー情報の交渉のシナリオのうちのいずれか1つを参照してもよい。
上記で説明されているように、再交渉のプロセスは、暗号法一式の交渉又はフロー情報の交渉を一緒に行ってもよく、或いは、第1の交渉ターンにおいて失敗している交渉のみを実行してもよい。
IPSec鍵再生成において、NEW_SPI通知ペイロードを導入することによって、又は、TSペイロードを搬送しないことによって、各々のIPSec鍵再生成について、IPSec鍵再生成ごとに、例えば、最低76バイトを節約することが可能であり、したがって、複雑な検証の処理を減少させ、また、SAペイロード、TSiペイロード、及びTSrペイロードの処理を減少させる。
図13を参照すると、図13は、この開示のある1つの実施形態にしたがったネットワークデバイス1300の概略的な図を図示している。ネットワークデバイスは、(例えば、上記の実施形態において説明されているイニシエータ等の)第1のネットワークデバイス及び(例えば、上記の実施形態において説明されているレスポンダ等の)第2のネットワークデバイスを含むネットワークシステムにおいてセキュリティアソシエーション(SA)の鍵再生成を実行するように構成され、第1のネットワークデバイスと第2のネットワークデバイスとの間にIKEトンネル及びIPSecトンネルが確立される。この実施形態においては、ネットワークデバイスは、第1のネットワークデバイスとして動作し、ネットワークデバイスは、決定モジュール1302、送信モジュール1304、受信モジュール1306、及び鍵再生成モジュール1308を含む。
決定モジュール1302は、第1のネットワークデバイスと関連する暗号法一式に変更があるか否かを決定するように構成される。送信モジュール1304は、第1のネットワークデバイスと関連する暗号法一式に変更がないときに、第2のネットワークデバイスに、SAの鍵再生成を実行するための第1の鍵再生成要求を送信するように構成され、第1の鍵再生成要求は、第1のSPIを搬送し、第1のネットワークデバイスと関連する暗号法一式を搬送しない。受信モジュール1306は、第2のネットワークデバイスから第1の鍵再生成応答を受信するように構成され、第2のネットワークデバイスと関連する暗号法一式に変更がないときに、第1の鍵再生成応答は、第2のSPIを搬送し、第2のネットワークデバイスと関連する暗号法一式を搬送しない。鍵再生成モジュール1308は、第1のネットワークデバイスと関連する暗号法一式及び第2のネットワークデバイスと関連する暗号法一式に変更がないときに、第1のSPI及び第2のSPIにしたがって、SAの鍵再生成を実行するように構成される。この実施形態のネットワークデバイスにおける各々のモジュールの実装の詳細については、図7及び10の実施形態におけるイニシエータの実装を参照してもよい。
他の実施形態において、ネットワークデバイスは、再交渉モジュール1310をさらに含む。第2のネットワークデバイスと関連する暗号法一式に変更があるときは、第1の鍵再生成応答は、第2のネットワークデバイスからの提案非選択通知を搬送する。再交渉モジュール1310は、交渉された暗号法一式を取得するまで、第2のネットワークデバイスと再交渉するように構成され、鍵再生成モジュール1308は、さらに、再交渉された暗号法一式にしたがって、SAの鍵再生成を実行するように構成される。再交渉モジュール1310は、IPSec SA鍵再生成の場合に、暗号法一式又はフロー情報について再交渉するべきであるか否かを決定するように構成され、再交渉のプロセスは、送信モジュール1304及び受信モジュール1306によって実行されるということを理解すべきである。複数の実施形態のうちのいくつかにおいて、再交渉モジュール1310は、決定モジュール1302に組み込まれてもよい。提案非選択通知のある1つの例は、NO_PROPOSAL_CHOSEN通知ペイロードであってもよい。この実施形態のネットワークデバイスの再交渉の実装の詳細については、図8及び図11の複数の実施形態におけるイニシエータの実装を参照してもよい。
ネットワークデバイス1300は、図1乃至図12の上記の複数の実施形態においてイニシエータが実行する操作を実装することが可能であるということが理解されるであろう。詳細な実装については、上記で説明されている実施形態を参照してもよい。本明細書においては、1つずつ説明する必要はない。
図14を参照すると、図14は、この開示のある1つの実施形態にしたがった他のネットワークデバイス1400の概略的な図を図示している。ネットワークデバイス1400は、(例えば、上記の実施形態において説明されているイニシエータ等の)第1のネットワークデバイス及び(例えば、上記の実施形態において説明されているレスポンダ等の)第2のネットワークデバイスを含むネットワークシステムにおいてセキュリティアソシエーション(SA)の鍵再生成を実行するように構成され、第1のネットワークデバイスと第2のネットワークデバイスとの間にIKEトンネル及びIPSecトンネルが確立される。この実施形態においては、ネットワークデバイスは、第2のネットワークデバイスとして構成され、ネットワークデバイスは、受信モジュール1402、決定モジュール1404、送信モジュール1406、及び鍵再生成モジュール1408を含む。
受信モジュール1402は、第1のネットワークデバイスから、SAの鍵再生成を実行するための第1の鍵再生成要求を受信するように構成され、第1の鍵再生成要求は、第1のSPIを搬送し、第1のネットワークデバイスと関連する暗号法一式を搬送しない。決定モジュール1404は、第2のネットワークデバイスと関連する暗号法一式に変更があるか否かを決定するように構成される。送信モジュール1406は、第1のネットワークデバイスに、第1の鍵再生成応答を送信するように構成され、第2のネットワークデバイスと関連する暗号構成に変更がないときに、第1の鍵再生成応答は、第2のSPIを搬送し、第2のネットワークデバイスと関連する暗号法一式を搬送しない。したがって、鍵再生成モジュール1408は、第1のSPI及び第2のSPIにしたがって、SAの鍵再生成を実行するように構成される。この実施形態のネットワークデバイスにおける各々のモジュールの実装の詳細については、図7及び10の説明を参照してもよい。
ネットワークデバイス1400の他の実施形態において、第2のネットワークデバイスと関連する暗号法一式に変更があるときに、第1の鍵再生成応答は、提案非選択通知を搬送するということである。したがって、受信モジュール1402は、さらに、第1のネットワークデバイスから、SAの鍵再生成を実行するための第2の鍵再生成要求を受信するように構成され、第2の鍵再生成要求は、第1のネットワークデバイスと関連する暗号法一式及び第1のSPIを搬送する。そして、送信モジュール1406は、さらに、第2の鍵再生成要求の中で搬送されるとともに第1のネットワークデバイスと関連する暗号法一式の中に一致する暗号法一式が存在しないということを示す他の提案非選択通知を搬送する第2の鍵再生成応答を送信するように構成される。ネットワークデバイスは、再交渉モジュール1410をさらに含み、再交渉モジュール1410は、交渉された暗号法一式を取得するまで、第1のネットワークデバイスと再交渉するように構成される。したがって、SAの鍵再生成は、さらに、再交渉された暗号法一式にしたがって実行される。再交渉モジュール1410は、IPSec SAの鍵再生成の場合に、暗号法一式又はフロー情報を再交渉するか否かを決定するように構成され、再交渉のプロセスは、送信モジュール1406及び受信モジュール1402によって実行されるということを理解すべきである。複数の実施形態のうちのいくつかにおいて、再交渉モジュール1410は、決定モジュール1404に組み込まれてもよい。この実施形態のネットワークデバイスの再交渉の実装の詳細については、図8及び図11の実施形態におけるイニシエータの実装を参照してもよい。
ネットワークデバイス1400は、図1乃至図12の上記の複数の実施形態においてレスポンダが実行する操作を実装することが可能であるということが理解されるであろう。詳細な実装については、上記で説明されている実施形態を参照してもよい。本明細書においては、1つずつ説明する必要はない。
図15を参照すると、図15は、この開示のある1つの実施形態にしたがった他のネットワークデバイス1500の概略的な図を図示している。ネットワークデバイス1500は、(例えば、上記の実施形態において説明されているイニシエータ等の)第1のネットワークデバイス及び(例えば、上記の実施形態において説明されているレスポンダ等の)第2のネットワークデバイスを含むネットワークシステムにおいてセキュリティアソシエーション(SA)の鍵再生成を実行するように構成され、第1のネットワークデバイスと第2のネットワークデバイスとの間にIKEトンネル及びIPSecトンネルが確立される。この実施形態においては、ネットワークデバイスは、第2のネットワークデバイスとして構成され、ネットワークデバイスは、受信モジュール1502、決定モジュール1504、送信モジュール1506、及び鍵再生成モジュール1508を含む。
受信モジュール1502は、第1のネットワークデバイスから、SAの鍵再生成を実行するための第1の鍵再生成要求を受信するように構成され、第1の鍵再生成要求は、第1のネットワークデバイスと関連する暗号法一式及び第1のSPIを搬送する。決定モジュール1504は、第2のネットワークデバイスと関連する暗号法一式に変更があるか否かを決定するように構成される。送信モジュール1506は、第1のネットワークデバイスに、第1の鍵再生成応答を送信するように構成され、第2のネットワークデバイスと関連する暗号法一式に変更がないときに、第1の鍵再生成応答は、第2のSPIを搬送し、第2のネットワークデバイスと関連する暗号法一式を搬送しない。鍵再生成モジュールは、第1のSPI及び第2のSPIにしたがって、SAの鍵再生成を実行するように構成される。鍵再生成の実装については、例えば、図6乃至12における上記の詳細な説明を参照してもよい。
ネットワークデバイス1500の他の実施形態において、第1の鍵再生成応答は、提案非選択通知を搬送し、その提案非選択通知は、第1の鍵再生成要求の中で搬送されるとともに第1のネットワークデバイスと関連する暗号法一式の中に一致する暗号法一式が存在しないということを示すということである。この場合には、ネットワークデバイス1500は、交渉された暗号法一式を取得するまで、第1のネットワークデバイスと再交渉するように構成される再交渉モジュール1510をさらに含む。したがって、SAは、さらに、交渉された暗号法一式にしたがって、鍵再生成を実行される。当業者は、再交渉モジュール1510が、IPSec SA鍵再生成の場合に、暗号法一式又はフロー情報について再交渉するか否かを決定するように構成され、再交渉のプロセスは、送信モジュール1506及び受信モジュール1502によって実行されるということを理解するであろう。複数の実施形態のうちのいくつかにおいて、再交渉モジュール1510は、決定モジュール1504に組み込まれてもよい。上記の実施形態のネットワークデバイス1500における再交渉の実装の詳細については、図9及び図12の実施形態におけるレスポンダの実装を参照してもよい。
当業者は、ネットワークデバイス1500が、図1乃至図12の上記の複数の実施形態においてレスポンダが実行する操作を実装することが可能であるということが理解するであろう。詳細な実装については、上記で説明されている実施形態を参照してもよい。本明細書においては、1つずつ説明する必要はない。
図16を参照すると、図16は、この開示のある1つの実施形態にしたがった他のネットワークデバイス1600の概略的な図を図示している。ネットワークデバイス1600は、(例えば、上記の実施形態において説明されているイニシエータ等の)第1のネットワークデバイス及び(例えば、上記の実施形態において説明されているレスポンダ等の)第2のネットワークデバイスを含むネットワークシステムにおいてセキュリティアソシエーション(SA)の鍵再生成を実行するように構成され、第1のネットワークデバイスと第2のネットワークデバイスとの間にIKEトンネル及びIPSecトンネルが確立される。複数の実施形態のうちのいくつかにおいて、ネットワークデバイス1600は、図1乃至12の実施形態において説明されているように、イニシエータとして動作してもよく、図1乃至12の実施形態において説明されているイニシエータの操作を実行してもよい。他の実施形態においては、ネットワークデバイス1600は、図1乃至12の実施形態において説明されているようにレスポンダとして動作してもよく、図1乃至12の実施形態において説明されているレスポンダの操作を実行してもよい。
ネットワークデバイスは、プロセッサ1602、プロセッサ1602に結合されるメモリ1604、トランシーバー(Tx/Rx)1606、及びTx/Rx1606に結合されるポート1608を含む。プロセッサ1602は、汎用プロセッサとして実装されてもよく、或いは、1つ又は複数の特定用途向け集積回路(ASIC)及び/又はディジタル信号プロセッサ(DSP)の部分であってもよい。プロセッサ1602は、単一のプロセス又は複数のプロセッサを指してもよい。メモリ1604は、例えば、ランダムアクセスメモリ(RAM)等のコンテンツを一時的に格納するためのキャッシュを含んでもよい。追加的に、メモリ1604は、例えば、読み取り専用メモリ(ROM)等の長期間記憶装置を含んでもよい。イニシエータとして動作するときに、プロセッサ1602は、図1乃至12の複数の実施形態において説明されているイニシエータの操作を実行するように構成される。レスポンダとして動作するときに、プロセッサ1602は、図1乃至12の複数の実施形態において説明されているレスポンダの操作を実行するように構成される。
さらに、ある1つの実施形態において、メモリ1604は、図13の複数の実施形態において説明されている複数のモジュール等の複数のソフトウェアモジュールを含んでもよい。他の実施形態においては、メモリ1604は、図14の複数の実施形態において説明されている複数のモジュール等の複数のソフトウェアモジュールを含んでもよい。さらなる実施形態においては、メモリ1604は、図15の複数の実施形態において説明されている複数のモジュール等の複数のソフトウェアモジュールを含んでもよい。
プロセッサ1602は、複数のソフトウェアモジュールの複数の命令を実行することによって、複数の操作を実行することが可能である。複数の実施形態のうちのいくつかにおいて、モジュールがある1つの操作を実行するように構成されるときに、そのことは、実際には、プロセッサ1602が、モジュールの中で複数の命令を実行して、その操作を実行するように構成されるということを意味してもよい。プロセッサ1602は、メモリ1604の中の複数の命令を実行することによって、図1乃至12において説明されているイニシエータ又はレスポンダが実行する操作のすべてを完全に又は部分的に実行することが可能である。
図17を参照すると、図17は、ネットワークシステム1700の概略的な図を図示している。ネットワークシステム1700は、少なくとも第1のネットワークデバイス1702(すなわち、イニシエータ)及び第2のネットワークデバイス1704(すなわち、レスポンダ)を含んでもよい。第1のネットワークデバイス1702は、図13の実施形態において説明されているネットワークデバイス1300であってもよい。第2のネットワークデバイス1704は、図14及び15の実施形態において説明されているネットワークデバイス1400又はネットワークデバイス1500であってもよい。他の実施形態においては、第1のネットワークデバイスは、ネットワークデバイス1600であってもよく、そのネットワークデバイス1600は、図1乃至12の複数の実施形態において説明されているイニシエータとして動作し、そして、図1乃至12の複数の実施形態において説明されているイニシエータの操作を実行する。また、第2のネットワークデバイスは、ネットワークデバイス1600であってもよく、そのネットワークデバイス1600は、図1乃至12の複数の実施形態において説明されているレスポンダとして動作し、そして、図1乃至12の複数の実施形態において説明されているレスポンダの操作を実行する。
当業者は、この開示を読んだ後に、本開示の実装のためにいずれかの既知の又は新たなアルゴリズムを使用してもよいということを理解することが可能である。しかしながら、この開示は、いずれかの既知の又は新たなアルゴリズムを使用するか否かにかかわらず、上記で言及している利点及び技術的進歩を達成する方法を提供するということに留意すべきである。
当業者は、この開示を読んだ後に、この明細書の中で開示されている複数の実施形態において説明されている複数の例に関して、電子的なハードウェアによって、又は、コンピュータソフトウェア及び電子的なハードウェアの組み合わせによって、複数のユニット及び複数のアルゴリズムのステップを実装してもよいということを認識することが可能である。複数の機能がハードウェアによって実行されるか又はソフトウェアによって実行されるかは、特定の発明及び技術的解決方法の設計上の制約条件に依存する。この開示を読んだ後に、当業者は、複数の異なる方法を使用して、各々の特定の発明について説明されている複数の機能を実装してもよいが、その実装は、本開示の範囲を超えるものであると解釈されるべきではない。
本開示によって提供されるいくつかの実施形態において、開示されているシステム及び方法は、他の方式によって実装されてもよいということを理解すべきである。例えば、説明されているネットワークデバイスの実施形態は、例示的なものであるにすぎない。例えば、ユニットの分割は、論理的且つ機能的な分割であるにすぎず、実際の実装においては他の分割であってもよい。例えば、複数のユニット又はモジュールを組み合わせ又は一体化して、他のシステムとしてもよく、或いは、いくつかの特徴を無視してもよく、又は、実行しなくてもよい。加えて、いくつかのインターフェイスを使用して、示され又は説明されている相互の結合、直接的な結合、又は通信接続を実装してもよい。電子的な形態、機械的な形態、又は他の形態によって、複数の装置又は複数のユニットの間の間接的な結合又は通信接続を実装してもよい。
それらの複数の機能が、ソフトウェア機能ユニットの形態で実装され、そして、独立した製品として販売され又は使用されるときに、それらの複数の機能は、コンピュータ読み取り可能な記憶媒体の中に格納されてもよい。それらの複数の機能は、コンピュータプログラム製品を形成するコンピュータコードで表現されてもよく、それらのコードは、それらの複数の機能を実行するように適切なハードウェアに指示してもよい。そのような理解に基づいて、本開示の複数の技術的解決方法は、本質的に、或いは、先行技術に寄与する部分又はそれらの複数の技術的解決方法の一部は、ソフトウェア製品の形態で実装されてもよい。コンピュータソフトウェア製品は、記憶媒体の中に格納され、そして、いくつかの命令を含み、それらのいくつかの命令は、本開示のそれらの複数の実施形態において説明されている複数の方法の複数のステップのすべて又は一部を実行するように、(パーソナルコンピュータ、サーバ、又はネットワークノード、すなわち、プロセッサであってもよい)コンピュータノードに指示する。上記の記憶媒体は、プログラムコードを格納することが可能であるUSBフラッシュドライブ、取り外し可能なハードディスク、読み取り専用メモリ(Read-Only Memory, ROM)、ランダムアクセスメモリ(Random Access Memory, RAM)、磁気ディスク、又は光ディスク等のいずれかの媒体を含む。
互いに通信している複数のデバイスは、特に明記しない限り、互いに連続的に通信している必要はない。加えて、互いに通信している複数のデバイスは、1つ又は複数の手段を通じて直接的に又は間接的に通信してもよい。
単一のデバイス又は物品が、本明細書において説明されるときに、単一のデバイス/物品の代わりに、(それらが協働するか否かにかかわらず)1つよりも多くのデバイス/物品を使用してもよいということが容易に明らかとなるであろう。同様に、(それらが協働するか否かにかかわらず)1つよりも多くのデバイス又は物品が、本明細書において説明される場合に、1つよりも多くのデバイス又は物品の代わりに、単一のデバイス/物品を使用してもよく、或いは、示された数のデバイス又はプログラムの代わりに、異なる数のデバイス/物品を使用してもよいということが容易に明らかとなるであろう。あるデバイスの機能及び/又は特徴は、代替的に、そのような機能/特徴を有するものとして明示的に説明されてはいない1つ又は複数の他のデバイスによって具体化されてもよい。したがって、本発明の他の実施形態は、そのデバイス自体を含む必要はない。