(57)【要約】【課題】同一のアクセスノードに接続された２つのホストが、同一のインターフェース識別子を生成し、このために、同一のＩＰアドレスを生成してしまうことがある。【解決手段】ＩＰネットワークに接続されたノードにＩＰアドレスを対応付けるようにノードを動作させる方法。ＩＰアドレスは、ルーティング接頭部およびインターフェース識別部を含み、ノードは公開鍵と個人鍵の組を有している。本方法は、一方向性の符号化関数を用いて、公開鍵と個人鍵の組の公開鍵を有する複数のデータコンポーネントを対応付けることによりインターフェース識別部を生成するステップと、インターフェース識別部と公開鍵を有し、前記公開鍵と個人鍵の組の公開鍵で署名された証明書を生成するステップを有する。証明書をノードが有する公開鍵を用いて認証でき、また、証明書の内容を用いてインターフェース識別子を再構築することにより、インターフェース識別子の所有権が検証される。【選択図】図１
2008271601.tif 000002
【特許請求の範囲】
【請求項１】
ＩＰネットワークに接続されたノードにＩＰアドレスを対応付けるように前記ノードを動作させる方法であって、該ＩＰアドレスは、ルーティング接頭部およびインターフェース識別部を含み、前記ノードは公開鍵と個人鍵の組を有しており、該方法は、
一方向性の符号化関数を用いて、前記公開鍵と個人鍵の組の公開鍵を有する複数のデータコンポーネントを対応付けることにより前記インターフェース識別部を生成するステップと、
前記インターフェース識別部と前記公開鍵を有し、前記公開鍵と個人鍵の組の公開鍵で署名された証明書を生成するステップであって、前記証明書を前記ノードが有する公開鍵を用いて認証できるように、また、前記証明書の内容を用いて前記インターフェース識別子を再構築することにより、前記インターフェース識別子の所有権が検証されるようになっている前記生成ステップを有することを特徴とする方法。
【請求項２】
請求項１記載の方法において、前記一方向性の符号化関数はハッシュ関数であることを特徴とする方法。
【請求項３】
請求項１または２記載の方法において、前記データコンポーネントは、ランダム値を含むことを特徴とする方法。
【請求項４】
ＩＰアドレスを利用する権限を提供する方法であって、
第１のノードにおいて請求項１記載の方法を実行し、インターフェース識別子と、対応する証明書とを有するＩＰアドレスを生成するステップと、
前記ＩＰアドレスと前記証明書とを第２のノードに送信するステップと、
前記第２のノードにおいて、前記証明書の内容を用いてインターフェース識別子を再構築し、再構築された前記インターフェース識別子を、送信された前記ＩＰアドレスと比較するステップと、
前記第２のノードにおいて、前記第１のノードの前記公開鍵を用いて前記証明書を検証するステップを含むことを特徴とする方法。
【請求項５】
ＩＰネットワークにおいて使用され、公開鍵と個人鍵の組を有するノードであって、該ノードは、
一方向符号化関数を用いて、前記公開鍵と個人鍵の組の公開鍵を有する複数のデータコンポーネントを対応付けることにより前記ノードで用いられるＩＰアドレスのインターフェース識別部を生成し、
前記公開鍵と個人鍵の組の中の個人鍵で署名された証明書を生成し、該証明書は、該インターフェース識別子と前記公開鍵を含み、前記証明書がホストの公開鍵を用いて認証され、また、該証明書の内容を用いて該インターフェース識別子を再構築することにより、該インターフェース識別子の所有権が検証されることを特徴とするノード。
【請求項６】
ＩＰネットワークを介し、第一ホストから、前記ＩＰネットワークに接続された第二ホストに対して送信される公開鍵を認証する方法であって、
前記第１ホストにおいて、前記公開鍵を用いてインターフェース識別子を生成し、該インターフェース識別子をルーティング接頭部と対応させ、第１ホストのためのＩＰアドレスを形成するステップと、
前記ＩＰネットワーク上の第１ノードから第２ノードに対して、前記公開鍵を送るステップと、
前記第２ノードにおいて、前記公開鍵が、前記インターフェース識別子を生成するために用いられた前記公開鍵であることを検証するステップを含むことを特徴とする方法。
【請求項７】
ＩＰネットワークに接続されたホストが、該ホストが所有することを請求するＩＰアドレスを利用できる権限を有することを前記ＩＰネットワークに接続されたノードが検証する方法であり、該ＩＰアドレスは、ルーティング接頭部とインターフェース識別部を有しており、該方法は、
該ホストから、ハッシュ値の系列に属するハッシュ値を有する一つあるいはそれ以上のデータコンポーネントを受信するステップと、
前記ハッシュ値に1回または複数回ハッシュ関数を適用することにより、前記ハッシュ値の系列の最後のハッシュ値を生成し、前記最後のハッシュ値を有する前記データコンポーネントに一方向性の符号化関数を適用するステップと、
該一方向性の符号化関数を適用した結果を前記ＩＰアドレスのインターフェース識別部と比較するステップとを含み、もし、該比較の結果が前記インターフェース識別部と一致した場合には、該ホストは、そのＩＰアドレスを利用する権限をもつものであると仮定され、一方、もし、該比較の結果が前記インターフェース識別部と一致しない場合には、該ホストは、そのＩＰアドレスを利用する権限を持たないものであると仮定されることを特徴とする方法。
【請求項８】
請求項７記載の方法において、前記データコンポーネントは、前記ホストに属する公開鍵あるいは公開鍵の要約を含むことを特徴とする方法。
【請求項９】
請求項７または８記載の方法において、前記データコンポーネントは、該ホストのリンク層アドレスに対応した初期のインターフェース識別子を含むことを特徴とする方法。
【請求項１０】
請求項７に記載の方法において、前記データコンポーネントは、受信したハッシュ値の前記系列中での位置を特定するカウンタ値を含むことを特徴とする方法。
【請求項１１】
請求項７記載の方法において、ホストにおいて種値と公開鍵あるいは公開鍵の要約に繰り返しハッシュ関数を適用することにより、前記ハッシュ値の系列を求めることを特徴とする方法。
【請求項１２】
請求項７記載の方法において、ホストにおいて種値と初期のインターフェース識別子に繰り返しハッシュ関数を適用することにより、前記ハッシュ値の系列を求めることを特徴とする方法。
【請求項１３】
請求項７記載の方法において、ホストにおいて種値と公開鍵あるいは公開鍵の要約、及び初期のインターフェース識別子に繰り返しハッシュ関数を適用することにより、前記ハッシュ値の系列を求めることを特徴とする方法。
【請求項１４】
請求項７記載の方法において、第一のＩＰアドレスの検証の際に、ホストから受信したハッシュ値は、系列中で最終のハッシュ値に先行したハッシュ値であり、以降の各検証処理では、次前のハッシュ値を受信する必要があることを特徴とする方法。
【請求項１５】
ＩＰネットワークに接続されたノードがＩＰアドレスを生成するように前記ノードを前記ＩＰネットワーク内で動作する方法であって、該ＩＰアドレスは、ルーティング接頭部およびインターフェース識別部を含み、該方法は、
少なくとも一つの乱数に逐次ハッシュ関数を適用することにより、ハッシュ値の系列を生成するステップと、
前記ハッシュ値の系列の最後のハッシュ値及び一つあるいはそれ以上の数のデータコンポーネントに対して、一方向性の符号化関数を適用することにより、該インターフェース識別部を生成するステップを含み、
該最後のハッシュ値に先行したハッシュ値は、ＩＰアドレスを生成するために以前に用いられたものではないことを特徴とする方法。
【請求項１６】
請求項１５記載の方法において、乱数と初期のインターフェース識別子の組み合わせに対し、ハッシュ関数を適用することにより、前記系列の最初のハッシュ値が生成されることを特徴とする方法。
【請求項１７】
請求項１５記載の方法において、乱数と公開鍵または公開鍵の要約に対し、ハッシュ関数を適用することにより、前記系列の最初のハッシュ値が生成されることを特徴とする方法。
【請求項１８】
請求項１５記載の方法において、乱数と初期のインターフェース識別子の組み合わせ、公開鍵または公開鍵の要約に対し、ハッシュ関数を適用することにより、前記系列の最初のハッシュ値が生成されることを特徴とする方法。
【請求項１９】
ＩＰネットワークに接続されたホストが、該ホストが所有することを請求しているＩＰアドレスを利用する権限をもつものであり、そのアドレスに対して送られたデータパケットを、該ホストが受信できることを、前記ＩＰネットワークに接続されたノードが検証する方法であって、
前記ノードにおいて請求項７記載の方法を実行し、前記ホストが該ＩＰアドレスを利用する権限をもつことを検証するステップと、
接続要求のための宛先アドレスとして前記ＩＰアドレスを用いて、該ホストへの接続要求を前記ノードから発行するステップと、
該ホストからの応答を前記ノードが受信するステップと、
受信した前記応答が、接続要求に対する正当な応答であることを検証するステップを含むことを特徴とする方法。
【請求項２０】
請求項１９記載の方法において、前記接続要求は、ランダムに生成された数であり、該応答は接続要求を含むことを特徴とする方法。
【請求項２１】
請求項１９記載の方法において、前記接続要求は、ランダムに生成された数と連結された前記ＩＰアドレスを含み、該応答は、該接続要求と連結された該ＩＰアドレスを含むことを特徴とする方法。
【請求項２２】
請求項１９記載の方法において、前記ノードにおいて、ランダムに生成された数を連結した前記ＩＰアドレスに対して、一方向性の符号化関数を適用することにより、前記接続要求を形成し、該接続要求と連結された該ＩＰアドレスに一方向性の符号化関数を適用することにより、該応答を形成することを特徴とする方法。
【請求項２３】
ＩＰネットワークにおいて使用されるホストが、該ホストが所有することを請求するＩＰアドレスを利用できる権限を有することを検証するノードであって、該ＩＰアドレスは、ルーティング接頭部とインターフェース識別部を有しており、該ノードは、
該ホストから、ハッシュ値の系列に属するハッシュ値を有する一つあるいはそれ以上のデータコンポーネントを受信し、
前記ハッシュ値に1回または複数回ハッシュ関数を適用することにより、前記ハッシュ値の系列の最後のハッシュ値を生成し、前記最後のハッシュ値を有する前記データコンポーネントに一方向性の符号化関数を適用し、
該一方向性の符号化関数を適用した結果を前記ＩＰアドレスのインターフェース識別部と比較し、もし、該比較の結果が前記インターフェース識別部と一致した場合には、該ホストは、そのＩＰアドレスを利用する権限をもつものであると仮定され、一方、もし、該比較の結果が前記インターフェース識別部と一致しない場合には、該ホストは、そのＩＰアドレスを利用する権限を持たないものであると仮定されることを特徴とするノード。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、インターネットプロトコル（ＩＰ）のアドレス機構に関し、特に、ＩＰｖ６のアドレス機構に関するものである。
【背景技術】
【０００２】
インターネットの利用が急速に高まってきたことにより、現状のインターネットプロトコルであるＩＰｖ４の弱点と限界が見えつつある。従って、インターネット技術特別調査委員会（ＩＥＴＦ）は、関連機関と緩やかな関係を保ちながら、ＩＰｖ６として知られる、拡張されたインターネットプロトコルを開発中である。特に、ＩＰｖ６は、より強化されたセキュリティー機構であるＩＰＳｅｃを組み込み、二つあるいはそれ以上の機関が、インターネットを介して安全に通信できるようにし、移動体でのインターネットアクセス（モバイルＩＰ）に対応できるものを目指している。モバイルＩＰによって、利用者は、一つのＩＰアクセスノードから他のノードへローミングしながら、移動中でもインターネットにアクセスすることができる。特に、モバイルＩＰは、（例えば、無線ＬＡＮと携帯電話ネットワークに接続された）無線移動機器を介してインターネットにアクセスする人たちによって用いられるものになる。
【０００３】
ＩＰｖ６は、１２８ビット長のＩＰアドレスを用いた、より広いＩＰアドレス空間を提供する。アドレスの前半の６４ビットは、ＩＰ端末あるいはホストによって用いられる（ローカルリンクと称される）インターネットアドレスノードを一意に識別するルーティング接頭部を形成し、一方、アドレスの後半の６４ビットは、アクセスノードにつながる（あるいはローカルリンク内の）移動端末を一意に識別するホスト接頭部を形成している。ホスト接頭部は、アクセスインターフェースを介して一意にホストを識別することから、“インターフェース識別子”と呼ばれる。通常、ホストがアクセスノードを登録した際には、アクセスノードから送られた同報メッセージによって、ホストはアクセスノードのルーティング接頭部を認識する。次に、ＲＦＣ３０４１（ＩＥＴＦ）に従い、ホストは、ホスト自身によって生成した乱数を用いて、そのインターフェース識別子を生成する。さらに、ホストは、リンク層アドレスを用いて、インターフェース識別子を生成するが、このリンク層アドレスは、例えば、アクセスネットワークによって用いられるＭＡＣ層アドレスである。
【０００４】
この方法が潜在的に抱える問題としては、同一のアクセスノードに接続された（必然的に同一のルーティング接頭部を持つ）２つのホストが、同一のインターフェース識別子を生成し、このために、同一のＩＰアドレスを生成してしまうというものがある。これは、許されるものではない。従って、ＩＰｖ６では、複製アドレス検出（ＤＡＤ）と呼ばれる機構が提供されている。一度、可能なＩＰアドレスをホストが生成すると、もしローカルリンクがローカルブロードキャストあるいはマルチキャストを行う場合には、ホストは、提案されたＩＰアドレスを含む、隣接ノードへの請求メッセージを、アクセスノードに対して送るか、あるいは、直接、ローカルリンクに送る。必要に応じて、アクセスノードは、このノードに接続した全ての他のホストに対して、同報メッセージを送る。もし、メッセージを受信したホストが、メッセージに含まれるＩＰアドレスを、すでに適用済みのアドレスであると認識した場合には、当該ホストは、請求元のホストに対して、隣接同報メッセージを送ることにより応答する。もし、請求元のホストが、所定の時間内に、隣接同報メッセージを受け取らない場合には、当該ホストは、生成されたアドレスを採用することになる。一方、もし、所定の時間内に、隣接同報メッセージが受信された場合には、請求元のホストは、新しいインターフェース識別子とＩＰアドレスを生成し、上記の請求処理を繰り返す。
前述の方法がもつ問題としては、多数の第三者にとって、隣接請求メッセージに対して、常に、隣接同報メッセージで応答することにより、請求元のノードを拒否することが比較的簡単にできてしまうということがあげられる。この種の攻撃は、“サービス拒否”攻撃と呼ばれる。
【０００５】
モバイルＩＰにＩＰｖ６を適用する際には、さらに他の問題がある。すでに説明したように、モバイルＩＰにより、ホストは、アクセスノードとアクセスネットワークの間でローミングが可能となるが、この特徴は、ホストの現在の物理的な位置を定義するＩＰアドレスを、ホスト自身が変更できるようにすることが必須となる。通常、移動ホストには、ホームネットワーク中での“固定”のホームＩＰアドレスが割当てられる。ホストがホームにある時には、ホストは、その物理アドレスとして、そのホームアドレスを用いることができる。しかし、ホストが、それ自身を“外部”アクセスノードに所属させる際には、そのホストには、一時的な気付アドレスが割当てられる。到着するパケットについては、対応するホストのモバイルＩＰ層は、気付アドレスと、宛先フィールド中のホームアドレスを交換し、一方、送出されるパケットについては、対応するホストのモバイルＩＰ層は、ホームアドレスと、宛先フィールド中の気付アドレスを交換する。モバイルホストが、新たな気付アドレスを取得した際には、全ての対応するホストに対し、それらの対応付け情報を更新するために、対応付けの更新メッセージを送る必要がある。
【０００６】
この機構がもつ潜在的なリスクとして、悪意をもつ第三者によって、偽造した対応付けの更新を対応するホストに送ることができてしまい、その結果、モバイルホストに向けられたデータパケットが、悪意をもつ者へ配送されてしまうというものがある。そして、もし悪意をもつ第三者により（その者によりパケットが開かれ読み出された後に）パケットがホストに転送されると、モバイルホストは、そのパケットが再配送され読まれたという事実を知ることさえ、不可能となる。この問題は、モバイルＩＰに限られたものではなく、ＩＰｖ６アーキテクチャ中の他の通信機能にも存在する問題である。このようなモバイルＩＰに関する問題および他の問題のいくつかについては、２００１年２月、ＩＥＴＦ提案“ｄｒａｆｔ−ｎｉｋａｎｄｅｒ−ｉｐｎｇ−ａｄｄｒｅｓｓ−ｏｗｎｅｒｓｈｉｐ−００．ｔｘｔ”に、より詳細に記載されている。
この問題についての解決策は、２００１年２月、ＩＥＴＦ提案“ｄｒａｆｔ−ｂｒａｄｎｅｒ−ｐｂｋ−ｆｒａｍｅ−００．ｔｘｔ”に提案されている。この解決策には、モバイルホストで、公開鍵と個人鍵からなる目的構築鍵（ＰＢＫ）の組を生成する処理が含まれている。エンドポイントＩＤは、ＩＰ接続を初期化した後、すぐに、接続関係にあるホストに送られる。続いて、モバイルホストは、接続関係にあるホストに、個人鍵を送り、接続関係にあるホストは、一方向性の符号化関数を鍵に適用し、以前受信したＥＩＤと比較することにより、公開鍵がこの接続に所属するものであることを確認することができる。続いて送られる対応付け更新は、モバイルホストで、ホストの個人鍵により署名される。接続関係にあるホストは、以前受信した公開鍵を用いた対応付け更新に付属した署名を確認する。
【発明の開示】
【発明が解決しようとする課題】
【０００７】
ＩＰｖ６に関して、これまで考察してきた２つの問題とは、すなわち、請求元ホストに近隣同報メッセージを送ることにより引き起こされるサービス攻撃が、拒否される可能性があるということと、対応付け更新の偽造による“中間位置にいる者”からの攻撃の可能性があるということである。同様の問題は、以下の状況でも生じる恐れがある。ＩＣＭＰルータ探索（ＲＦＣ２４６１、セクション６．１．２）、ＩＣＭＰリダイレクト（ＲＦＣ２４６１、セクション８．１）、共通トンネリング（ＲＦＣ２４７３）、ＩＰｓｅｃトンネリング（ＲＦＣ２４０１）、ルータ・リナンバリング（ＲＦＣ２８９４）、ＩＰｖ６ルーティング・ヘッダ（ＲＦＣ２４６０、セクション８．４）の状況、ならびに、条件によっては近接逆探査（ｄｒａｆｔ−ｉｅｔｆ−ｉｏｎ−ｉｐｖ６−ｉｎｄ−０５．ｔｘｔ）およびＳＣＴＰ（ＲＦＣ２９６０）の状況である。他の多くの提案と同様に、ＨＩＰ提案でも起こりうる可能性もある。これらの全ての問題は、ＩＰアドレスの所有者を検証できないという、共通の原因となる。
ブラッドナーの提案を考慮すると、ＰＢＫは、公開鍵をＩＰアドレスに対応付けるのではなく、ＥＩＤにのみ対応付けるものとなる。さらに、ＥＩＤとＩＰアドレスの間には、直接の対応付け関係はない。従って、ＰＢＫは、上記の問題を直接解決できるものではない。
本発明の目的は、上記の問題を解決することにある。特に、本発明の目的は、ＩＰアドレスの所有者を証明する手段を提供することである。本明細書では、ＩＰアドレスの所有権とは、アドレスの特定の範囲内で、ＩＰアドレスを用いる権限が所有者に与えられ、さらに、そのＩＰアドレスに適用されるルーティング情報を変更できる権限が所有者に与えられていることを意味している。
【課題を解決するための手段】
【０００８】
本発明の第一の特徴では、ＩＰネットワークに接続されたホストが、ホストが所有することを請求するＩＰアドレスを利用できる権限を有することを検証する方法が提供され、このＩＰアドレスは、ルーティング接頭部とインターフェース識別部を有しており、本方法は、ホストから一つあるいはそれ以上のコンポーネント（即ちデータコンポーネント）を受信するステップと、一方向性の符号化関数を、特定のあるいは各々のコンポーネント、もしくは、特定のあるいは各々のコンポーネントの派生物に適用するステップと、その結果あるいは結果の派生物をＩＰアドレスのインターフェース識別部と比較するステップとを含み、もし、その結果あるいは結果の派生物がインターフェース識別部と一致した場合には、ホストは、そのＩＰアドレスを利用する権限をもつものであると仮定され、一方、もし、その結果あるいは結果の派生物がインターフェース識別部と一致しない場合には、ホストは、そのＩＰアドレスを利用する権限をもたないものであると仮定される方法であることを特徴としている。
ホストは、コンポーネント、および／あるいは、コンポーネントの派生物を用いて、そのＩＰアドレスのインターフェース識別部を生成することができる。複数のコンポーネントが含まれる場合には、いくつかのコンポーネントと、他のコンポーネントの派生物との組み合わせに対し、一方向性の符号化関数を適用するものであってもよい。コネクションが継続している間、生成するホストは、これらのコンポーネントを保持し、必要に応じ、これらのコンポーネントを第三者に提供することができる。この第三者は、コンポーネントを利用して、インターフェース識別子を再構成し、ＩＰアドレスに関するホストの所有権を検証することができる。悪意のある第三者にとっては、逆符号化を行い、ＩＰアドレスからコンポーネントを復元することは困難であり、これにより、アドレスに関して真の所有権をもつかのようになりすますことは困難となる。
【０００９】
前記一方向性の符号化関数は、ＳＡＨ−１、ＭＤ５、あるいは他の既知の暗号化による一方向性の符号化関数であってよい。
本発明の実施例の利点は、公開鍵インフラ（ＰＫＩ）のように大掛かりなインフラを必要とせず、暗号化関数を新たな観点から適用することに基づくことにある。さらに、本発明の一部の実施例では、現在提案中のＩＰｖ６仕様に対して、アーキテクチャ上の変更を必要としないため、本発明は、先に考慮したブラッドナーの提案、すなわち、現在提案中のＩＰｖ６アーキテクチャに変更を必要とするものよりも有利なものとなる。
ＩＰネットワークは、インターネット、あるいは、企業のＬＡＮまたはＷＡＮなどの私設のＩＰネットワークを含むものであってよい。ＩＰネットワークは、インターネット、および／あるいは私設のＩＰネットワークに接続されたアクセスネットワークを含むものであってもよい。
好ましくは、前記コンポーネントは、前記ホストにより生成されたか第三者により前記ホストに対して発行された公開鍵、あるいは公開鍵の要約、あるいは、同一の長さをもつ固定（例えば、ゼロ）ビット系列、および、関連したハッシュ値の系列の一つであるハッシュ値を含んでいる。これに代わり、あるいはこれに加えて、前記コンポーネントは、ホストのリンク層アドレスに対応した、あるいはホストのリンク層アドレスから導出された初期インターフェース識別子、または、同一の長さをもつ固定（例えば、ゼロ）ビット系列を含んでいる。さらに好ましい構成としては、前記コンポーネントは、前記公開鍵あるいは公開鍵の前記要約、およびホストのリンク層アドレスに対応した、あるいはホストのリンク層アドレスから導出された初期インターフェース識別子、または、同一の長さをもつ固定（例えば、ゼロ）ビット系列を含んでいる。さらに好ましい構成としては、前記コンポーネントは、前記系列中の、受信したハッシュ値の位置を特定するカウンタ値を含んでいる。
【００１０】
好ましくは、前記ハッシュ値の系列は、ホストにおいて、種値、前記公開鍵あるいは公開鍵の前記要約、および初期インターフェース識別子に対して、一方向性の符号化関数を適用することにより求められる。これに代わり、前記ハッシュ値の系列は、ホストにおいて、前記種値、および前記公開鍵あるいは公開鍵の前記要約のいずれか、あるいは初期インターフェース識別子に対して、一方向性の符号化関数を適用することにより求められる。受信されたハッシュ値から求められ、前記値を生成するために用いられるハッシュ値は、系列中の最後の値である。最初のＩＰアドレス検証のタイミングで、ホストから受信されたハッシュ値は、系列中で、最後のハッシュ値よりも先にあるハッシュ値である。その後の各々の検証処理では、一つ前のハッシュ値を次々に受信する必要がある。
好ましくは、本方法は、ハッシュ系列の最後の値を求めるステップと、一つあるいはそれ以上の数の他のコンポーネントが連結された最後のハッシュ値に、一方向性の符号化関数を適用するステップとを含んでいる。その結果については、最後の結果とインターフェース識別子とを比較する前に、さらに処理が施されるものであってよい。
本発明の第二の特徴では、ホストにおいてＩＰアドレスを生成する方法が提供され、ＩＰアドレスは、ルーティング接頭部およびインターフェース識別部を含み、本方法は、一つあるいはそれ以上の数のコンポーネントに対して、一方向性の符号化関数を適用することにより、インターフェース識別部を生成するステップを含んでいる。
好ましくは、前記コンポーネントは、乱数からハッシュ値を用いるなんらかの方法によって生成される、ハッシュ値を含んでいる。より好ましくは、乱数の組み合わせと初期インターフェース識別子、または、前記公開鍵あるいは公開鍵の前記要約、または、前記初期インターフェース識別子と前記公開鍵あるいは公開鍵の前記要約との組み合わせの、いずれかの組み合わせに対して、一方向性の符号化関数を適用することにより、ハッシュ値が生成される。
【００１１】
本発明の第三の特徴では、新たなホストがネットワークに接続された際に、ＩＰネットワークでのＩＰアドレスの複製を防ぐ方法が提供され、本方法は、下記のステップを含んでいる。
一方向性の符号化関数を用いて、一つのコンポーネント、または複数のコンポーネント、および／または、一つのコンポーネントあるいは複数のコンポーネントの派生物を組み合わせることによって、新しいホストにおいて、インターフェース識別子を生成し、その結果、または、その結果の派生物を前記インターフェース識別子として用いるステップであって、前記インターフェース識別子は、前記ＩＰアドレスの一部を形成することを特徴とするステップと、
新しいホストから、アクセスネットワークにすでに接続されている他のホストに対して、近隣請求メッセージを送るステップと、
新しいホストで、他の各ホストから、前記ＩＰアドレスを所有することを請求する近隣同報メッセージを受信するステップであって、その近隣同報メッセージあるいは各々の近隣同報メッセージは前記コンポーネントあるいは複数のコンポーネントを含むことを特徴とするステップと、
受信した各々の近隣同報メッセージに対して、
前記符号化関数を用いて、コンポーネントあるいは複数のコンポーネント、および／または、コンポーネントあるいは複数のコンポーネントの派生物を組み合わせるステップと、
その結果、またはその結果の派生物を、ＩＰアドレスのインターフェース識別部と比較するステップであって、もしその結果あるいはその派生物がそのインターフェース識別部と一致する場合には、そこから近隣同報メッセージを受け取ったとされるホストを、ＩＰアドレスを用いる権限をもつものと仮定され、一方、もし、その結果あるいはその派生物がインターフェース識別部と一致しない場合には、そのホストは、そのＩＰアドレスを利用する権限をもたないものであると仮定されることを特徴とするステップ。
【００１２】
好ましくは、前記コンポーネントあるいは複数のコンポーネントは、公開鍵あるいは公開鍵の要約、またはそれらの派生物を含む。これにより、新たに加わったホストは、公開鍵を認識し、近隣同報メッセージを送信するこのホストが、そのＩＰアドレスを生成するためにこの公開鍵を利用したものであると確実に仮定することができ、これにより、新しく加わったホストは、そのＩＰアドレスを利用する権限を得るために、他のホストは、各々対応した個人鍵を所有しなければならないものであると仮定することができる。
好ましくは、上記の仮定のもとに、新たに加わったホストは、なんらかの既知の認証プロトコル、あるいは（ゼロ知識プロトコルなどの）他の公開鍵暗号化によるプロトコルを用いて、現状で、他のホストが必要とする個人鍵を所有していることを検証することができる。好ましくは、（検証）プロトコルが適切に動作していることにより、他のホストは、そのＩＰアドレスを利用する権限をもつものであると仮定することができ、前記プロトコルが適切に動作しない場合には、他のホストは、このＩＰアドレスを利用する権限がないものと仮定することができる。
本発明の第四の特徴では、ＩＰネットワークに接続されたホストが、そのホストが所有することを請求しているＩＰアドレスを利用する権限をもつものであり、そのホストが、そのアドレスに対して送られたデータパケットを受信できることを検証する方法が提供され、本方法は、以下のステップを含んでいる。
【００１３】
本発明の上記第一の特徴における方法を実行し、前記ホストがIPアドレスを利用する権限をもつことを検証するステップと、
接続要求のための宛先アドレスとして前記ＩＰアドレスを用いて、ホストへの接続要求を発行するステップと、
ホストからの応答を受信するステップと、
受信した応答が、接続要求に対する正当な応答であることを検証するステップ。
好ましくは、前記接続要求は、乱数を含んでいる。よリ好ましくは、前記接続要求は、乱数を連結した前記ＩＰアドレスを含んでいる。より好ましくは、前記応答は、前記乱数を連結した前記ＩＰアドレスに対して、一方向性の符号化関数を適用することにより、構成される。
【００１４】
本発明の第五の特徴では、ＩＰネットワークを介し、第一ホストから第二ホストに対して送信される公開鍵を認証する方法が提供され、本方法は、以下のステップを含んでいる。
前記第一ホストにおいて、前記公開鍵を用いてインターフェース識別子を生成し、このインターフェース識別子をルーティング接頭部と組み合わせて、第一ホストのためのＩＰアドレスを形成するステップと、
前記ＩＰネットワーク上の第一ノードから第二ノードに対して、前記公開鍵を送るステップと、
前記第二ノードにおいて、前記公開鍵が前記インターフェース識別子を生成するために用いられる鍵であることを検証するステップ。
本発明の第六の特徴では、ＩＰアドレスを公開鍵に対応付ける方法が提供され、ここでＩＰアドレスは、ルーティング接頭部とインターフェース識別部を含んでおり、本方法は以下のステップを含んでいる。
符号化関数を用いて、一つあるいはそれ以上の数のコンポーネント、および／あるいはそのコンポーネントの派生物を組み合わせることにより、前記インターフェース識別子を生成するステップと、
公開鍵と個人鍵の組の中の個人鍵で署名された証明書を生成するステップであって、この証明書は、インターフェース識別子と、前記コンポーネントまたは前記派生物あるいは他の派生物のいくつかを含み、ホストの公開鍵を用いて証明書が認証できるように、また、証明書の内容を用いて該インターフェース識別子を再構築し、その結果と真のインターフェース識別子とを比較することにより、インターフェース識別子の所有権が検証されるようになっていることを特徴とするステップ。
【００１５】
（実施例の詳細な説明）
図１は、インターネット通信手順を示すものであり、ここでは、複数の利用者端末あるいはホスト１から４が、インターネット５に接続されている。ホスト１から３は、アクセスネットワーク７のアクセスノード６を介して、インターネット５に接続されている。ホスト４は、図には示していないアクセスネットワークによって接続されている。
ホスト１の一つが、アクセスネットワーク７に新たに接続しようとするものであり、このホストに関して、アクセスネットワークは外部ネットワークである（よって、アクセスノード６は外部エージェントである）と仮定する。ホスト１は、外部エージェントからルータ同報メッセージを受信することにより、この仮定した状態を認識する。（このメッセージは、外部エージェントにより定期的に配信されるメッセージや、ホスト１から外部エージェントに対して送られるルータ請求メッセージに応じて、ホスト１に送信されるものであってよい）ホスト１は、ルータ同報メッセージによって、インターネット中で、この外部エージェントを一意に識別するルーティング接頭部を認識する。次に、ホスト１は、そのホームネットワーク９のホームエージェント８に対して、外部エージェント６を介して、対応付け更新メッセージを送り、ホームエージェントに対して、その新しい位置を伝える。ホームエージェントは、ホスト１に対して、外部エージェント６を介して対応付け認知メッセージを送ることにより、応答する。すでに上述したように、ホスト１は、ルーティング接頭部とインターフェース識別子を組み合わせて、ＩＰアドレスを形成している。
【００１６】
以下、インターフェース識別子を生成するための新しい方法について説明する。本方法は、以下の利点をもっている。
・リンク層アドレスへの、インターフェース識別子の対応付け
・公開鍵への、インターフェース識別子の対応付け
・複製アドレス検出の際に、サービス拒否攻撃を阻止する手段の提供
・遠隔から“アドレス所有権”を探索する手段の提供
【００１７】
インターフェース識別子の一般的な説明
ここで説明する方法は、暗号化の面で、強力な一方向性の符号化関数にもとづくものである。一方向性の符号化関数は、ＨＡＳＨ（．．．）と表すものとし、ここでは、特定の一方向性の符号化関数として、ＳＨＡ−１を用いることとする。（しかし、これに代わり、他のものを用いることも可能である）一般的な記法として、インターフェース識別子を生成する本方法は、以下のように定義される。
interface identifier : =HASH(component1 | component2 | component3)
ここで、“．．．｜．．．”は、連結を表し、コンポーネントの一つは、新たに生成された（“新”）乱数であり、他のコンポーネントは、インターフェース識別子を生成するノード（または、ホスト）が、インターフェース識別子を対応付けようとする情報である。
与えられたインターフェース識別子に関しては、そのインターフェース識別子の値にハッシングする複数のコンポーネントを計算により求めることは困難である。インターフェース識別子は、６４ビットの長さをもつため、この場合、その６３ビットが有用となり、この複数のコンポーネントを求めるためには、平均すると、２の６３乗の半分、すなわち２の６２乗の回数分の処理を必要とする。現在の処理装置によれば、このデータ長のハッシュ値を逆転することも可能ではあるが、実用上は、この処理には数百年を要するものとなる。ランダムなインターフェース識別子は、比較的短い寿命、多くの場合は日のオーダーの寿命をもつものと仮定できるため、この仮定は、リスクを生じる上では無視しうるものである。将来の計算機の処理能力の向上（１８ヶ月で倍増）を考慮しても、このリスクが顕在化するまでには、幾年もかかることになる。悪意をもつノードは、ＮＳパケットを受信するごとに、コンポーネントを計算するのではなく、あらかめじ計算しておいた値をキャッシュしておくことを選択するかもしれない。しかし、この処理に必要となる記憶領域は、禁止されているものである。
【００１８】
本方法のセキュリティは、インターフェース識別子の生成元以外の他者は、要求に応じて迅速、容易には、コンポーネントの値を提供できないという前提にもとづいている。もちろん、単一のコンポーネントのみを用いて、インターフェース識別子を生成することにより、ある程度のセキュリティーのレベルを得ることも可能である。しかし、複数のコンポーネントを用いることにより、後で述べるような、他の利点を得ることができる。
インターフェース識別子を生成する本方法により得られる利点を最大限活用するために、ネットワークに接続する全てのノードは、ある“合意”に従う必要がある。この合意は、多くの事項を取り決めるものになる。まず初めに、この合意は、インターフェース識別子を生成する方法を限定する。次の合意は、もし、ノードが、インターフェース識別子を生成するために用いられるコンポーネントを提供できるならば、そのノードは、これらのコンポーネントを提供できないノードに比べて、より確実にそのインターフェース識別子を“所有”できるものであると規定するものである。さらに、三番目の合意は、コンポーネントの構造的、意味的な条件を規定するものであり、すなわち、コンポーネントの一つは、乱数であり、他のコンポーネントは恣意的なものであることを規定するものである。
【００１９】
インターフェース識別子のリンク層アドレスへの対応付け
基本的なＩＥＴＦ文書（ＲＦＣ２３７３）に基づくと、リンク層アドレスを直接利用して、インターフェース識別子が生成される。この構成方法は、可逆であり、リンク層アドレスとインターフェース識別子が各々に対応し合ったものであることを確認することができる。すなわち、所定のインターフェース識別子に関して、誰もが、対応するリンク層アドレスを生成でき、その逆も可能となっているということである。これは、ローカルリンクの内部では、有用である。しかし、別のＩＥＴＦ文書（ＲＦＣ３０４１）に基づくと、リンク層アドレスがローカルリンクの外部に送出されて、ホストの秘匿性がリスクに晒されないように、このリンクは破壊されるものになっている。インターフェース識別子を生成するためにリンク層アドレスを用いるが、実際には、この情報は用いられることはない。すなわち、新しいインターフェース識別子を生成するために用いられる乱数は、外部に発行されることもなく、いかなる方法によっても利用されることはない。従って、所定のインターフェース識別子からリンク層を推察することや、まして、（リンク層アドレスによって識別された）あるノードが、所定のインターフェイスを実際に生成したことを知ることはできない。
【００２０】
ここで説明する方法は、リンク層アドレスとインターフェース識別子との間のリンクを、部分的に、再構成するものである。すでに説明したように、インターフェース識別子は、いくつかのコンポーネントから生成され、それらのコンポーネントの（少なくとも）一つは、生成するノードに対してのみ初期段階で既知のものとなっている。他のコンポーネントは、リンク層アドレスである。インターフェース識別子を所有することを請求しているノードは、インターフェース識別子を生成するために用いられたコンポーネントを公開した（必然的にそうした）時に、この公開されたコンポーネントを認識した他のノードは、自動的に、これらのコンポーネントの中から、リンク層アドレスを選び出すことになる。コンポーネントが、インターフェース識別子へのハッシングを実際に行ったことを確認することにより、インターフェース識別子の生成者が、所定のリンク層アドレスを用いようとしたことを確証することができる。
インターフェース識別子をリンク層アドレスに対応付けるためには、次式によって、インターフェース識別子を生成することが十分となる。
interface identifier : = HASH(random | link layer address)
ここで、“ｒａｎｄｏｍ”とは、新しい乱数であり、“ｌｉｎｋ  ｌａｙｅｒ  ａｄｄｒｅｓｓ”とは、生成元のノードが利用しようとするリンク層アドレスである。
【００２１】
インターフェース識別子の公開鍵への対応付け
従来から、ＩＰアドレスを公開鍵（あるいは、他のセキュリティ関係の情報）に対応付けられないことは、ＩＰｖ６に関するいくつかの通信機構のセキュリティに関する重大な問題であった。例えば、他のノードに、特定のアドレスに関して、ルーティング情報の変更を通知しようとするノードは、そのＩＰアドレスを“所有”することを示す必要がある。
このような認証に関する、３つの可能な解決策について検討した。一番目は、認証を局所的に構成することである。これは、単一の管理者のもとにある、小規模から中規模のネットワークでうまく動作する。二番目は、ＩＰアドレスの所有権の証明を提供するための、広域のインフラの一種を使う場合である。セキュア・リバースＤＮＳなどの、特定の目的のＰＫＩは、このサービスを提供するものである。しかし、実際に、このようなサービスを実現することは極めて困難である。三番目は、相互の合意に基づいて、認証を行うというものである。これは、いわゆるＡＡＡアプローチと呼ばれ、ＩＥＴＦのＡＡＡワーキンググループによって推奨されている。しかし、このようなシステムは、そのサービス範囲が広がるにつれて、漸近的にグローバルなインフラの形態に近いものとなり、数的な拡張性を確保し、信頼性を維持するという面で問題になる。すなわち、これらの３つの方法のいずれもが、拡張性の面で制限を受けることとなる。
【００２２】
ここで提案する四番目の方法は、暗号を用いて、ＩＰｖ６アドレスのＩＰｖ６インターフェース識別部は、暗号化のための重要情報をもつには十分な長さを持っているという事実を活用する。その基本的な考え方は、インターフェース識別子と公開鍵との間の暗号に関する重要なリンクを提供するインターフェース識別子を、コンポーネントベースで生成するということである。すなわち、インターフェース識別子を生成する際に用いられるコンポーネントの一つが、公開鍵（あるいは、公開鍵のハッシュ、すなわち、公開鍵の暗号化の要約あるいは“指紋”）である。リンク層アドレスの場合と同様に、コンポーネントを公開することにより、インターフェース識別子の生成者は、特定の公開鍵を利用したいことを請求することを、ノードが提供するものとなる。従って、インターフェース識別子と、それを生成する元になったコンポーネントのみが与えられると、インターフェース識別子の現状の利用者が、所定の暗号化鍵を実際に利用したい状態にあるということを、他のノードが確証することができる。逆の命題、すなわち、公開鍵の利用者が、所定のインターフェース識別子を利用したい状況にあるということは、その鍵によって、インターフェース識別子に署名することにより与えられる。これらの特徴を与えるために、インターフェース識別子は、以下により定義し、
interface identifier : = HASH (random | public key)
署名を以下のように行う、
certificate/signed message : ={interface identifier | public key} ｐｒｉｖａｔｅ  ｋｅｙ
【００２３】
ここで、“．．．｜．．．”は、連結を表し、“｛…｝Ｋ”は、鍵Ｋで署名されたメッセージを表し、“random”は、新しい乱数であり、public keyは、公開鍵あるいはその暗号化されたハッシュであり、“private key”は、対応する個人鍵である。より保証を加えるために、以下のように、署名されたメッセージの中に乱数を含めることができる。
certificate/signed message : ={interface identifier | random | public key} ｐｒｉｖａｔｅ  ｋｅｙ
【００２４】
完全なインターフェース識別子の生成手順
本発明とその応用をさらに説明する目的のために、以下、詳細に、実施方法を提案する。この提案では、インターフェース識別子を生成するために、リンク層アドレスと公開鍵を利用する。
ここでは、以下の演算子を利用する。
．．．｜．．．は、連結を表す。
｛…｝Ｋは、鍵Ｋで署名されたメッセージを表す。
［…］Ｋは、鍵Ｋで暗号化されたメッセージを表す。
【００２５】
１．  II０を、ホストのリンク層アドレスにもどつき、［ＲＦＣ２３７３］ＡｐｐｅｎｄｉｘＡで規定された通りに生成された、６４ビットの初期インターフェース値とする。もしこのような値がない場合には、II０を、６４ビットのゼロとする。
２．  オプションとして、認証された第三者から、鍵の組＜Ｋ＋，Ｋ−＞を生成もしくは取得する。ここで、Ｋ＋は、公開鍵であり、Ｋ−は、それに対応した個人鍵である。
３．  公開鍵の要約を計算により求め、＃Ｋ＋：＝ＨＡＳＨ（Ｋ＋）とする。もし公開鍵を用いない場合には、＃Ｋ＋は、同一の長さのゼロ値とする。
４．  初期乱数値ＨＮを生成し、ここで、Ｎは、次のステップで生成される系列の長さである。
５．  ハッシュ値の系列、ＨＮ，．．．，Ｈｉ，．．．，Ｈ０を生成する。ここでは、Ｈｉ−１：＝ＨＡＳＨ（Ｈｉ｜II０｜＃Ｋ＋）であり、Ｈ０が得られるまで、関数をＮ回適用する。
６．  ＲＦＣ３０４１準拠のインターフェース識別子生成アルゴリズムのためのＨの来歴の種値を、ハッシュ系列の最終値、すなわち、Ｈ：＝Ｈ０とする。
７．  ＲＦＣ３０４１のセクション３．２．１に規定された通りに、（小修正を施しながら）以下の処理を続ける。
・  連結Ｈ｜II０’を求める。ここで、Ｈは、ステップ６で生成した、来歴の種値であり、II０’は、６４ビットのゼロ値である。＊）注記あり
・  II’＝ＭＤ５（Ｈ｜II０’）を求める。
・  ＭＤ５要約のII’の最左側の６４ビットをとり、ビット６をゼロにする。この結果が、インターフェース識別子IIとなる。
・  もし、より多くの試みが必要になる場合には、（すなわち、認証の重複などの理由がある場合）ハッシュ系列の最終値を棄却して、これにより、Ｎを一つ繰り下げ、Ｎ：＝Ｎ−１とし、上記のステップ６以降を繰り返す。この手順は、ＭＤ５関数を単に一度だけ適用する［ＲＦＣ３０４１］とは異なる。
【００２６】
８．  もし、ステップ２で、オプションの公開鍵値が、生成されるか得られた場合には、インターフェース識別子を含む自己署名された証明書と、公開鍵の要約と、ハッシュ系列中の複数の値と、ハッシュ系列の最後の値と、ホストのリンク層アドレスを生成し、以下を求める。
ＣＥＲＴ：＝｛II，＃Ｋ＋，Ｎ，Ｈ０｝ Ｋ−
もし、公開鍵を用いない場合には、ＣＥＲＴを別に用いるところでは、常に、Ｎｕｌｌ値を用いる必要がある。
＊）II０’をII０とする代わりに、ゼロとする理由は、２つある。一つ目の理由は、II０は、ＨＮ，．．．，Ｈｉ，．．．，Ｈ０の系列の生成に含まれていて、これにより、ＲＦＣ３０４１で論じられているように、悪い乱数生成を引き起こす可能性を考慮しなければならないということである。さらに、Ｈｉで所有権を証明することは、またII０を必要とし、以下に論じるように、この所有権をリンク層アドレスに局所的にリンク付けてしまう可能性が残されている。二つ目の理由は、IIの計算からII０を切り離すことによって、遠隔ノードに対して、最初にＨを公開できるだけになることである。遠隔リンクを介して、II０を公開してしまうことは、ＲＦＣ３０４１の秘匿性を守るという目的を実質的に阻害することになり、望ましいことではない。
【００２７】
ここで説明した方法では、インターフェース識別子の所有権は、基本的には、生成されたハッシュ系列に基づくものであり、要求に応じて、ハッシュ系列から以前の値を取り出すことに依っている。この要求は、頻度が低い（攻撃が発生しない限り、実質的には存在しない）ため、多くのホストに対しては十分なように思われる。しかし、暗号化鍵に対して、インターフェース識別子を強力に対応付けるように、また、インターフェース識別子に対しても、その鍵を対応付けるように、この方法は設計されている。さらに、この方法は、インターフェース識別子の生成に対し、リンク層アドレスを強力に対応付けるものとなっている。この理由を、以下に記す。
ハッシュ系列ＨＮ，．．．，Ｈｉ，．．．，Ｈ０が構成される際には、各ステップにおいて、リンク層アドレスと公開鍵のハッシュの両方が用いられる。このことは、実際には、インターフェース識別子を用いる際には、ホストが、特定の公開鍵と特定のリンク層アドレスを利用したいという状況であることを示している。局所的には、これにより、ノードは、“間違った”リンク層アドレスのノードのインターフェース識別子を用いて他のノードから送られてくるパケットを無視できることになる。リンク層アドレスの変更が、特別の特権やハードウェア動作を必要とするような環境では、この状況は、セキュリティの向上に、なんらかの寄与を及ぼすものとなる。
公開鍵を含めることは、より意味のある効果をもたらす。このことは、特に、他のホストが、公開鍵を認識し、これらのホストが、持つべきインターフェース識別子の所有権を、確実に仮定できるようになることを意味している。すなわち、インターフェース識別子の生成処理の過程で、特定の公開鍵のハッシュを用いることにより、そのノードは、その特定のインターフェース識別子に、鍵を“所有”させようとしていることを強力に示すものとなる。これと逆の方向となる処理は、自己署名された証明書によって表され、基本的に、鍵の所有者が、インターフェース識別子を“所有”したいことを示すものとなる。これら２つのものは、ともに、インターフェース識別子と公開鍵の間の、暗号化について強力な双方向性の対応付けを生み出している。実際には、初期の段階で近接請求メッセージを用いて、ホストが、この情報を公開しようとして、請求された近接同報（メッセージ）の中にこの情報を言い換えることは、有用なものになると考えられる。この目的のために、近接請求（ＮＳ）メッセージおよび近接同報（ＮＡ）メッセージは、以下の情報を含むものであってよい。
【００２８】
−公開鍵、Ｋ＋自身
−自己署名された証明書、ＣＥＲＴ
−オプションとして、初期インターフェース識別子、II０
しかし、リンク層アドレスを検証する以外の目的に対しては、これは必要ではなく、インターフェース識別子の所有権が検証されないならば、この検証は、行われない可能性が高い。Ｋ＋とＣＥＲＴを含めることにより、受信するホストは、鍵Ｋ＋の所有者が、請求されたインターフェース識別子を利用したい状況にあることを検証できるものとなる。
本方法を用いて生成されたインターフェース識別子は、多くの利用先があり、それらの一部を詳細に説明する。
【００２９】
ＤＡＤの際のサービス拒否の防止
アドレスの再構成の間、新しく生成されたインターフェース識別子は、既に存在するインターフェース識別子との間で衝突を起こす可能性がある。この状況は、他のノードがすでに識別子を“所有”していることを表す、近接同報パケットを受信することにより示される。ＲＦＣ３０４１では、このような衝突を解消する方法として、ＭＤ５を用いて、次のインターフェース識別子を計算により求め、最大５回までこれを試みるという方法がある。残念なことに、この方法は、すべてのインターフェース識別子を所有することを単に要求しているような悪意をもつノードに対しては、適用できない。
【００３０】
ハッシュに基づくＤｏＳ防止
悪意をもつノードに対して、インターフェース識別子を“所有”しようと要求することを防止するために、以下のようにＤＡＤプロトコルを拡張することが提案されている。
ａ）全ての近接請求（ＮＳ）パケットは、以下の形式をもっている。
＜ＴＡ，Ｃ，Ｋ＋，ＣＥＲＴ＞
ここで、ＴＡは暫定的なアドレス、Ｃは乱数、Ｋ＋は応答するノードの公開鍵、およびＣＥＲＴは、上記のステップ８で生成された証明書である。（接続要求として用いられる）乱数と証明書は、厳密に言うと必要となるものではないが、オーバーヘッドもほどんどなく、セキュリティを少しばかり向上させる効果がある。
ｂ）ＮＡ取り消しメッセージは、ＤＡＤの一部として送られ、以下の形式をもつものである。
＜ＴＡ，ＴＬＬＡ，ｉ，Ｈｉ，＃Ｋ＋，Ｒ＞
ここで、ＴＡは、その所有権についてＮＡが要求しているアドレスであり、ＴＴＬＡは、ターゲットのリンク層アドレスであり、［ＲＦＣ２３７３］ＡｐｐｅｎｄｉｘＡで規定されるようにＴＴＬＡからII０が計算される、また、ｉは、使用されたハッシュ値のカウンタ値であり（最初のＮＡの衝突について、ｉは１と定義され）、Ｈｉは、ハッシュ系列中のｉ番目のハッシュであり、＃Ｋ＋は、公開鍵の要約（あるいは、公開鍵の暗号が用いられない場合には、１２８ビットのゼロ値）であり、Ｒは、ＭＤ５（Ｈｉ｜Ｃ）である。これらの値を発行することにより、応答ノードは、それがインターフェース識別子を“所有”するものであることを示すものとなる。さらに、応答ノードがインターフェース識別子を生成した際に、オプションの公開鍵の組が、応答ノードによって生成あるいは取得された場合には、このメッセージには、以下の形式をもつ、公開鍵と署名が含まれるものとなる。
＜ＴＡ，ＴＬＬＡ，ｉ，Ｈｉ，＃Ｋ＋，Ｒ，Ｋ＋，ＳＩＧＮ＞
【００３１】
ここで、Ｋ＋は、上記のステップ２で生成された公開鍵であり、ＳＩＧＮは、Ｋ−を用いて生成された、ＩＰヘッダを含む、パケット全体に対する署名である。
ＮＡを送出するホストが、インターフェース識別子を実際に所有することを検証するために、受信ホストは、以下の処理を実行する。
１．  ｉ回だけ、Ｈｉ−１：＝ＨＡＳＨ（Ｈｉ｜II０｜＃Ｋ＋）を計算し、Ｈ０を計算により求める。
２．  Ｈ＝Ｈ０とする。
３．  II’＝ＭＤ５（Ｈ｜II０’）を計算により求める。ここで、II０’は、６４ビットのゼロ値である。
４．  II’と、０ｘＤＦＦＦＦＦＦＦＦＦＦＦＦＦＦＦのビット毎のＡＮＤを計算し、II    とする。これにより、基本的に、II’のビット６がクリアされ、IIが得られる。
５．  ＴＡ＝０ｘｆｅ８０００００００００００００｜IIであることをチェックする。ここで、０ｘｆｅ８０００００００００００００は、ＩＰｖ６リンクローカルアドレスの接頭部である。
６．  Ｒ＝ＭＤ５（Ｈｉ｜Ｃ）であることをチェックする。
さらに、もし、ＮＡが、オプションの署名を含むならば、受信ホストで以下を計算する。
７．  ＃Ｋ＋＝ＨＡＳＨ（Ｋ＋）であることをチェックする。
８．  Ｋ＋を用いて、受信したパケットについて、ＳＩＧＮが、有効な署名であることをチェックする。
例えば、ｉ＝１の場合、ＮＡは、
＜ＴＡ，ＴＬＬＡ，１，Ｈ１，＃Ｋ＋，ＴＩＭＥ，Ｋ＋，ＳＩＧＮ＞
を含み、計算は下記のようになる。
【００３２】
１．Ｈ０：＝ＨＡＳＨ（Ｈ１｜II０｜＃Ｋ＋）
２．Ｈ：＝Ｈ０
３．II’：＝ＭＤ５（Ｈ｜６４ビットのゼロ）
４．II：＝II’と、０ｘＤＦＦＦＦＦＦＦＦＦＦＦＦＦＦＦのビット毎のＡＮＤ
５．ＴＡ＝０ｘｆｅ８０００００００００００００｜IIのチェック
６．Ｒ＝ＭＤ５（Ｈｉ｜Ｃ）のチェック
７．＃Ｋ＋＝ＨＡＳＨ（Ｋ＋）のチェック
８．ＳＩＧＮが、受信したパケットについて有効な署名であることのチェック
もし、全てのチェックに合格した場合には、請求元ノードは、請求者が実際にインターフェース識別子を所有し、それが新しいインターフェース識別子を生成することになることを仮定してもよいものとなる。
しかし、この状態では、再び攻撃が発生する可能性が残っている。新しいノードがインターフェース識別子を生成した際に、そのインターフェース識別子を所有することを請求する代わりに、攻撃側は、そのノードがインターフェース識別子を確立できるようにし、その時に限り、動作できるようにする。そのノードが、一度、インターフェース識別子に関する所有権を確立すると、攻撃側は、インターフェース識別子を要求するＮＳを送出する。このプロトコルによれば、正しい所有者は、これまで秘密とされた値Ｈ１を公開することにより、反撃しなければならず、これにより、攻撃側を最初にブロックする。しかし、次に、攻撃側は、Ｈ１を公開したＨＡを単純に再現することにより、再度、インターフェース識別子を所有することを要求する。正しい所有者は、ハッシュ系列中の以前の値Ｈｉを公開することにより、この繰り返し攻撃を防護する。このように、この問題を解決するものとして知られている唯一の方法は、Ｈｉの長さに依存して、２の（ｉ＊（（Ｈｉの長さ）−１））乗のオーダーの処理数に及ぶ、力ずくのやりかたである。さらに、２つ以上のＨｉの値を、局所的に公開することが必要となる場合でも、攻撃の試みを示す良い方法となる。
本方法は、図２のフローチャートで詳細に示されている。
【００３３】
ＰＫベースのＤｏＳの防止
繰り返し攻撃の問題を解決する他の方法としては、公開された、強力に対応付けられたコンポーネントの一つを利用するというものがある。すなわち、２つのノードが、同一の公開されたコンポーネントを提供することにより、所定のインターフェース識別子を“所有”することを要求している際には、一つのノードのみが、それらのコンポーネントの一つを“所有”しているということを示せるだけであり、特定のコンポーネントが、この衝突を解決するために用いられる。ここでは、解決に用いられるコンポーネントは、公開鍵である。従って、もし２者が、同一のコンポーネントを示すことにより、同一のインターフェース識別子を所有することを要求するならば（あるいは、それらのコンポーネントが、すでに公開済みであるならば）、請求者のうちの一方が、そのインターフェース識別子に対応付けられた公開鍵に対応した個人鍵を利用する能力があることを示すによって、この衝突は解決される。
公開鍵の暗号化の方法には、いくつかの種類がある。これには、ＲＳＡなどの従来の公開鍵暗号化、ＤＳＡなどの公開鍵署名アルゴリズム、およびゼロ知識プロトコルが含まれている。インターフェース識別子に関する所有権を証明する目的のために、これらの方法のいずれかを用いることができる。すなわち、暗号化された要約によって公開鍵を表現することが可能となり、請求者が実際に個人鍵にアクセスする証拠をタイムリーに提供できることが可能となるということだけが、求められている。このように、タイムリーに証拠を提供する通常の方法は、認証プロトコルを実行することである。
【００３４】
リンク層アドレスに基づくＤｏＳの防止
用いられるリンク層通信の特徴に依存して、リンク層アドレスを用いて、衝突を解消する（そして、繰り返し攻撃に対処する）ことも可能になり、これは、局所的に、インターフェース識別子の所有権を検証する唯一の手段としても用いられる。すなわち、もし、利用される通信媒体が、安全で確実なリンク層アドレスを持っているならば、すでに説明したように、リンク層アドレスをインターフェース識別子に対応づける能力が十分あるものとなり、これにより、正当なインターフェース識別子のみを用いることが確かなものとなる。
【００３５】
インターフェース識別子のルーティング可能なアドレスへの拡張
ここまでは、インターフェース識別子についてのみ説明してきた。しかし、［ＲＦＣ３０４１］に規定されているように、ランダムに生成されたインターフェース識別子は、局所的に一意であることが仮定されるのみである。すなわち、グローバルなインターネット環境では、互いに衝突し合うインターフェース識別子が生じる可能性があり、むしろ、おおむね発生すると言ってもよいものである。（“誕生日のパラドックス”によれば、２の（６３／２）乗あるいは３０億通りのインターフェースがある場合には、このような衝突が起こる可能性は、約５０％である）従って、衝突は、（拡張された）複製アドレス検出の手順での一意性を求めることにより、局所的なものには許すことができないが、これらの衝突は、非局所での場合に容認される必要がある。従って、非局所での場合には、インターフェース識別子によってのみ認証を行うことは賢明とはいえない。
【００３６】
接続要求／応答
パケットベースの通信の基本的な問題は、ソースアドレスを容易になりすますことができてしまうことにある。すなわち、グローバル浸入フィルタを用いない場合には、ソースアドレスが妥当性をもっていないところでパケットを簡単に送ることができるということである。基本的なセキュリティのレベルは、パケットで指定されたソースアドレスへの逆接続要求を送り、応答を待つことにより達成される。パケットの送り元は、そのアドレスに送られたパケットを受信できる場合にのみ、適切に応答することができる。この方法は、よく知られた方法であり、例えば、いくつかのプロトコルにおける、いわゆるクッキー機構で用いられている。
インターフェース識別子の所有権を証明するための、基本的な、ハッシングのみに基づく方法は、単純なコンポーネントの開示による接続要求／応答手法と、より複雑なコンポーネントの開示の繰り返し手法とを組み合わせている。（これらの手法の両者ともに、上記で説明済みである）さらに、この組み合わせは、所有権を検証するものは大量の計算を必要としないように行うものとなっている。少ない処理量であるため、計算機資源を極端に消費するサービス拒否攻撃を起こすことを防止できる。
【００３７】
この基本的な考え方は、要求元が、まず、インターフェース識別子を含んだチェックされるべきアドレスと、インターフェース識別子がつくられる元になるコンポーネントを送る。これは、プロトコル中の最初のメッセージとなる。検証機能は、コンポーネントをチェックし、要求元も、インターフェース識別子自身を生成したことを確認するか、それが起源となるノードからの物であることを確証する。しかし、このプロトコルは、たいていの場合、この最初の組のコンポーネントを認識した多くのノードが存在するものの、後に使われる、その次の組のコンポーネントを認識するノードの数は、かなり少なくなるように設計されている。
検証機能が、インターフェース識別子とコンポーネントをチェックすると、それは、検証されるアドレスに接続要求を送る。原則的に、この接続要求は、単純な乱数である。しかし、ここでは、この乱数は、検証されるべきインターフェース識別子とコンポーネントと組み合わされ、これにより、同一の乱数を繰り返し使用することが可能となる。この接続要求は、プロトコル中の第二のメッセージとなる。要求元が、この接続要求を受け取ると、それは応答を生成する。この応答は、プロトコルの第三と最終のメッセージを形成する。応答を生成する際には、２つの可能なオプションが存在する。
ａ）請求者は、インターフェース識別子と、それが、第一のメッセージ中にすでに開示したものと同一の組のコンポーネントを使用し、
interface identifier : = HASH (components)
これらのインターフェース識別子とコンポーネントを送る。（なぜなら、これらは、検証機能によっては、保持されていないためである）
ｂ）応答を生成する際には、請求者は、インターフェース識別子と、以前のコンポーネントの組、すなわち、第一のメッセージ中にすでに開示したコンポーネントを生成するときにしようしたコンポーネントの組を使用し、
interface identifier  : = HASH (components1)
components1           : = HASH (components2)
インターフェース識別子とコンポーネント２（ｃｏｍｐｏｎｅｎｔｓ２）を送る。
【００３８】
これらの手法は、両方とも、各々の利点と欠点を持っている。手法ａ）の主な利点は、コンポーネントの第二の組は、公開する必要がなく、その結果、後で利用するために、これらを“保存”しておくことができることである。しかし、その欠点は、コンポーネントの第一の組を知っている者であれば、その応答が生成できてしまうところにある。それに対し、手法ｂ）では、コンポーネントの第二の組を用いることにより、そのコンポーネントの組を公開情報とできる。従って、それらが一度でも利用された後には、コンポーネントの第一の組を認識することができた任意のホストは、コンポーネントの第二の組を認識した可能性が高くなるということになる。従って、セキュリティの面ではほとんど強化されていないことになる。
ここでは、第一の手法ａ）が好ましく、同一の組のコンポーネントを、第一と最後のメッセージで用いる。この方法は、以下を保証するものである。
−請求者は、検証すべきアドレスに送られたメッセージを、受け取ることができる。この特徴は、単純な接続要求／応答のプロトコルによって実現できる。
−請求者は、インターフェース識別子が生成する元になったコンポーネントの組を、それ自身で生成しているか、それらのコンポーネントをなんらかの方法で認識している。このように、（基本的な要求接続と応答に比べて）セキュリティのレベルを向上させるためには、コンポーネントを知る（あるいは認識する）必要がある。不幸にも、コンポーネントを認識することは、それほど困難なことではない。幸運なことは、ここで説明したプロトコルでは、コンポーネントは、保護の第一層としてのみ働き、実際の所有権は、公開鍵の暗号化のみによって証明されるということである。
【００３９】
攻撃する者は、少なくとも３つの異なる方法で、コンポーネントを認識する。攻撃する者は、コンポーネントを生成したノードと同一のローカルリンク上にあるものであるため、あるいは、攻撃する者は、コンポーネントを生成したノードと他の遠隔ノードとの間のトラフィックを盗聴することができるため、あるいは、攻撃する者は、このプロトコルを実行することにより起源となるノードからコンポーネントを認識したものであるため、攻撃する者はコンポーネントを認識することができる。
もし、攻撃する者が、コンポーネントを生成したノードと同一のローカルリンク上にあるものであるために、コンポーネントを認識できた場合には、インターフェース識別子を利用することは困難であるということが分かる。その場合、コンポーネントの起源となる生成元が、インターフェース識別子の所有者となっていると考えられる。もし、起源ノードが、他のローカルリンクに移動したり、あるいは、攻撃する者が、他のローカルリンクに移動した場合には、この状況は、盗聴または検証プロトコルを実行することによって、攻撃する者が、コンポーネントを認識した場合と同様となる。
他の場合では、攻撃する者と、コンポーネントの実際の生成元は、異なるリンク上に存在する。従って、これらは、異なるルーティング接頭部を持つものとなる。ここでは、起源ノードと攻撃する者は、異なるルーティング可能アドレスを持つため、起源ノードと同一のインターフェース識別子を用いる攻撃する者は、攻撃する者として扱うことはできない。本セクションで説明したように、攻撃する者は、基本的な接続要求／応答プロトコルを実行するが、その実行によって、攻撃する者を助けるようなことにはならず、また助けてはならない。
本方法は、図３のフローチャートで詳細に示されている。
【００４０】
接続要求／応答と公開鍵に基づく認証の組み合わせ
ローカルの場合に重要な問題になるのは、インターフェース識別子の一意性である。既に述べたように、グローバルの場合には、インターフェース識別子は、一意である必要はなく、一般的に一意とはなっていない。従って、その一意性の保証や証明を試みる意味はない。同様に、リンク層アドレスも、グローバルの場合には、関係のないものとなる。それに代えて、公開鍵とインターフェース識別子とを互いに強力に対応付けることができることが極めて重要となる。しかし、署名の生成や署名の検証といった、公開鍵の処理は、計算機処理上では高価なものであるため、ここでは、一方向性の符号化関数を最初に用いて、攻撃を困難にするための“前線バリア”とし、その後で、公開鍵機能を用いることが、好ましい方法となる。公開鍵を直接利用することは、計算機資源を極端に消費するサービス拒否攻撃を引き起こす可能性をもっている。
公開鍵に基づく方法では、先ず始めに、請求者が、検証すべきアドレスと、インターフェース識別子と、インターフェース識別子を生成する元となるコンポーネントを含むパケットを送る。しかし、検証機能は、状態を生成したり、そうでない場合には、この第一のメッセージをかつて受信したことを記憶していることは求められていないため、これらのコンポーネントは、請求者の公開鍵に関するなんらかの情報を含むものではない。検証機能は、以前と同じように、接続要求を生成する。しかし、接続要求に加え、請求者に対して、追加情報として、その公開鍵も送る。この場合、公開鍵は、自己署名証明書として送付するのが最良となる。検証機能は、この証明書をすでに入手していて、それを送ることは、メッセージに追加することのみを要求するようになっていることが望ましい。
次のステップは、要求されるものに依って、いくつかのオプションを含んでいる。もし、検証機能が、その公開鍵を提供していた場合には、請求者はそれを使うことができる。いずれの場合でも、請求者は、それ自身の個人鍵を用いて、接続要求に対応する必要があり、効率的に多層の応答を生成することができる。すなわち、請求者は、接続要求を受信しそれに応答することが実際に可能であることを示す。攻撃する者は、虚偽の応答メッセージを送り、検証機能にとって、メッセージの処理には多大な計算機資源を消費するものとなるため、検証機能にとっては、これを検証することが処理の面から“安価”である必要がある。
【００４１】
次に、さらに高度なセキュリティレベルが、公開鍵を用いて形成される。ここでは、検証機能は、インターフェース識別子と公開鍵の間の対応付けが、実際に存在することをチェックできることが、まず必要となる。しかし、公開鍵に関する情報が検証機能に届けられると、それを用いる方法についてはいくつかの標準的なオプションが存在する。
以上を要約すると、本方法は、以下のセキュリティ保護の“層”を持っていることになる。
０．１  検証機能は、請求者が、インターフェース識別子に対応したコンポーネントの組を認識していることを、極めて安価に、接続要求を送る前でさえ、検証することができる。
０．２  検証機能は、状態に関する情報を格納する必要がなく、安価に、接続要求を構築することができる。
１．１  検証機能は、請求者が接続要求を受信できたことを、安価に検証することができる。
１．２  検証機能は、第一のメッセージで用いられた同一の組のコンポーネントをまだ知っていることを、安価に検証することができる。
２．１  検証機能は、請求者によって与えられた公開鍵が、実際に、インターフェース識別子を生成する際に用いられた複数のコンポーネントの一つであることを、安価に検証することができる。
２．２  検証機能は、請求者が公開鍵に対応した個人鍵を所有していることを、（費用をかけて）検証することができる。
【００４２】
プロトコルの詳細な説明
アリスとボブの間での機構を説明する。ここでは、ボブがアリスに対して、ボブがＩＰアドレスＴＡを“所有”していることを証明しようとしている。以下の、３メッセージプロトコルを用いる。さらに、ボブが、どのようにアドレスを生成するかを特定するために、０−ステップが必要となる。
０．上記で概説した方法を用い、ボブは新しいＩＰアドレスＴＡを生成する。
１．  ボブは、ボブがアドレスＴＡを所有していることをアリスに証明しようとする。これを行うために、ボブは、以下を含むメッセージをアリスに送る。
ＭＳＧ１＝＜ＴＡ，Ｈ０，＃Ｋ＋，Ｎ＞
ここで、
・ＴＡは、ルーティング接頭部ＲＰとインターフェース識別子IIから成り立ち、その所有権をボブが証明しようとしているＩＰアドレスであり、
・Ｈ０は、IIを生成する際に、Ｈ０であり、
・＃Ｋ＋は、Ｈ０を生成する際に、ボブが用いた公開鍵のハッシュ値であり、
・Ｎは、ボブがアリスから受信することを期待している返信を特定するために、ボブが用いる（一回限りの）乱数である。Ｎは、任意の数でよいため、もしボブが乱数を用いたくなければ、ボブは任意の数、例えば、ゼロを指定してもよい。
【００４３】
２．  アリスはパケットを受信し、接続要求を送る。
２．１  アリスは、以下をチェックする。
interface_identifier(TA)=MD5(H０|64-bit zero) bitwiseand 0xDFFFFFFFFFFFFFFF.
これは、ボブが、Ｈ０の正しい値を知っていることを証明することである。これが可能なのは、ボブは、それを彼自身が作り出していたから、または、盗聴によってや、前もってこれと同一のプロトコルを実行することによって、それを知りえていたことのいずれかの理由があるためである。これは、インターフェース識別子の所有権の証明する上での弱さとして、すでに説明したとおりである。
２．２  アリスは、以下の接続要求を生成する。
Ｃ：＝ＭＤ５（Ｐ｜Ｈ０｜＃Ｋ＋｜Ｎ｜ＴＡ）
ここで、Ｐは、（一回限りの）乱数である。この単一の乱数は、幾度かの接続要求のために用いられるため、アリスが、状態を作り出す必要はない。
２．３  アリスは、アドレスＴＡにパケットを送る。そのパケットは、接続要求Ｃを含んでいる。ここでは、ボブはＴＡを介して到達可能であることをチェックするために、このメッセージはアドレスＴＡに送られることに注目したい。オプションとして、パケットは、アリスが自己署名した証明書、ＣＥＲＴＡ＝｛IIＡ，＃ＫＡ＋，ＮＡ，ＨＡ，０｝ＫＡ−を含むものであってもよい。
ＭＳＧ２＝＜Ｎ，Ｃ＞  または  ＭＳＧ２＝＜Ｎ，Ｃ，ＫＡ＋，ＣＥＲＴＡ＞
【００４４】
３．  ボブは、接続要求を受信し、応答を返す。
３．１  オプションとして、ボブは、Ｎをチェックして、接続要求が、彼の初期パケットに対応して実際に送られたものかどうかを確認する。
３．２  ボブは応答を計算する
Ｒ：＝ＭＤ５（Ｃ｜ＴＡ｜Ｈ０｜＃Ｋ＋｜Ｎ）
３．３  オプションとして、ボブは、アリスの公開鍵ＫＡ＋を取り出し、ＣＥＲＴＡをチェックする。
最初に、ボブが以下を検証する。
・アリスがＭＳＧ２を送信する際に、ＩＰヘッダ中のソースＩＰアドレスとしてアリスが用いた、インターフェース識別子に対して、IIＡが一致すること
・IIＡが、ＭＤ５（Ｈ０｜６４ビットのゼロ）と０ｘＤＦＦＦＦＦＦＦＦＦＦＦＦＦＦＦとのビット毎の論理積と等しいこと
・＃ＫＡ＋が、ＨＡＳＨ（ＫＡ＋）と等しいこと
・ＣＥＲＴＡが、＃ＫＡ＋を含むこと
・ＣＥＲＴＡが、有効に署名されたこと
もし、この検証の結果、正しくないことが判明した場合には、ボブは、オプション部のＫＡ＋とＣＥＲＴＡは、まったく受信しなかったかのようにして、処理を続ける。
【００４５】
３．４  もし、ボブが、アリスの公開鍵を受信し、ステップ３．３の検証の結果が正しいものであった場合には、ボブは、ボブとアリスとの間で共有すべき秘密鍵を準備する。
・秘密の対称な鍵ＫＡＢを生成し、アリスとボブの間で共有するものとする
・アリスの公開鍵を用いて、新しく生成された鍵ＫＡＢと、ボブがＨ０を生成する際に用いたII０と、ボブがＨ０を生成する際に用いたＨ１とを含むメッセージを暗号化する。これは、秘密の部分Ｓであり、アリスだけが開くことができるものとなる。
Ｓ：＝［II０，ＫＡＢ，Ｈ１］ＫＡ＋
もし、Ｓが生成されない場合には、空のストリングで代用する。
３．５  ボブは、応答Ｒを含むパケットを、アリスに送る。さらに、このメッセージは、ＭＳＧ１が含むのと同一のＴＡ、Ｈ０、＃Ｋ＋およびＮを含まなければならない。
ＭＳＧ３＝＜ＴＡ，Ｈ０，＃Ｋ＋，Ｎ，Ｒ，Ｓ＞
オプションとして、メッセージは、ボブの個人鍵Ｋ＋と、ボブの証明書ＣＥＲＴと署名ＳＩＧＮも含んでよい。
ＭＳＧ３＝＜ＴＡ，Ｈ０，＃Ｋ＋，Ｎ，Ｒ，Ｓ，Ｋ＋，ＣＥＲＴ，ＳＩＧＮ＞
署名ＳＩＧＮは、メッセージの残りの部分に対する署名であり、ボブの個人鍵Ｋ−を用いて生成される。
【００４６】
４．  アリスは、応答を受信し、それをチェックする。
４．１  アリスは、いかなる状態も保持していないため、アリスは、まず、インターフェース識別子がＨ０に関して有効であることを、再度チェックする。
interface_identifier(TA)=MD5(H０|64-bit zero) bitwiseand 0xDFFFFFFFFFFFFFFF.
もし、これが成立しない場合には、アリスは、このパケットを単に棄却する。
４．２  Ｐを知って、アリスは、受信したメッセージからの情報を用いて、Ｃを再計算し、
Ｃ’：＝ＭＤ５（Ｐ｜Ｈ０｜＃Ｋ＋｜Ｎ｜ＴＡ）
応答Ｒが期待通りの値を持っていることをチェックする。
Ｒ＝ＭＤ５（Ｃ’｜ＴＡ｜Ｈ０｜＃Ｋ＋｜Ｎ）
【００４７】
もし、この検証結果、正しくないことが判明した場合には、アリスは、ボブの請求は無効であると仮定する。一方、有効な請求であることは、ボブがＴＡに送られたパケットを受信できることを証明することになる。
４．３  もし、メッセージが、オプション部、すなわち、ボブの公開鍵Ｋ＋、ボブの証明書ＣＥＲＴ、および対応する署名ＳＩＧＮを含んでいる場合には、アリスは、以下をチェックする。
・ＣＥＲＴの中のIIが、ＴＡのインターフェース識別子と一致すること
・＃Ｋ＋が、ＨＡＳＨ（Ｋ＋）と等しいこと
・ＣＥＲＴが、＃Ｋ＋を含むこと
・ＣＥＲＴが、有効に署名されたこと
・署名ＳＩＧＮが有効であること
これは、鍵Ｋ＋の所有者が、アドレスＴＡを使いたい状況にあること、また、ボブがＫ−を知っていることから鍵Ｋ＋をボブが所有していることを、証明するものである。
４．４  もしメッセージが秘密の部分Ｓを含んでいる場合には、アリスは、アリスの個人鍵ＫＡ−を用いてＳを暗号解読し、IIＡと、ＫＡＢとＨ１を取り出す。
アリスは、以下をチェックする。
II＝ＭＤ５（ＨＡＳＨ（Ｈ１｜II０｜＃Ｋ＋））
これにより、IIの生成元が、その要約が＃Ｋ＋である公開鍵を利用したい状況にあり、II０と一致するリンク層アドレスを持つ状況にあることが証明される。これにより、IIからＫ＋までと、Ｋ＋からIIに戻るループが閉じる。II０が解読により得られるという事実は、メッセージが暗号化されているため、通常は問題にはならない。
【００４８】
もし、オプションのステップ４．３を含む、全てのプロトコルが検証が成功すると、ボブは現状でＴＡに到達可能であり、Ｋ＋はボブがＴＡを生成するのに用いた公開鍵であるということを、アリスは知ることとなる。さらに、アリスは、ボブのリンク層アドレスはII０であることを知るが、アリスは、その情報については関知しない。
以上を要約すると、ここで提示した手法の利点は下記のようになる。
−［ＲＦＣ２３７３］で規定されるが［ＲＦＣ３０４１］では破棄されるような、リンク層アドレスとインターフェース識別子との間の強力な対応付けが、部分的に再構築され、［ＲＦＣ３０４１］のプライバシー保護の目的に適うものになる。
−新しい対応付けは、インターフェース識別子から公開鍵に対して、生成される。
−ＩＰｖ６の自動構成［ＲＦＣ２４６２］の間に、サービス拒否攻撃を阻止する手段が、複製アドレス検出（ＤＡＤ）手順に付け加えられる。
−局所的なルーティング情報を修正する目的のためにインターフェース識別子を“探索”する手段が、例えば、ＩＰｖ６対応付け更新など、必要に応じて提供される。
本手法の主要な特徴を以下に示す。
−一方向性の関数をコンポーネントに適用し、ＩＰｖ６アドレスのインターフェース識別部を形成し、コンポーネントの少なくとも一つを最初に秘密とすることにより、後にこれらのコンポーネントを公開して、インターフェース識別子の所有権の証明に活用することができる。
−一方向性の関数を、コンポーネントに複数回適用することにより、攻撃する者が以前公開されたコンポーネントを利用した攻撃を行うものに対する、セキュリティの保護を提供することが提案されている。
−一方向性の関数をコンポーネントに適用し、ＩＰｖ６アドレスのインターフェース識別部を形成し、これらのコンポーネントに、意味的な情報を付与し、これらのコンポーネントを公開することにより、インターフェース識別子を、インターフェース識別子の利用者のために意味的に重要なコンポーネントの値を表す暗号化トークンとして動作させることができる。
【００４９】
−特に、リンク層アドレスは、意味的に重要なコンポーネントとして用いられるものの一つである。リンク層アドレスを含ませることのセキュリティ上の意義は、ローカルリンクの物理的な実装に依存するものとなる。
−特に、公開鍵、または公開鍵のメッセージ要約は、意味的に重要なコンポーネントとして用いられるものの一つである。潜在的に、公開鍵、または公開鍵のメッセージ要約は、鍵とＩＰｖ６アドレスが、ＰＫＩやＡＡＡインフラのような外部のインフラを必要とせずに、リンクできるようにするものであるため、これは極めて大きなセキュリティ上の重要性を持つものである。
−公開鍵をインターフェース識別子に対応付ける能力を用いて到達性をチェックする既知の接続要求・応答方法を組み合わせることにより、インターネット上で、特定のインターフェース識別子を制御しようと請求する者が、実際に、高い確率で、その制御が可能となっていることをチェックすることが可能となる。
−コンポーネントからインターフェース識別子を繰り返し生成することを組み合わせることにより、検証機能が、計算機資源を極端に消費するサービス拒否に対する、なんらかの保護を有するように、インターフェース識別子の所有権のチェックを行うことが可能となる。このＤｏＳ保護は、検証機能に費用をかけて公開鍵の計算をさせる、ノードの数を制限することにより実現される。
上記の実施例については、本発明の範囲を逸脱することなく、様々な変形が可能となっている。
【図面の簡単な説明】
【００５０】
【図１】インターネットに接続された複数のホストを含むネットワークの概要図である。
【図２】図１に示したネットワーク中での、複製アドレス検出処理のフローチャートである。
【図３】図１に示したネットワーク中での、対応付け更新処理を実行する方法のフローチャートである。
【図１】
2008271601.tif 000003
【図２】
2008271601.tif 000004
【図３】
2008271601.tif 000005