ＩＰアドレス委任
ネットワークルーティングプレフィックスと、暗号化によって生成されたインタフェース識別子とを含むＩＰｖ６について生成されたリクエストを検証する方法である。このリクエストは委任用の証明書を含み、この証明書は、少なくともホストの公開鍵と、１つ以上の更なるパラメータあるいは１つ以上の更なるパラメータを生成するための式あるいは式群、ＩＰｖ６ネットワークルーティングプレフィックスの範囲あるいはセットの指定、委任先ホストのアイデンティティ、前記公開鍵に関連付けられている秘密鍵を使用して、少なくとも前記アイデンティティと前記ＩＰｖ６ネットワークルーティングプレフィックスの範囲あるいはセットの指定を介して取得されるデジタル署名を含んでいる。この方法は、ＩＰｖ６アドレスのネットワークルーティングプレフィックスが指定に含まれることを検証すること、公開鍵と更なるパラメータ（群）が暗号化によって生成されたインタフェース識別子を生成するために使用できるかを検証すること、公開鍵を使用して署名を検証することを含んでいる。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＩＰアドレス委任（delegation：デリゲーション）に関するものであり、特に、暗号化によって生成されたアドレス（Cryptographically Generated Address）を所有するノードから別のノードへ、その暗号化によって生成されたアドレスについての責任の委任に関するものである。
【背景技術】
【０００２】
ＩＰアドレスは、１２８ビット長である。アドレスの先頭６４ビットはルーティングプレフィックを形成し、これは、ＩＰ端末あるいはノードによって使用される、インターネットアクセスノード（あるいは、いわゆる「ローカルリンク」）を固有に識別する。残りの６４ビットはホストサフィックスを形成し、これは、アクセスノード（あるいはローカルリンク内）に対する移動端末を固有に識別する。ホストサフィックスは、「インタフェース識別子」と呼ばれる。これは、アクセスインタフェースを介して固有にホストを識別するからである。典型的には、ホストをアクセスノードに登録すると、ホストはアクセスノードから送信される広告メッセージから、アクセスノードのルーティングプレフィックスを学習する。ＩＥＴＦ ＲＦＣ３０４１に従えば、次に、ホストは、ホストによって生成される乱数を使用して、自身のインタフェース識別子を生成する。ホストは、更に、リンクレイヤアドレスを使用して、インタフェースを識別子を生成することもできる。このリンクレイヤアドレスは、例えば、アクセスネットワークによって使用されるＭＡＣレイヤアドレスである。
【０００３】
国際公開第０２／０７６０６０号は、一方向符号化関数、例えば、ハッシュ関数を使用して、インタフェース識別子の暗号化バージョンをどのようにして生成できるか、また、このインタフェース識別子を別のピア（peer）ユーザにどのように提供できるかについて記載している。ここで、このピアユーザは、ノードが、ＩＰアドレスのインタフェース識別子部分の所有者であることを検証することができる。このような暗号化によって生成されたアドレス（cryptographically generated address）は、ＣＧＡとして知られている。ＣＧＡは、例えば、サービス拒否攻撃を防止することを支援するためのセキュリティレベルを提供する。ここで、サービス拒否攻撃は、攻撃者が、ノードを使用したいことを、ＩＰアドレスの所有者に要求することである。ＣＧＡは、ＩＥＴＦ ＲＦＣ３９７２で標準化されていて、また、ＩＥＴＦ ＲＦＣ３９７１で標準化されているセキュア近隣ディスカバリ（ＳｅＮＤ）プロトコルで使用されている。
【０００４】
ＲＦＣ３９７２に従えば、ＣＧＡは以下のようにして生成される。
【０００５】
ハッシュ１＝ハッシュ（修飾子｜プレフィックス｜公開鍵｜拡張）
ＩＰｖ６アドレス＝プレフィックス｜ハッシュ１（セキュリティレベルと他の要件に従って生成される所定のビット付き）
ここで、「プレフィックス（prefix）」はネットワークルーティングプレフィックスであり、「ハッシュ（hash）」は暗号化ハッシュ関数（ＳＨＡ−１）であり、「公開鍵」はアドレスを生成するノードの公開鍵であり、「拡張」は標準化情報を搬送するための現行は未使用のフィールドである。「修飾子」はセキュリティを高めかつランダム性を増すために、ノードによって生成される１２８ビット値である。より詳しくは、必要とされるセキュリティレベルに依存して、修飾子値は、一定の連続するデータ（修飾子と公開鍵を含む）となるように選択され、このデータは値（「ハッシュ２（Hash2）」）をハッシュする。この値は、左端ビット位置において指定番号「０」を有している。
【０００６】
ＣＧＡの所有権を証明するためには、ノードは、証明書を提供することができるようにしなければならない。この証明書には、ＣＧＡアドレスのインタフェース識別子（ＩＩＤ）部分、修飾子、公開鍵、及び任意の拡張を含み、これらがＣＧＡデータ構造として構成される。証明書は、ノードの公開鍵を使用して、送信されるメッセージ（１２８ビットのＣＧＡタイプタグで連結されている）に渡って取得されるデジタル署名（ＳＨＡ−１）を含んでいる。証明書を受信するピアノードは、まず、ハッシュ２を計算し、それが左端位置で正しい番号の「０」を有しているかを検証する。そのような場合、ピアノードは、ハッシュ１を計算し、これとＩＩＤとを比較する。これによって、ＩＩＤが公開鍵と秘密鍵のペアに属していることを検証し、更に、検証された公開鍵を使用して、署名処理の逆処理を行うことによって署名を検証する。この２番目のステップは、送信側が実際に公開鍵を所有し、かつ単純に悪用していないことを証明し、また、メッセージが、要求された送信側から発信されたことを証明する。
【０００７】
ＣＧＡを所有するホスト（「委任元（delegating）」ノード）は、そのアドレスについての責任をいくつかの更なるノード（「委任先（delegated）」ノード）に委任することができ、例えば、委任先ノードに、委任元ノードに向けられているトラフィックをリクエストすることを許容する。これは、委任先ノードに証明書を提供することによって達成され、この証明書は、ＣＧＡ、ＣＧＡデータ構造、委任先ノードのアイデンティティ、委任元ノードの秘密鍵を使用して生成される署名を含んでいる。要求されたＣＧＡを使用することが許容されていることをサードパーティに証明するために、委任先ノードは、証明書をサードパーティに提供し、このサードパーティは、ＩＩＤが公開鍵に属することを検証し、かつ証明書が所有者の公開鍵によって有効に署名されることを検証することができる。アイデンティティが委任先ノードの公開鍵である場合、委任先ノードは、自身の秘密鍵で、ＣＧＡに関連する任意のリクエストを署名することができる。つまり、サードパーティに、委任先ノードが要求されたアイデンティティを所有することを証明することを許容する。
【発明の概要】
【発明が解決しようとする課題】
【０００８】
この委任に対する方法に付随する問題は、委任元ノードによって委任先ノードへ提供される証明書が、単一のＣＧＡと結び付けられることである。例えば、モビリティティと新規のネットワークルーティングプレフィックスの自身の使用のために、委任元ノードが自身のＩＰｖ６アドレスを変更するイベントでは、新規の証明書は、委任先ノードに提供されなければならない。
【課題を解決するための手段】
【０００９】
本発明の第１の構成に従えば、ネットワークルーティングプレフィックスと、暗号化によって生成されたインタフェース識別子を備えるＩＰｖ６アドレスに関して生成されたリクエストを検証する方法が提供される。このリクエストは、少なくともホストの公開鍵、１つ以上の更なるパラメータあるいは１つ以上の更なるパラメータを生成するための式あるいは式群、ＩＰｖ６ネットワークルーティングプレフィックスの範囲あるいはセットの指定、委任先ホストのアイデンティティ、公開鍵に関連付けられている秘密鍵を使用して、少なくともアイデンティティとＩＰｖ６ネットワークルーティングプレフィックスの範囲あるいはセットの指定を介して取得されるデジタル署名を含む、委任用の証明書を含んでいる。この方法は、ＩＰｖ６アドレスのネットワークルーティングプレフィックスが範囲の指定に含まれることを検証すること、公開鍵と更なるパラメータ（群）が暗号化によって生成されたインタフェース識別子を生成するために使用できるかを検証すること、公開鍵を使用して署名を検証することを含んでいる。
【００１０】
本発明の実施形態は、これらのＩＰｖ６アドレスがまだ生成されていない場合にでさえ、そのＩＰｖ６アドレスに対する責任を更なるホストに委任することを許容する。アドレスが使用されることになると、ホスト間の後続のシグナリングが削減される、あるいはより一層解消される。
【００１１】
実施形態に従えば、１つ以上の更なるパラメータは、修飾子を含んでいる。この修飾子は、ランダム性の度合をアドレス生成処理に導入する。より好ましくは、証明書は、インタフェース識別子が生成される毎に修飾子が変更するように、その修飾子を生成するための式を含んでいる。１つ以上の更なるパラメータは、１つ以上の拡張を含んでいても良い。
【００１２】
上記のＩＰｖ６ネットワークルーティングプレフィックスの範囲あるいはセットは、すべての利用可能なプレフィックスのサブセットであっても良い。選択的には、ＩＰｖ６ネットワークルーティングプレフィックスの範囲あるいはセットの指定は、すべての利用可能なルーティングプレフィックスを指定することができる。即ち、証明書は、委任先ノードに、すべてのルーティングプレフィックスに関して動作することを認可する。
【００１３】
公開鍵と更なるパラメータ（群）を検証するステップは、検証処理において、ＩＰｖ６アドレスのネットワークルーティングプレフィックスを使用し、かつハッシュアルゴリズムを採用することを含んでいても良い。ハッシュアルゴリズムは、公開鍵を使用して、署名を検証するためにも使用されても良い。
【００１４】
本発明の第２の構成に従えば、委任用の証明書を生成するように構成されている第１のプロセッサを備えるＩＰｖ６ホストが提供される。この証明書は、少なくともホストの公開鍵と、１つ以上の更なるパラメータあるいは１つ以上の更なるパラメータを生成するための式あるいは式群、ＩＰｖ６ネットワークルーティングプレフィックスの範囲あるいはセットの指定、委任先ホストのアイデンティティ、公開鍵に関連付けられている秘密鍵を使用して、少なくともアイデンティティと、ＩＰｖ６ネットワークルーティングプレフィックスの範囲あるいはセットの指定を介して取得されるデジタル署名を含んでいる。公開鍵と１つ以上の更なるパラメータは、暗号化によって生成されたアドレスのインタフェース識別子の部分を計算するために使用することができる。ホストは、更に、委任先ホストに証明書を提供するための出力と、少なくとも公開鍵と１つ以上の更なるパラメータを使用して、インタフェース識別子を生成し、暗号化によって生成されたアドレスを生成するために、インタフェース識別子と、ネットワークルーティングプレフィックスの範囲あるいはセット内に含まれるネットワークルーティングプレフィックスとを組み合わせるように構成されている第２のプロセッサとを備える。この出力は、更に、暗号化によって生成されたアドレスが生成されている場合に、委任先ホストへ、暗号化によって生成されたアドレスを含む通知を送信するように構成されていても良い。
【００１５】
本発明の第３の構成に従えば、ピアＩＰｖ６ホストから委任用の証明書を受信するための第１の入力を備えるＩＰｖ６ホストが提供される。この証明書は、少なくともピアＩＰｖ６ホストの公開鍵と、１つ以上の更なるパラメータあるいは１つ以上の更なるパラメータを生成するための式あるいは式群、ＩＰｖ６ネットワークルーティングプレフィックスの範囲あるいはセットの指定、ＩＰｖ６ホストのアイデンティティ、公開鍵に関連付けられている秘密鍵を使用して、少なくともアイデンティティとＩＰｖ６ネットワークルーティングプレフィックスの範囲あるいはセットの指定を介して取得されるデジタル署名を含んでいる。ホストは、更に、ピアＩＰｖ６ホストが証明書をマッピングしている暗号化によって生成されたアドレスを使用していることの通知を、ピアＩＰｖ６ホストから受信するための第２の入力と、暗号化によって生成されたアドレスについてのリクエストをサードパーティノードに送信し、かつ証明書をリクエストに含めるための出力とを備えている。
【００１６】
本発明の第４の構成に従えば、少なくともホストの公開鍵と、１つ以上の更なるパラメータあるいは１つ以上の更なるパラメータを生成するための式あるいは式群、ＩＰｖ６ネットワークルーティングプレフィックスの範囲あるいはセットの指定、委任先ホストのアイデンティティ、公開鍵に関連付けられている秘密鍵を使用して、少なくともアイデンティティとＩＰｖ６ネットワークルーティングプレフィックスの範囲あるいはセットの指定を介して取得されるデジタル署名を含む委任用の証明書が記憶されているコンピュータ記憶媒体が提供される。
【図面の簡単な説明】
【００１７】
【図１】新規のＣＧＡ委任用の証明書に対する構造例を示す図である。
【図２】ＣＧＡ委任用の証明書の生成及び使用に関与する通信システムの構成要素を示す図である。
【図３】ＩＰｖ６アドレスについて生成されるリクエストを検証するための処理を示すフロー図である。
【発明を実施するための形態】
【００１８】
いくつかの別のノード（「委任先（delegated）」ノード）への暗号化によって生成されたＩＰアドレス（ＣＧＡ）がまだ未定である限り、ＩＰｖ６ノードあるいはホスト（「委任元（delegating）」ノード）に責任を委任することできることを許容するために、本明細書では、これらの未定のＣＧＡを生成するために必要とされる情報を含む証明書を、委任元ノードで生成することを含むメカニズムが提案される。この証明書は、委任元ノードの秘密鍵で生成される署名を含み、そして、委任先ノードへ提供される。サードパーティに証明書を提示することによって、委任先ノードは、その後、要求されたＣＧＡに対して委任された責任を証明することができる。
【００１９】
委任メカニズムをより詳細に検討すると、まだ未定のＣＧＡを生成することについての責任を委任したいノードは、図１に示されるデータ構造を有する証明書を生成する。この証明書は、新規のＣＧＡデータ構造と委任先ノードのアイデンティティを含んでいる。このアイデンティティは、委任先ノードに属する公開鍵であっても良い。新規のデータ構造は、修飾子、委任元ノードの公開鍵、任意の拡張、及び他の許容されるネットワークルーティングプレフィックスの範囲、セット、あるいは他の定義からなる。許容されるプレフィックスは、例えば、ブルームフィルタ（Bloom filter）を使用してアルゴリズム的に定義されても良いし、あるいは、実際には、データ構造は、あらゆるプレフィックスが許容されることの表示を含んでいても良い。むしろ、単一の修飾子の値を定義すると、データ構造は、修飾子を生成するための手段、例えば、アルゴリムあるいはアルゴリズムのリファレンスを識別することができ、これによって、修飾子は、既知の入力値、例えば、ネットワークルーティングプレフィックスと現在時刻から、確定的に生成することができる。時刻が使用される場合、ＣＧＡ群が期限を定められることになる。適切な粗粒度、例えば、１時間間隔、が使用されるべきである。同様に、任意の使用される拡張は、アルゴリズム的に定義されても良い。
【００２０】
ＣＧＡについて要求されるセキュリティレベルが、その最低値（ＲＦＣ３９７２に従えば、即ち、ｓｅｃ＝０）に設定されると想定すると、修飾子を生成するためのアルゴリズムは、容易に定義することができる。より複雑な検討項目は、ｓｅｃ＞０の場合である。
【００２１】
委任元ノードは、自身の秘密鍵で生成される署名を証明書に含め、その証明書を委任先ノードへ提供する。これは、任意の適切なメカニズム、例えば、ＩＥＴＦ ＲＦＣ３９７２のセクション６に記載されるメカニズムを使用して実行することができる。当業者には明らかなように、署名は、ＣＧＡデータ構造にバインドされる。その後のいくつかの時点で、委任元ノードは、自身のためのＣＧＡを生成することになる。これを実行するために、必要であれば、指定されたアルゴリズム（群）を使用して修飾子（及び任意の拡張）を生成し、かつ適切なネットワークルーティングプレフィックスを選択あるいは生成して、ＲＦＣ３９７２のセクションで提示される処理を実行する。
【００２２】
この時点で、委任元ノードは、自身の新規のＩＰｖ６アドレスを委任先ノードへ通知することになる。続いて、委任先ノードがサードパーティノード（「検証（verifying）」ノード）に、新規のＣＧＡについて動作することをリクエストしたい場合、委任先ノードは、そのリクエストに証明書を含めるべきである。検証ノードは、リクエストを検証するために以下の動作を実行する。
【００２３】
・ＣＧＡからネットワークルーティングプレフィックスを抽出し、それが、証明書のＣＧＡデータ構造で定義される任意のセットあるいは範囲内におさまるかを検証する。
【００２４】
・次に、データ構造から修飾子を抽出あるいは生成し、それとともに、委任元ノードの公開鍵と任意の拡張（群）を抽出する。
【００２５】
・ＣＧＡ生成中に使用される実衝突カウント値は、検証の時点では判明しないので、検証ノードは、連続的に衝突カウントを１、１及び２に設定しなければならず、そして、ＣＧＡが委任元ノードの公開鍵に属することを検証するために、ＩＥＴＦ ＲＦＣ３９７２のセクション５のアルゴリズムを実行しなければならない。
【００２６】
・ＣＧＡが正しく検証されるイベントでは、検証ノードは、次に、証明書内に含まれる署名が、委任元ノードの公開鍵に対応する秘密鍵を使用して生成されているかを検証することを試行する。
【００２７】
・署名が正しく検証されるイベントでは、検証ノードは、リクエストの送信者、即ち、委任先ノードが、証明所内に含まれるアイデンティティの所有者であるかを検証するための試行を行っても良い。そのアイデンティティが更なる公開鍵である場合、これは、委任先ノードの公開鍵を使用して生成されるリクエスト内に含まれる更なる署名を検証することを含んでいても良い。
【００２８】
セキュリティレベルが低、即ち、ｓｅｃ＝０に設定される場合、検証ノードに対してハッシュ２を計算する必要はない。しかしながら、ｓｅｃ＞０である場合、ＲＦＣ３９７２のセクション５のステップ６及び７で記載される処理が実行されなければならない。
【００２９】
図２は、委任元ノード１を示している。この委任元ノード１は、上述の委任用の証明書を生成するように構成されている第１のプロセッサ２を備えている。第２のプロセッサ３は、証明書内に含まれるパラメータを使用してＣＧＡを生成するように構成されている。証明書と、ＣＧＡの生成の通知の両方が、出力４を介して、委任先ノード５に送信される。この委任先ノード５は、第１の入力６で証明書を受信し、第２の入力７で通知を受信する。プロセッサ９は、委任されたＣＧＡについてのリクエスト群を生成することと、それらを証明書とともに検証ノード１０へ送信することを担当する。リクエスト群は、検証ノード１０によって入力１１で受信される。３つの段階の検証処理が、証明書について実行される。即ち、ルーティングプレフィックスが範囲１２内であるかを検証し、ＩＩＤが公開鍵１３にマッチするかを検証し、署名１４を検証する。
【００３０】
図３は、証明書を検証するための処理を示すフロー図である。図示されるステップ群は、検証ノードで、委任先ノードからのリクエストを受信すること（ステップ１００）、ＣＧＡからルーティングプレフィックスを抽出すること（ステップ１０１）、ルーティングプレフィックスが証明書内で指定される範囲内にあるかを検証すること（ステップ１０２）、ＣＧＡのＩＩＤを検証すること（ステップ１０３）、及び署名を検証すること（ステップ１０４）を含んでいる。任意のステップで検証が失敗する場合、リクエストは拒否される（ステップ１０６）。すべての検証ステップが成功する場合、リクエストは受け付けられ、処理される（ステップ１０５）。
【００３１】
当業者には、本発明の範囲を逸脱することなく、上述の実施形態を様々に変形することができることが理解されるであろう。
【技術分野】
【０００１】
本発明は、ＩＰアドレス委任（delegation：デリゲーション）に関するものであり、特に、暗号化によって生成されたアドレス（Cryptographically Generated Address）を所有するノードから別のノードへ、その暗号化によって生成されたアドレスについての責任の委任に関するものである。
【背景技術】
【０００２】
ＩＰアドレスは、１２８ビット長である。アドレスの先頭６４ビットはルーティングプレフィックを形成し、これは、ＩＰ端末あるいはノードによって使用される、インターネットアクセスノード（あるいは、いわゆる「ローカルリンク」）を固有に識別する。残りの６４ビットはホストサフィックスを形成し、これは、アクセスノード（あるいはローカルリンク内）に対する移動端末を固有に識別する。ホストサフィックスは、「インタフェース識別子」と呼ばれる。これは、アクセスインタフェースを介して固有にホストを識別するからである。典型的には、ホストをアクセスノードに登録すると、ホストはアクセスノードから送信される広告メッセージから、アクセスノードのルーティングプレフィックスを学習する。ＩＥＴＦ ＲＦＣ３０４１に従えば、次に、ホストは、ホストによって生成される乱数を使用して、自身のインタフェース識別子を生成する。ホストは、更に、リンクレイヤアドレスを使用して、インタフェースを識別子を生成することもできる。このリンクレイヤアドレスは、例えば、アクセスネットワークによって使用されるＭＡＣレイヤアドレスである。
【０００３】
国際公開第０２／０７６０６０号は、一方向符号化関数、例えば、ハッシュ関数を使用して、インタフェース識別子の暗号化バージョンをどのようにして生成できるか、また、このインタフェース識別子を別のピア（peer）ユーザにどのように提供できるかについて記載している。ここで、このピアユーザは、ノードが、ＩＰアドレスのインタフェース識別子部分の所有者であることを検証することができる。このような暗号化によって生成されたアドレス（cryptographically generated address）は、ＣＧＡとして知られている。ＣＧＡは、例えば、サービス拒否攻撃を防止することを支援するためのセキュリティレベルを提供する。ここで、サービス拒否攻撃は、攻撃者が、ノードを使用したいことを、ＩＰアドレスの所有者に要求することである。ＣＧＡは、ＩＥＴＦ ＲＦＣ３９７２で標準化されていて、また、ＩＥＴＦ ＲＦＣ３９７１で標準化されているセキュア近隣ディスカバリ（ＳｅＮＤ）プロトコルで使用されている。
【０００４】
ＲＦＣ３９７２に従えば、ＣＧＡは以下のようにして生成される。
【０００５】
ハッシュ１＝ハッシュ（修飾子｜プレフィックス｜公開鍵｜拡張）
ＩＰｖ６アドレス＝プレフィックス｜ハッシュ１（セキュリティレベルと他の要件に従って生成される所定のビット付き）
ここで、「プレフィックス（prefix）」はネットワークルーティングプレフィックスであり、「ハッシュ（hash）」は暗号化ハッシュ関数（ＳＨＡ−１）であり、「公開鍵」はアドレスを生成するノードの公開鍵であり、「拡張」は標準化情報を搬送するための現行は未使用のフィールドである。「修飾子」はセキュリティを高めかつランダム性を増すために、ノードによって生成される１２８ビット値である。より詳しくは、必要とされるセキュリティレベルに依存して、修飾子値は、一定の連続するデータ（修飾子と公開鍵を含む）となるように選択され、このデータは値（「ハッシュ２（Hash2）」）をハッシュする。この値は、左端ビット位置において指定番号「０」を有している。
【０００６】
ＣＧＡの所有権を証明するためには、ノードは、証明書を提供することができるようにしなければならない。この証明書には、ＣＧＡアドレスのインタフェース識別子（ＩＩＤ）部分、修飾子、公開鍵、及び任意の拡張を含み、これらがＣＧＡデータ構造として構成される。証明書は、ノードの公開鍵を使用して、送信されるメッセージ（１２８ビットのＣＧＡタイプタグで連結されている）に渡って取得されるデジタル署名（ＳＨＡ−１）を含んでいる。証明書を受信するピアノードは、まず、ハッシュ２を計算し、それが左端位置で正しい番号の「０」を有しているかを検証する。そのような場合、ピアノードは、ハッシュ１を計算し、これとＩＩＤとを比較する。これによって、ＩＩＤが公開鍵と秘密鍵のペアに属していることを検証し、更に、検証された公開鍵を使用して、署名処理の逆処理を行うことによって署名を検証する。この２番目のステップは、送信側が実際に公開鍵を所有し、かつ単純に悪用していないことを証明し、また、メッセージが、要求された送信側から発信されたことを証明する。
【０００７】
ＣＧＡを所有するホスト（「委任元（delegating）」ノード）は、そのアドレスについての責任をいくつかの更なるノード（「委任先（delegated）」ノード）に委任することができ、例えば、委任先ノードに、委任元ノードに向けられているトラフィックをリクエストすることを許容する。これは、委任先ノードに証明書を提供することによって達成され、この証明書は、ＣＧＡ、ＣＧＡデータ構造、委任先ノードのアイデンティティ、委任元ノードの秘密鍵を使用して生成される署名を含んでいる。要求されたＣＧＡを使用することが許容されていることをサードパーティに証明するために、委任先ノードは、証明書をサードパーティに提供し、このサードパーティは、ＩＩＤが公開鍵に属することを検証し、かつ証明書が所有者の公開鍵によって有効に署名されることを検証することができる。アイデンティティが委任先ノードの公開鍵である場合、委任先ノードは、自身の秘密鍵で、ＣＧＡに関連する任意のリクエストを署名することができる。つまり、サードパーティに、委任先ノードが要求されたアイデンティティを所有することを証明することを許容する。
【発明の概要】
【発明が解決しようとする課題】
【０００８】
この委任に対する方法に付随する問題は、委任元ノードによって委任先ノードへ提供される証明書が、単一のＣＧＡと結び付けられることである。例えば、モビリティティと新規のネットワークルーティングプレフィックスの自身の使用のために、委任元ノードが自身のＩＰｖ６アドレスを変更するイベントでは、新規の証明書は、委任先ノードに提供されなければならない。
【課題を解決するための手段】
【０００９】
本発明の第１の構成に従えば、ネットワークルーティングプレフィックスと、暗号化によって生成されたインタフェース識別子を備えるＩＰｖ６アドレスに関して生成されたリクエストを検証する方法が提供される。このリクエストは、少なくともホストの公開鍵、１つ以上の更なるパラメータあるいは１つ以上の更なるパラメータを生成するための式あるいは式群、ＩＰｖ６ネットワークルーティングプレフィックスの範囲あるいはセットの指定、委任先ホストのアイデンティティ、公開鍵に関連付けられている秘密鍵を使用して、少なくともアイデンティティとＩＰｖ６ネットワークルーティングプレフィックスの範囲あるいはセットの指定を介して取得されるデジタル署名を含む、委任用の証明書を含んでいる。この方法は、ＩＰｖ６アドレスのネットワークルーティングプレフィックスが範囲の指定に含まれることを検証すること、公開鍵と更なるパラメータ（群）が暗号化によって生成されたインタフェース識別子を生成するために使用できるかを検証すること、公開鍵を使用して署名を検証することを含んでいる。
【００１０】
本発明の実施形態は、これらのＩＰｖ６アドレスがまだ生成されていない場合にでさえ、そのＩＰｖ６アドレスに対する責任を更なるホストに委任することを許容する。アドレスが使用されることになると、ホスト間の後続のシグナリングが削減される、あるいはより一層解消される。
【００１１】
実施形態に従えば、１つ以上の更なるパラメータは、修飾子を含んでいる。この修飾子は、ランダム性の度合をアドレス生成処理に導入する。より好ましくは、証明書は、インタフェース識別子が生成される毎に修飾子が変更するように、その修飾子を生成するための式を含んでいる。１つ以上の更なるパラメータは、１つ以上の拡張を含んでいても良い。
【００１２】
上記のＩＰｖ６ネットワークルーティングプレフィックスの範囲あるいはセットは、すべての利用可能なプレフィックスのサブセットであっても良い。選択的には、ＩＰｖ６ネットワークルーティングプレフィックスの範囲あるいはセットの指定は、すべての利用可能なルーティングプレフィックスを指定することができる。即ち、証明書は、委任先ノードに、すべてのルーティングプレフィックスに関して動作することを認可する。
【００１３】
公開鍵と更なるパラメータ（群）を検証するステップは、検証処理において、ＩＰｖ６アドレスのネットワークルーティングプレフィックスを使用し、かつハッシュアルゴリズムを採用することを含んでいても良い。ハッシュアルゴリズムは、公開鍵を使用して、署名を検証するためにも使用されても良い。
【００１４】
本発明の第２の構成に従えば、委任用の証明書を生成するように構成されている第１のプロセッサを備えるＩＰｖ６ホストが提供される。この証明書は、少なくともホストの公開鍵と、１つ以上の更なるパラメータあるいは１つ以上の更なるパラメータを生成するための式あるいは式群、ＩＰｖ６ネットワークルーティングプレフィックスの範囲あるいはセットの指定、委任先ホストのアイデンティティ、公開鍵に関連付けられている秘密鍵を使用して、少なくともアイデンティティと、ＩＰｖ６ネットワークルーティングプレフィックスの範囲あるいはセットの指定を介して取得されるデジタル署名を含んでいる。公開鍵と１つ以上の更なるパラメータは、暗号化によって生成されたアドレスのインタフェース識別子の部分を計算するために使用することができる。ホストは、更に、委任先ホストに証明書を提供するための出力と、少なくとも公開鍵と１つ以上の更なるパラメータを使用して、インタフェース識別子を生成し、暗号化によって生成されたアドレスを生成するために、インタフェース識別子と、ネットワークルーティングプレフィックスの範囲あるいはセット内に含まれるネットワークルーティングプレフィックスとを組み合わせるように構成されている第２のプロセッサとを備える。この出力は、更に、暗号化によって生成されたアドレスが生成されている場合に、委任先ホストへ、暗号化によって生成されたアドレスを含む通知を送信するように構成されていても良い。
【００１５】
本発明の第３の構成に従えば、ピアＩＰｖ６ホストから委任用の証明書を受信するための第１の入力を備えるＩＰｖ６ホストが提供される。この証明書は、少なくともピアＩＰｖ６ホストの公開鍵と、１つ以上の更なるパラメータあるいは１つ以上の更なるパラメータを生成するための式あるいは式群、ＩＰｖ６ネットワークルーティングプレフィックスの範囲あるいはセットの指定、ＩＰｖ６ホストのアイデンティティ、公開鍵に関連付けられている秘密鍵を使用して、少なくともアイデンティティとＩＰｖ６ネットワークルーティングプレフィックスの範囲あるいはセットの指定を介して取得されるデジタル署名を含んでいる。ホストは、更に、ピアＩＰｖ６ホストが証明書をマッピングしている暗号化によって生成されたアドレスを使用していることの通知を、ピアＩＰｖ６ホストから受信するための第２の入力と、暗号化によって生成されたアドレスについてのリクエストをサードパーティノードに送信し、かつ証明書をリクエストに含めるための出力とを備えている。
【００１６】
本発明の第４の構成に従えば、少なくともホストの公開鍵と、１つ以上の更なるパラメータあるいは１つ以上の更なるパラメータを生成するための式あるいは式群、ＩＰｖ６ネットワークルーティングプレフィックスの範囲あるいはセットの指定、委任先ホストのアイデンティティ、公開鍵に関連付けられている秘密鍵を使用して、少なくともアイデンティティとＩＰｖ６ネットワークルーティングプレフィックスの範囲あるいはセットの指定を介して取得されるデジタル署名を含む委任用の証明書が記憶されているコンピュータ記憶媒体が提供される。
【図面の簡単な説明】
【００１７】
【図１】新規のＣＧＡ委任用の証明書に対する構造例を示す図である。
【図２】ＣＧＡ委任用の証明書の生成及び使用に関与する通信システムの構成要素を示す図である。
【図３】ＩＰｖ６アドレスについて生成されるリクエストを検証するための処理を示すフロー図である。
【発明を実施するための形態】
【００１８】
いくつかの別のノード（「委任先（delegated）」ノード）への暗号化によって生成されたＩＰアドレス（ＣＧＡ）がまだ未定である限り、ＩＰｖ６ノードあるいはホスト（「委任元（delegating）」ノード）に責任を委任することできることを許容するために、本明細書では、これらの未定のＣＧＡを生成するために必要とされる情報を含む証明書を、委任元ノードで生成することを含むメカニズムが提案される。この証明書は、委任元ノードの秘密鍵で生成される署名を含み、そして、委任先ノードへ提供される。サードパーティに証明書を提示することによって、委任先ノードは、その後、要求されたＣＧＡに対して委任された責任を証明することができる。
【００１９】
委任メカニズムをより詳細に検討すると、まだ未定のＣＧＡを生成することについての責任を委任したいノードは、図１に示されるデータ構造を有する証明書を生成する。この証明書は、新規のＣＧＡデータ構造と委任先ノードのアイデンティティを含んでいる。このアイデンティティは、委任先ノードに属する公開鍵であっても良い。新規のデータ構造は、修飾子、委任元ノードの公開鍵、任意の拡張、及び他の許容されるネットワークルーティングプレフィックスの範囲、セット、あるいは他の定義からなる。許容されるプレフィックスは、例えば、ブルームフィルタ（Bloom filter）を使用してアルゴリズム的に定義されても良いし、あるいは、実際には、データ構造は、あらゆるプレフィックスが許容されることの表示を含んでいても良い。むしろ、単一の修飾子の値を定義すると、データ構造は、修飾子を生成するための手段、例えば、アルゴリムあるいはアルゴリズムのリファレンスを識別することができ、これによって、修飾子は、既知の入力値、例えば、ネットワークルーティングプレフィックスと現在時刻から、確定的に生成することができる。時刻が使用される場合、ＣＧＡ群が期限を定められることになる。適切な粗粒度、例えば、１時間間隔、が使用されるべきである。同様に、任意の使用される拡張は、アルゴリズム的に定義されても良い。
【００２０】
ＣＧＡについて要求されるセキュリティレベルが、その最低値（ＲＦＣ３９７２に従えば、即ち、ｓｅｃ＝０）に設定されると想定すると、修飾子を生成するためのアルゴリズムは、容易に定義することができる。より複雑な検討項目は、ｓｅｃ＞０の場合である。
【００２１】
委任元ノードは、自身の秘密鍵で生成される署名を証明書に含め、その証明書を委任先ノードへ提供する。これは、任意の適切なメカニズム、例えば、ＩＥＴＦ ＲＦＣ３９７２のセクション６に記載されるメカニズムを使用して実行することができる。当業者には明らかなように、署名は、ＣＧＡデータ構造にバインドされる。その後のいくつかの時点で、委任元ノードは、自身のためのＣＧＡを生成することになる。これを実行するために、必要であれば、指定されたアルゴリズム（群）を使用して修飾子（及び任意の拡張）を生成し、かつ適切なネットワークルーティングプレフィックスを選択あるいは生成して、ＲＦＣ３９７２のセクションで提示される処理を実行する。
【００２２】
この時点で、委任元ノードは、自身の新規のＩＰｖ６アドレスを委任先ノードへ通知することになる。続いて、委任先ノードがサードパーティノード（「検証（verifying）」ノード）に、新規のＣＧＡについて動作することをリクエストしたい場合、委任先ノードは、そのリクエストに証明書を含めるべきである。検証ノードは、リクエストを検証するために以下の動作を実行する。
【００２３】
・ＣＧＡからネットワークルーティングプレフィックスを抽出し、それが、証明書のＣＧＡデータ構造で定義される任意のセットあるいは範囲内におさまるかを検証する。
【００２４】
・次に、データ構造から修飾子を抽出あるいは生成し、それとともに、委任元ノードの公開鍵と任意の拡張（群）を抽出する。
【００２５】
・ＣＧＡ生成中に使用される実衝突カウント値は、検証の時点では判明しないので、検証ノードは、連続的に衝突カウントを１、１及び２に設定しなければならず、そして、ＣＧＡが委任元ノードの公開鍵に属することを検証するために、ＩＥＴＦ ＲＦＣ３９７２のセクション５のアルゴリズムを実行しなければならない。
【００２６】
・ＣＧＡが正しく検証されるイベントでは、検証ノードは、次に、証明書内に含まれる署名が、委任元ノードの公開鍵に対応する秘密鍵を使用して生成されているかを検証することを試行する。
【００２７】
・署名が正しく検証されるイベントでは、検証ノードは、リクエストの送信者、即ち、委任先ノードが、証明所内に含まれるアイデンティティの所有者であるかを検証するための試行を行っても良い。そのアイデンティティが更なる公開鍵である場合、これは、委任先ノードの公開鍵を使用して生成されるリクエスト内に含まれる更なる署名を検証することを含んでいても良い。
【００２８】
セキュリティレベルが低、即ち、ｓｅｃ＝０に設定される場合、検証ノードに対してハッシュ２を計算する必要はない。しかしながら、ｓｅｃ＞０である場合、ＲＦＣ３９７２のセクション５のステップ６及び７で記載される処理が実行されなければならない。
【００２９】
図２は、委任元ノード１を示している。この委任元ノード１は、上述の委任用の証明書を生成するように構成されている第１のプロセッサ２を備えている。第２のプロセッサ３は、証明書内に含まれるパラメータを使用してＣＧＡを生成するように構成されている。証明書と、ＣＧＡの生成の通知の両方が、出力４を介して、委任先ノード５に送信される。この委任先ノード５は、第１の入力６で証明書を受信し、第２の入力７で通知を受信する。プロセッサ９は、委任されたＣＧＡについてのリクエスト群を生成することと、それらを証明書とともに検証ノード１０へ送信することを担当する。リクエスト群は、検証ノード１０によって入力１１で受信される。３つの段階の検証処理が、証明書について実行される。即ち、ルーティングプレフィックスが範囲１２内であるかを検証し、ＩＩＤが公開鍵１３にマッチするかを検証し、署名１４を検証する。
【００３０】
図３は、証明書を検証するための処理を示すフロー図である。図示されるステップ群は、検証ノードで、委任先ノードからのリクエストを受信すること（ステップ１００）、ＣＧＡからルーティングプレフィックスを抽出すること（ステップ１０１）、ルーティングプレフィックスが証明書内で指定される範囲内にあるかを検証すること（ステップ１０２）、ＣＧＡのＩＩＤを検証すること（ステップ１０３）、及び署名を検証すること（ステップ１０４）を含んでいる。任意のステップで検証が失敗する場合、リクエストは拒否される（ステップ１０６）。すべての検証ステップが成功する場合、リクエストは受け付けられ、処理される（ステップ１０５）。
【００３１】
当業者には、本発明の範囲を逸脱することなく、上述の実施形態を様々に変形することができることが理解されるであろう。
【特許請求の範囲】
【請求項１】
ネットワークルーティングプレフィックスと、暗号化によって生成されたインタフェース識別子を備えるＩＰｖ６アドレスに関して生成されるリクエストを検証する方法であって、
前記リクエストは、ホストの少なくとも公開鍵、１つ以上の更なるパラメータあるいは１つ以上の更なるパラメータを生成するための式あるいは式群、ＩＰｖ６ネットワークルーティングプレフィックスの範囲あるいはセットの指定、委任先ホストのアイデンティティ、前記公開鍵に関連付けられている秘密鍵を使用して、少なくとも前記アイデンティティと前記ＩＰｖ６ネットワークルーティングプレフィックスの範囲あるいはセットの指定を介して取得されるデジタル署名を含む委任用の証明書を含み、
前記方法は、
前記ＩＰｖ６アドレスの前記ネットワークルーティングプレフィックスが前記指定に含まれることを検証するステップと、
前記公開鍵と前記更なるパラメータ（群）が前記暗号化によって生成されたインタフェース識別子を生成するために使用できるかを検証するステップと、
前記公開鍵を使用して前記署名を検証するステップと
を備えることを特徴とする方法。
【請求項２】
前記１つ以上の更なるパラメータは、修飾子を含んでいる
ことを特徴とする請求項１に記載の方法。
【請求項３】
前記証明書は、インタフェース識別子が生成される毎に前記修飾子を変更するように、前記修飾子を生成するための式を含んでいる
ことを特徴とする請求項２に記載の方法。
【請求項４】
前記１つ以上の更なるパラメータは、１つ以上の拡張を含んでいる
ことを特徴とする請求項１乃至３のいずれか１項に記載の方法。
【請求項５】
前記ＩＰｖ６ネットワークルーティングプレフィックスの範囲あるいはセットは、利用可能なすべてのルーティングプレフィックスのサブセットである
ことを特徴とする請求項１乃至４のいずれか１項に記載の方法。
【請求項６】
前記ＩＰｖ６ネットワークルーティングプレフィックスの範囲あるいはセットの指定は、利用可能なすべてのルーティングプレフィックスを指定する
ことを特徴とする請求項１乃至５のいずれか１項に記載の方法。
【請求項７】
前記公開鍵と前記更なるパラメータ（群）が前記暗号化によって生成されたインタフェース識別子を生成するために使用できるかを検証するステップは、検証処理において、前記ＩＰｖ６アドレスの前記ネットワークルーティングプレフィックスを使用することを含む
ことを特徴とする請求項１乃至６のいずれか１項に記載の方法。
【請求項８】
前記公開鍵と前記更なるパラメータ（群）が前記暗号化によって生成されたインタフェース識別子を生成するために使用できるかを検証するステップと、前記公開鍵を使用して前記署名を検証するステップとは、それぞれハッシュアルゴリズムを利用する
ことを特徴とする請求項１乃至７のいずれか１項に記載の方法。
【請求項９】
ＩＰｖ６ホストであって、
委任用の証明書を生成するように構成されている第１のプロセッサであって、前記証明書が、少なくとも当該ＩＰｖ６ホストの公開鍵と、１つ以上の更なるパラメータあるいは１つ以上の更なるパラメータを生成するための式あるいは式群、ＩＰｖ６ネットワークルーティングプレフィックスの範囲あるいはセットの指定、委任先ホストのアイデンティティ、前記公開鍵に関連付けられている秘密鍵を使用して、少なくとも前記アイデンティティと前記ＩＰｖ６ネットワークルーティングプレフィックスの範囲あるいはセットの指定を介して取得されるデジタル署名を含み、前記公開鍵と前記１つ以上のパラメータが、暗号化によって生成されたアドレスのインタフェース識別子部分を計算するために使用することができる、第１のプロセッサと、
前記証明書を前記委任先ホストに提供するための出力と、
少なくとも前記公開鍵と前記１つ以上の更なるパラメータを使用して、インタフェース識別子を生成し、暗号化によって生成されたアドレスを生成するために、前記インタフェース識別子と、前記ネットワークルーティングプレフィックスの範囲あるいはセット内に含まれるネットワークルーティングプレフィックスとを組み合わせるように構成されている第２のプロセッサと
を備えることを特徴とするＩＰｖ６ホスト。
【請求項１０】
前記出力は、更に、暗号化によって生成されたアドレスが生成されている場合に、前記委任先ホストへ、前記暗号化によって生成されたアドレスを含む通知を送信するように構成されている
ことを特徴とする請求項９に記載のＩＰｖ６ホスト。
【請求項１１】
ＩＰｖ６ホストであって、
ピアＩＰｖ６ホストから委任用の証明書を受信するための第１の入力であって、前記証明書が、少なくとも前記ピアＩＰｖ６ホストの公開鍵と、１つ以上の更なるパラメータあるいは１つ以上の更なるパラメータを生成するための式あるいは式群、ＩＰｖ６ネットワークルーティングプレフィックスの範囲あるいはセットの指定、当該ＩＰｖ６ホストのアイデンティティ、前記公開鍵に関連付けられている秘密鍵を使用して、少なくとも前記アイデンティティと前記ＩＰｖ６ネットワークルーティングプレフィックスの範囲あるいはセットの指定を介して取得されるデジタル署名を含む、第１の入力と、
前記ピアＩＰｖ６ホストが、前記証明書をマッピングしている暗号化によって生成されたアドレスを使用していることの通知を、前記ピアＩＰｖ６ホストから受信するための第２の入力と、
前記暗号化によって生成されたアドレスについてのリクエストをサードパーティノードに送信し、かつ前記証明書を前記リクエストに含めるための出力と
を備えることを特徴とするＩＰｖ６ホスト。
【請求項１２】
少なくともホストの公開鍵と、１つ以上の更なるパラメータあるいは１つ以上の更なるパラメータを生成するための式あるいは式群、ＩＰｖ６ネットワークルーティングプレフィックスの範囲あるいはセットの指定、委任先ホストのアイデンティティ、前記公開鍵に関連付けられている秘密鍵を使用して、少なくとも前記アイデンティティと前記ＩＰｖ６ネットワークルーティングプレフィックスの範囲あるいはセットの指定を介して取得されるデジタル署名を含む委任用の証明書が記憶されているコンピュータ記憶媒体。
【請求項１】
ネットワークルーティングプレフィックスと、暗号化によって生成されたインタフェース識別子を備えるＩＰｖ６アドレスに関して生成されるリクエストを検証する方法であって、
前記リクエストは、ホストの少なくとも公開鍵、１つ以上の更なるパラメータあるいは１つ以上の更なるパラメータを生成するための式あるいは式群、ＩＰｖ６ネットワークルーティングプレフィックスの範囲あるいはセットの指定、委任先ホストのアイデンティティ、前記公開鍵に関連付けられている秘密鍵を使用して、少なくとも前記アイデンティティと前記ＩＰｖ６ネットワークルーティングプレフィックスの範囲あるいはセットの指定を介して取得されるデジタル署名を含む委任用の証明書を含み、
前記方法は、
前記ＩＰｖ６アドレスの前記ネットワークルーティングプレフィックスが前記指定に含まれることを検証するステップと、
前記公開鍵と前記更なるパラメータ（群）が前記暗号化によって生成されたインタフェース識別子を生成するために使用できるかを検証するステップと、
前記公開鍵を使用して前記署名を検証するステップと
を備えることを特徴とする方法。
【請求項２】
前記１つ以上の更なるパラメータは、修飾子を含んでいる
ことを特徴とする請求項１に記載の方法。
【請求項３】
前記証明書は、インタフェース識別子が生成される毎に前記修飾子を変更するように、前記修飾子を生成するための式を含んでいる
ことを特徴とする請求項２に記載の方法。
【請求項４】
前記１つ以上の更なるパラメータは、１つ以上の拡張を含んでいる
ことを特徴とする請求項１乃至３のいずれか１項に記載の方法。
【請求項５】
前記ＩＰｖ６ネットワークルーティングプレフィックスの範囲あるいはセットは、利用可能なすべてのルーティングプレフィックスのサブセットである
ことを特徴とする請求項１乃至４のいずれか１項に記載の方法。
【請求項６】
前記ＩＰｖ６ネットワークルーティングプレフィックスの範囲あるいはセットの指定は、利用可能なすべてのルーティングプレフィックスを指定する
ことを特徴とする請求項１乃至５のいずれか１項に記載の方法。
【請求項７】
前記公開鍵と前記更なるパラメータ（群）が前記暗号化によって生成されたインタフェース識別子を生成するために使用できるかを検証するステップは、検証処理において、前記ＩＰｖ６アドレスの前記ネットワークルーティングプレフィックスを使用することを含む
ことを特徴とする請求項１乃至６のいずれか１項に記載の方法。
【請求項８】
前記公開鍵と前記更なるパラメータ（群）が前記暗号化によって生成されたインタフェース識別子を生成するために使用できるかを検証するステップと、前記公開鍵を使用して前記署名を検証するステップとは、それぞれハッシュアルゴリズムを利用する
ことを特徴とする請求項１乃至７のいずれか１項に記載の方法。
【請求項９】
ＩＰｖ６ホストであって、
委任用の証明書を生成するように構成されている第１のプロセッサであって、前記証明書が、少なくとも当該ＩＰｖ６ホストの公開鍵と、１つ以上の更なるパラメータあるいは１つ以上の更なるパラメータを生成するための式あるいは式群、ＩＰｖ６ネットワークルーティングプレフィックスの範囲あるいはセットの指定、委任先ホストのアイデンティティ、前記公開鍵に関連付けられている秘密鍵を使用して、少なくとも前記アイデンティティと前記ＩＰｖ６ネットワークルーティングプレフィックスの範囲あるいはセットの指定を介して取得されるデジタル署名を含み、前記公開鍵と前記１つ以上のパラメータが、暗号化によって生成されたアドレスのインタフェース識別子部分を計算するために使用することができる、第１のプロセッサと、
前記証明書を前記委任先ホストに提供するための出力と、
少なくとも前記公開鍵と前記１つ以上の更なるパラメータを使用して、インタフェース識別子を生成し、暗号化によって生成されたアドレスを生成するために、前記インタフェース識別子と、前記ネットワークルーティングプレフィックスの範囲あるいはセット内に含まれるネットワークルーティングプレフィックスとを組み合わせるように構成されている第２のプロセッサと
を備えることを特徴とするＩＰｖ６ホスト。
【請求項１０】
前記出力は、更に、暗号化によって生成されたアドレスが生成されている場合に、前記委任先ホストへ、前記暗号化によって生成されたアドレスを含む通知を送信するように構成されている
ことを特徴とする請求項９に記載のＩＰｖ６ホスト。
【請求項１１】
ＩＰｖ６ホストであって、
ピアＩＰｖ６ホストから委任用の証明書を受信するための第１の入力であって、前記証明書が、少なくとも前記ピアＩＰｖ６ホストの公開鍵と、１つ以上の更なるパラメータあるいは１つ以上の更なるパラメータを生成するための式あるいは式群、ＩＰｖ６ネットワークルーティングプレフィックスの範囲あるいはセットの指定、当該ＩＰｖ６ホストのアイデンティティ、前記公開鍵に関連付けられている秘密鍵を使用して、少なくとも前記アイデンティティと前記ＩＰｖ６ネットワークルーティングプレフィックスの範囲あるいはセットの指定を介して取得されるデジタル署名を含む、第１の入力と、
前記ピアＩＰｖ６ホストが、前記証明書をマッピングしている暗号化によって生成されたアドレスを使用していることの通知を、前記ピアＩＰｖ６ホストから受信するための第２の入力と、
前記暗号化によって生成されたアドレスについてのリクエストをサードパーティノードに送信し、かつ前記証明書を前記リクエストに含めるための出力と
を備えることを特徴とするＩＰｖ６ホスト。
【請求項１２】
少なくともホストの公開鍵と、１つ以上の更なるパラメータあるいは１つ以上の更なるパラメータを生成するための式あるいは式群、ＩＰｖ６ネットワークルーティングプレフィックスの範囲あるいはセットの指定、委任先ホストのアイデンティティ、前記公開鍵に関連付けられている秘密鍵を使用して、少なくとも前記アイデンティティと前記ＩＰｖ６ネットワークルーティングプレフィックスの範囲あるいはセットの指定を介して取得されるデジタル署名を含む委任用の証明書が記憶されているコンピュータ記憶媒体。
【図１】
【図２】
【図３】
【図２】
【図３】
【公表番号】特表２０１１−５１５０４９（Ｐ２０１１−５１５０４９Ａ）
【公表日】平成２３年５月１２日（２０１１．５．１２）
【国際特許分類】
【出願番号】特願２０１０−５４９０１７（Ｐ２０１０−５４９０１７）
【出願日】平成２０年３月４日（２００８．３．４）
【国際出願番号】ＰＣＴ／ＥＰ２００８／０５２６３４
【国際公開番号】ＷＯ２００９／１０９２２１
【国際公開日】平成２１年９月１１日（２００９．９．１１）
【出願人】（５９８０３６３００）テレフオンアクチーボラゲット エル エム エリクソン（パブル） (2,266)
【Ｆターム（参考）】
【公表日】平成２３年５月１２日（２０１１．５．１２）
【国際特許分類】
【出願日】平成２０年３月４日（２００８．３．４）
【国際出願番号】ＰＣＴ／ＥＰ２００８／０５２６３４
【国際公開番号】ＷＯ２００９／１０９２２１
【国際公開日】平成２１年９月１１日（２００９．９．１１）
【出願人】（５９８０３６３００）テレフオンアクチーボラゲット エル エム エリクソン（パブル） (2,266)
【Ｆターム（参考）】
[ Back to top ]