ネットワークワーキンググループ Request for Comments: 1825 分類: スタンダードトラック R. Atkinson Naval Research Laboratory 1995年8月 インターネット・プロトコルのためのセキュリティ・アーキテクチャ (Security Architecture for the Internet Protocol) このメモの位置付け この文書は、インターネット・コミュニティに対してインターネット・ス タンダードトラックのプロトコルを規定するとともに、それを改良するた めの議論や提言を求めるものである。 このプロトコルの標準化状態、およびステータスについては、"Internet Official Protocol Standards" (STD 1) の最新版を参照すること。 このメモの配布に制限はない。 1. はじめに このメモでは、IP バージョン 4 (IPv4) と IP バージョン 6 (IPv6) の ためのセキュリティの仕組みと、それらが提供するサービスについて記述 する。 それぞれのセキュリティの仕組みについては、別の文書にて定義される。 この文書ではまた、これらのセキュリティの仕組みを実装するシステムに おける鍵管理の要求事項についても記述する。 この文書は、インターネットのためのセキュリティ・アーキテクチャの全 体についてではなく、IP 層におけるセキュリティに閉じた内容になって いる。 1.1 技術的な定義 この章では、この文書で使用されるいくつかの基本的事項について定義す る。 この他の定義やその背景については、別の文書にて記述される [VK83, HA94]。 認証 受信されたデータが送信されたデータと同一のものであることを確 認できること。 また、送信者を主張する者が本物の送信者であることを確認するこ とができること。 インテグリティ データが送信元から宛先まで、知らないうちに変更されていないこ とが保証されること。 機密性 目的の受信者は、送信された内容を知ることができるが、意図しな い組織には、送信された内容を特定することができないように通信 すること。 暗号化 機密性を提供するために一般的に使用される仕組み。 否認防止 データの送信者が、以前にそのデータを送信したことを後になって 否定しようとする可能性があるが、その送信者が実際にそのデータ を送信したということを受信者が証明することができること。 SPI 「セキュリティ・パラメータ・インデックス」の略語。 ある特定のセキュリティ・アソシエーションを識別するために、宛 先アドレスと組み合わせて使用される、構造化されていない不透明 な指標。 セキュリティ・アソシエーション 与えられたネットワーク・コネクションやコネクションの集合に関 連付けられるセキュリティ情報の集合。 これについては、後で詳細に記述する。 トラフィック解析 敵にとって有用な情報を推測する目的で、ネットワークのトラフィ ック・フローを解析すること。 このような情報の例として、伝送の頻度、通信中の組織の身元、パ ケット長、使用されるフロー識別子などがある [Sch94] 。 1.2 要求事項に関する用語 この文書では、ある特別な要求事項の重要性を明確にするために使用する 単語を、通常、大文字で表記する。 これらの単語は以下の通りである。 - しなければならない (MUST) この単語、あるいは「要求される (REQUIRED) 」という形容詞は、この項 目が仕様の絶対的な要求事項であることを意味する。 - する必要がある (SHOULD) この単語、あるいは「推奨される (RECOMMENDED) 」という形容詞は、あ る特定の状況では、この項目を無視できるような有効な理由が存在する可 能性があることを意味する。 しかし、そこに含まれている意味はすべて理解される必要があり、別の方 法を取る前に、その状況を慎重に考えるべきである。 - しても良い (MAY) この単語、あるいは「選択できる (OPTIONAL) 」という形容詞は、この項 目が実に選択的であることを意味する。 あるベンダは、特定の市場がそれを必要とするか、または製品の質を高め るために、この項目を取り入れようとするかもしれない。 例えば、別のベンダは同じ項目を省略するかもしれない。 1.3 典型的な利用法 IPv4 と IPv6 においてセキュリティ・サービスを提供するために、2 種 類のヘッダが使用される。 それは、「IP 認証ヘッダ (AH) 」[Atk95a] と「IP 暗号ペイロード (ESP) 」[Atk95b] ヘッダである。 これらの IP セキュリティの仕組みには様々な利用法が考えられる。 この章では、この中でもより利用されそうな方法についていくつか記述す る。 ここで記述されたものは、完全なものではないし、徹底的なものでもな い。 この他の利用法についても検討することができる。 IP 認証ヘッダは、IP データグラムに機密性を提供せずに、インテグリテ ィと認証を提供するように設計されている。 機密性を提供しないことで、機密性を提供するための暗号の輸出、輸入、 そしてその利用が規制されている場所でも、インターネット上で広く認証 ヘッダの実装が利用できることが保証される。 認証ヘッダは、AH を実装している複数のホスト間、AH を実装している複 数のゲートウェイ間、AH を実装しているホストやゲートウェイとホスト やゲートウェイの組の間のセキュリティをサポートする。 セキュリティ・ゲートウェイは、外部の信頼されていないシステムと、そ の配下のサブネットワーク上の信頼されたホストとの間の通信ゲートウェ イの役割をするシステムである。 それはまた、信頼されたホストが外部の信頼されていないシステムと通信 する際に、その信頼されたホストに対してセキュリティ・サービスを提供 する。 信頼されたサブネットワークには、能動的な攻撃も受動的な攻撃もしない ことを互いに信用し合い、基本となる通信チャネル (例えば、イーサネッ トなど) が攻撃されていないことを信用するホストとルータが存在する。 セキュリティ・ゲートウェイが信頼されたサブネット上の一つ以上のホス トに代わってサービスを提供する場合、そのセキュリティ・ゲートウェイ は、その信頼されたホストに代わってセキュリティ・アソシエーションを 確立し、そのセキュリティ・ゲートウェイと外部のシステムとの間のセキ ュリティ・サービスを提供する責任を負っている。 この場合は、ゲートウェイのみが AH を実装する必要があり、ゲートウェ イの配下にある信頼されたサブネット上のすべてのシステムは、ゲートウ ェイと外部システムとの間の AH サービスを利用することができる。 信頼されたホストから、例えば IPSO [Ken91] のような認められたセンシ ティビティラベルを含むデータグラムを受け取ったセキュリティ・ゲート ウェイは、そのゲートウェイと外部の宛先との間の AH で使用するセキュ リティ・アソシエーションを生成・選択する際にそのラベルの値を考慮す るべきである。 このような環境では、IP 暗号ペイロード (ESP) を含む IP パケットを受 け取るゲートウェイは、最終的な宛先である信頼されたホストへ転送され る復号化されたパケットに対して、暗黙的 (使用されるセキュリティ・ア ソシエーションに含まれる)、あるいは明示的ラベル情報 (例えば IPSO など) を含む適切な認証を加えるべきである。 明示的センシティビティラベルを含むパケットでは、終点間でのラベルの インテグリティを保証するために、常に IP 認証ヘッダを使用するべきで ある。 セキュリティ・ゲートウェイを使用する環境では、そのセキュリティ・ゲ ートウェイは、IP セキュリティが使用されていることを知るシステムか らのものであると称する認証されていないパケットに対して、アドレスに 基づく IP パケット・フィルタリングを実行しなければならない (MUST)。 IP 暗号ペイロード (ESP) は、IP データグラムにインテグリティと認証 と機密性を提供するように設計されている [Atk95b]。 ESP は、ESP を実装している複数のホスト間、ESP を実装している複数の ゲートウェイ間、そして ESP を実装しているホストやゲートウェイとホ ストやゲートウェイの組との間のセキュリティをサポートする。 セキュリティ・ゲートウェイは、外部の信頼されていないシステムと、そ の配下のサブネットワーク上の信頼されたホストとの間の通信ゲートウェ イの役割をするシステムであり、その信頼されたホストが外部の信頼され ていないシステムと通信する際に、その信頼されたホストに対してセキュ リティ・サービスを提供する。 信頼されたサブネットワークには、能動的な攻撃も受動的な攻撃もしない ことを互いに信用し合い、基本となる通信チャネル (例えば、イーサネッ トなど) が攻撃されていないことを信用するホストとルータが存在する。 信頼されたシステムは、常に信頼できるものであるべきであるが、実際は しばしば信頼できないものである。 ゲートウェイ間での暗号化は、インターネットのような信頼されていない バックボーンを介して、仮想私設ネットワークを構築する際に最も適した 方法である。 この仮想私設ネットワークは、ゲートウェイ間の暗号化により部外者を排 除することによって実現される。 このように、ゲートウェイ間での暗号化はホスト間での暗号化を必ずしも 置き換えるものとはならず、それどころか、その二つが存在し、しばしば 共に利用されるべきものである。 セキュリティ・ゲートウェイが、信頼されたサブネット上の一つ以上のホ ストに代わってサービスを提供する場合、そのセキュリティ・ゲートウェ イは、その信頼されたホストに代わってセキュリティ・アソシエーション を確立し、そのセキュリティ・ゲートウェイと外部のシステムとの間のセ キュリティ・サービスを提供する責任を負っている。 この場合、ゲートウェイのみが ESP を実装する必要があり、ゲートウェ イの配下にある信頼されたサブネット上のすべてのシステムは、ゲートウ ェイと外部システムとの間の ESP サービスを利用することができる。 信頼されたホストから、認められたセンシティビティラベルを含むデータ グラムを受け取ったゲートウェイは、そのゲートウェイと外部の宛先との 間の ESP で使用されるセキュリティ・アソシエーションを生成・選択す る際にそのラベルの値を考慮するべきである。 このような環境では、ESP を含む IP パケットを受け取るゲートウェイ は、最終的な宛先である信頼されたホストへ転送される復号化されたパケ ットに対して、適切なラベルを付与するべきである。 明示的センシティビティラベルを含むパケットでは、終点間でのラベルの インテグリティを保証するために、常に IP 認証ヘッダを使用するべきで ある。 コネクション上にセキュリティ・ゲートウェイが存在しない場合、ESP を 実装している 2 つの終端システムは、2 つのシステム間で運ばれる利用 者データ (例えば、TCP や UDP など) のみを暗号化するように ESP を使 用しても良い。 ESP は、利用者が要求し、必要とするセキュリティのみを選択・利用でき るように、最大限の柔軟性を持つように設計される。 受信側は、インテグリティが暗号的に保証されてない経路制御ヘッダ (Routing header) は無視する必要がある (SHOULD)。 このルールが厳しく定着されないと、そのシステムは、指定経路制御攻撃 (source routing attack) を含む様々な種類の攻撃に対して弱くなる [Bel89] [CB94] [CERT95]。 これらの文書では、特に IPv4 ブロードキャストについては議論していな いが、これらの IP セキュリティの仕組みを IPv4 ブロードキャスト・パ ケットで使用しても良い (MAY)。 ただし、ブロードキャスト・アプリケーションの場合は、鍵配送とセキュ リティ・アソシエーションの管理は容易ではない。 また、対称鍵アルゴリズムが使用される場合は、受信側は、受信されたパ ケットが使用するべき正しい鍵を知っている多くのシステムの中の一つか ら来たということだけを知ることができるだけであるので、ブロードキャ スト・パケットで暗号を利用する価値は制限される。 1.4 セキュリティ・アソシエーション 「セキュリティ・アソシエーション」の概念は、IP 暗号ペイロードと IP 認証ヘッダの両方にとって基本となるものである。 与えられたセキュリティ・パラメータ・インデックス (SPI) と宛先アド レスの組み合わせによって、一意に、特定の「セキュリティ・アソシエー ション」が識別される。 認証ヘッダや暗号ペイロードの実装は、セキュリティ・アソシエーション の概念をサポートしなければならない (MUST)。 また、実装はセキュリティ・アソシエーションの一部として、他のパラメ ータをサポートしてもよい (MAY)。 セキュリティ・アソシエーションには、通常、以下にあげたパラメータが 含まれるが、同様に追加のパラメータを含むことも可能である: * IP 認証ヘッダにおいて使用される認証アルゴリズムとアルゴリズム モード [AH の実装において要求される (REQUIRED) ]。 * 認証ヘッダでの認証アルゴリズムで使用される鍵 [AH の実装において要求される (REQUIRED) ]。 * IP 暗号ペイロードにおいて使用される暗号アルゴリズムとアルゴリ ズムモードと変換 [ESP の実装において要求される (REQUIRED) ]。 * 暗号ペイロードでの暗号アルゴリズムで使用される鍵 [ESP の実装において要求される (REQUIRED) ]。 * 暗号アルゴリズムのための暗号同期や初期ベクトル・フィールドの 有/無とそのフィールド長 [ESP の実装において要求される (REQUIRED) ]。 * (使用されていれば) ESP 変換で使用される認証アルゴリズムとモ ード [ESPの実装において推奨される (RECOMMENDED) ]。 * (もしあれば) ESP 変換の中の認証アルゴリズムで使用される認証 鍵 [ESP の実装において推奨される (RECOMMENDED) ]。 * 鍵の有効期間や鍵が変更されるべき時間 [すべての実装において推奨される (RECOMMENDED) ]。 * このセキュリティ・アソシエーションの有効期間 [すべての実装において推奨される (RECOMMENDED) ]。 * セキュリティ・アソシエーションの送信元アドレス。 これは、複数の送信システムが、ある宛先に対して同じセキュリテ ィ・アソシエーションを共有する場合、ワイルドカード・アドレス となる可能性がある [すべての実装において推奨される (RECOMMENDED) ]。 * 保護されるデータのセンシティビティレベル (例えば、Secret や Unclassified など) [マルチレベルセキュリティを提供するすべてのシステムにおいて要 求され (REQUIRED)、その他のすべてのシステムにおいて推奨され る (RECOMMENDED) ]。 送信側ホストは、適切なセキュリティ・アソシエーション (と、それゆえ SPI 値) を選択するために送信側の利用者 ID と宛先アドレスを使用す る。 受信側ホストは、正しいアソシエーションを識別するために、SPI 値と宛 先アドレスの組み合わせを使用する。 よって、AH の実装では、有効なすべての到来パケットに対するセキュリ ティ・アソシエーションと、それに関連するセキュリティ設定データを決 定するために、常に SPI を宛先アドレスと組み合わせて使用することが できる。 以前は有効であったセキュリティ・アソシエーションが無効になった場合 は、宛先システムはすぐにはその SPI 値を再利用しないほうが良い (SHOULD NOT)。 宛先システムは SPI 値を他のセキュリティ・アソシエーションに再利用 する前に、その SPI 値が陳腐化するまで待つ必要がある (SHOULD)。 セキュリティ・アソシエーションは、通常、単方向である。 2 つのホスト間で認証された通信セッションでは、通常 2 つのセキュリ ティ・パラメータ・インデックスが使用される (それぞれの方向に 1 つ づつ)。 あるセキュリティ・パラメータ・インデックスとある宛先アドレスの組み 合わせによって、セキュリティ・アソシエーションが一意に識別される。 宛先アドレスは、ユニキャスト・アドレスやマルチキャスト・グループ・ アドレスであっても良い。 セキュリティ・アソシエーションが受信側指向であることは、ユニキャス ト・トラフィックの場合は、通常、宛先システムが SPI 値を選択するこ とを意味する。 宛先に SPI 値を選択してもらうことによって、手動で設定されたセキュ リティ・アソシエーションが、 (例えば鍵管理プロトコルを使用して) 自 動で設定されたセキュリティ・アソシエーションと衝突する可能性がなく なる。 マルチキャスト・トラフィックの場合は、一つの宛先マルチキャスト・グ ループに対して複数の宛先システムが存在するので、システムまたは人 は、そのマルチキャスト・グループの代わりに複数のSPI を選択し、ここ では定義されない仕組みを利用して、その情報をマルチキャスト・グルー プの正規のメンバー全員に伝える必要がある。 あるマルチキャスト・グループに対する複数の送信者は、そのグループへ のすべてのトラフィックに対して、一つのセキュリティ・アソシエーショ ン (と、それゆえセキュリティ・パラメータ・インデックス) を使用して も良い (MAY)。 この場合は、受信側はそのメッセージがそのマルチキャスト・グループに 対するセキュリティ・アソシエーション・データを知っているシステムか ら来たということだけを知ることができる。 対象アルゴリズム (例えば、DES、IDEA など) が使用される場合には、受 信側は一般にどのシステムがマルチキャスト・トラフィックを送り出した のかを認証することができない。 また、マルチキャスト・トラフィックでは、マルチキャスト・グループに 対して各送信者毎に別々のセキュリティ・アソシエーション (と、それゆ え SPI) を使用しても良い (MAY)。 それぞれの送信者が自分自身のセキュリティ・アソシエーションを持ち、 かつ非対称アルゴリズムが使用される場合には、そのデータの生成元の認 証のサービスも提供される。 2. 設計目的 この章では、このセキュリティ・アーキテクチャとその構成要素の仕組み の設計目的についていくつか記述する。 この作業の主な目的は、IPv4 と IPv6 がセキュリティを求める利用者に 利用できるような強力な暗号セキュリティの仕組みを持つことを保証する ことである。 これらのセキュリティの仕組みは、トラフィックにこれらの仕組みを利用 しないインターネット利用者に対して悪影響を及ぼさないように設計され る。 これらの仕組みは、その暗号アルゴリズムを実装の他の部分に影響を及ぼ すことなく置き換えることができるように、アルゴリズムに依存しないよ うになっている。 これらのセキュリティの仕組みは、様々なセキュリティポリシーの環境で 利用できるべきである。 標準のデフォルトのアルゴリズム (鍵付 MD5、DES CBC) は、インターネ ット全体で相互接続性を保証するために指定される。 ここで選択されたデフォルトのアルゴリズムは、SNMPv2 [GM93] で使用さ れる標準のデフォルトのアルゴリズムと同じものである。 3. IP 層セキュリティの仕組み IP のための 2 種類の暗号セキュリティの仕組みが存在する。 一つ目は、機密性なしにインテグリティと認証を提供する認証ヘッダであ る [Atk95a]。 二つ目は、常に機密性を提供し、また (アルゴリズムとモードによって は)、インテグリティと認証を提供することも可能な暗号ペイロードであ る [Atk95b]。 この 2 種類の IP セキュリティの仕組みは、共に、あるいは別々に使用 されても良い。 これらの IP 層の仕組みでは、多くのトラフィック解析攻撃に対するセキ ュリティは提供されない。 しかし、トラフィック解析からの保護を提供するために使用される可能性 のある、この仕様の範囲外の手法 (例えば、バルクリンク暗号化など) が いくつか存在する [VK83] 。 3.1 認証ヘッダ IP 認証ヘッダでは、その IP データグラムの認証情報を保有する [Atk95a]。 認証ヘッダでは、IP データグラムに対して暗号認証関数を計算し、その 計算中に秘密の認証鍵を使用する。 送信側は、認証される IP パケットを送り出す前に認証データを計算す る。 分割は、出力パケットに対する認証ヘッダ処理の後と、入力パケットに対 する認証ヘッダ処理の前に起こる。 受信側は、受信時に認証データが正しいことを確認する。 各中継点で減少する「TTL」 (IPv4) や「中継限界数 (Hop Limit) 」 (IPv6) フィールドのように、配送中に変更される必要のあるフィールド は、認証計算から省略される。 しかし、中継限界数フィールドを省略することで、提供されるセキュリテ ィに悪影響を及ぼすようなことはない。 否認防止は、認証ヘッダで使用されるいくつかの認証アルゴリズム (例え ば、送信側と受信側の鍵の両方が認証計算中に使用される非対称アルゴリ ズムなど) によって提供される可能性がある。 しかし、それは認証ヘッダで使用されるすべての認証アルゴリズムによっ て、必ずしも提供されるものではない。 デフォルトの認証アルゴリズムは鍵付 MD5 であるが、すべての対称アル ゴリズムと同じように、それ自身では否認防止を提供することはできな い。 機密性とトラフィック解析からの保護は、認証ヘッダによっては提供され ない。 認証ヘッダを使用することで、参加システムにおける IP プロトコル処理 のコストが増し、通信の待ち時間も増加する。 この待ち時間は、主に認証ヘッダ (AH) を含むそれぞれの IP データグラ ムに対する、送信側での認証データの計算と、各受信側での認証データの 計算およびその比較によって増加する。 認証ヘッダは、現在のインターネットの大部分に存在するものよりも、非 常に強力なセキュリティを提供するものであり、輸出の可能性に影響を及 ぼしたり、大幅に実装コストを増加させるものであるべきではない。 セキュリティ・ゲートウェイが、そのセキュリティ・ゲートウェイの配下 の信頼されたネットワーク上のホストに代わって認証ヘッダを実装する場 合には、この動作モードは勧められない。 認証ヘッダは、生成元から最終的な宛先までに対して使用されるべきであ る。 IPv6 が利用できるすべてのホストでは、少なくとも 128 ビットの鍵を使 用する MD5 アルゴリズムと共に IP 認証ヘッダを実装しなければならな い (MUST)。 認証ヘッダを実装する IPv4 システムでは、少なくとも 128 ビットの鍵 を使用する MD5 アルゴリズムと共に IP 認証ヘッダを実装しなければな らない (MUST) [MS95]。 実装は、鍵付 MD5 に加えて他の認証アルゴリズムをサポートしても良い (MAY)。 3.2 暗号ペイロード IP 暗号ペイロード (ESP) は、IP データグラムにインテグリティと認証 と機密性を提供するように設計されている [Atk95b] 。 暗号ペイロードでは、IP データグラム全体か、上位層プロトコル (例え ば TCP、UDP、ICMP など) のデータのみを ESP 内部にカプセル化し、そ の ESP の内容の大部分を暗号化し、その暗号化された暗号ペイロードに 新しい平文の IP ヘッダを追加する。 この平文の IP ヘッダは、保護されたデータをインターネットワークを通 して運ぶために使用される。 3.2.1 ESP のモードについての記述 ESP には 2 種類のモードがある。 トンネルモードとして知られる一つ目のモードは、ESP ヘッダの中に IP データグラム全体をカプセル化する。 トランスポートモードとして知られる二つ目のモードは、ESP の内側に上 位層プロトコル (例えば UDP や TCP など) をカプセル化し、それから平 文の IP ヘッダが付加される。 3.2.2 ESP の利用法 ESP は、ホスト間、ホストとセキュリティ・ゲートウェイ間、あるいはセ キュリティ・ゲートウェイ間で動作する。 ESP をセキュリティ・ゲートウェイでサポートすることで、暗号化を行な うセキュリティ・ゲートウェイの背後に信頼できるネットワークを作るこ とができ、信頼できないネットワーク・セグメントを通過するトラフィッ クに機密性を提供しながら、暗号化の性能と費用のコストを抑えることが できる。 両側のホストが直接 ESP を実装し、その間に割り込むセキュリティ・ゲ ートウェイが存在しない場合には、トランスポートモード (上位層プロト コルデータ (例えば TCP や UDP など) のみが暗号化され、暗号化された IP ヘッダは存在しない) を使用しても良い。 IP データグラム全体を機密にする必要がない利用者は、このモードを使 うことにより、消費される帯域とプロトコル処理のコストを抑えることが できる。 ESP は、ユニキャストとマルチキャスト・トラフィックの両方で動作す る。 3.2.3 ESP の性能の影響 ESP によって使用されるセキュリティ・カプセル化のアプローチは、参加 システムのネットワーク性能に著しく影響を与えるものであるが、ESP を 使用することによって、特別な ESP アソシエーションに参加していない ルータや他の中間システムに悪影響を及ぼすものであるべきではない。 セキュリティ・カプセル化が使用される場合、参加システムのプロトコル 処理はより多くの時間とより多くの処理能力を必要とするため、より複雑 となる。 また、暗号化を使用することによって、通信の待ち時間が増加する。 この待ち時間は、主に暗号ペイロードを含むそれぞれの IP データグラム に要求される暗号化と復号化によって増加する。 ESP にかかるコストは、正確にはその暗号アルゴリズム、鍵長、そしてそ の他の要素を含む実装の特性によって変化する。 高いスループットが要求される場合には、その暗号アルゴリズムをハード ウェアで実装することが求められる。 世界的なインターネットを通した相互接続性のために、IP 暗号ペイロー ドに準拠するすべての実装は、ESP の仕様において詳述されるような、暗 号ブロック連鎖 (Cipher-Block Chaining : CBC) モードでの Data Encryption Standard (DES) の使用をサポートしなければならない (MUST)。 また、この必須アルゴリズムとモードに加えて、他の機密性アルゴリズム とモードを実装しても良い。 暗号の輸出と利用はいくつかの国で規制される [OTA94]。 3.3 セキュリティの仕組みの組み合わせ ある状況では、IP 認証ヘッダは、要求されたセキュリティの性質を得る ために IP 暗号ペイロードと組み合わせられる可能性がある。 認証ヘッダは、常にインテグリティと認証を提供し、ある認証アルゴリズ ム (例えば、RSA など) が使用される場合には、否認防止を提供すること が可能となる。 暗号ペイロードは、常にインテグリティと機密性を提供し、ある認証暗号 化アルゴリズムが使用される場合には、認証を提供することも可能であ る。 暗号ペイロードを使用してデータグラムをカプセル化する前に、認証ヘッ ダを IP データグラムに加えることは、強力なインテグリティ、認証、機 密性を持つことを望む利用者、そしておそらく、強い否認防止を必要とす る利用者にとって望ましいことであるかもしれない。 この 2 種類の仕組みが組み合わされた場合、IP 認証ヘッダが置かれてい る場所によって、そのデータのどの部分が認証されるのかが明らかにな る。 この 2 種類の仕組みの組み合わせについては、IP 暗号ペイロードの仕様 の中で詳細に記述される [At94b]。 3.4 その他のセキュリティの仕組み トラフィック解析からの保護は、前述のセキュリティの仕組みのいずれに よっても提供されない。 トラフィック解析からの意味のある保護をインターネット層で経済的に提 供することができるのかどうかは明確ではないし、トラフィック解析を気 にかけているインターネット利用者はほとんどいないように思える。 トラフィック解析からの保護の一つの伝統的な方法は、バルクリンク暗号 化の利用である。 もう一つの手法は、トラフィック解析によって提供されるデータ中のノイ ズを増やすように、間違ったトラフィックを送り出すものである。 参考文献 [VK83] では、トラフィック解析の問題についてより詳細に議論 されている。 4. 鍵管理 IP 層セキュリティで使用される鍵管理プロトコルは、この文書では指定 されない。 しかし、鍵管理プロトコルはセキュリティ・パラメータ・インデックス (SPI) のみを通して AH と ESP に結ばれるので、鍵管理の方法を完全に 指定することなく、有効に AH と ESP を定義することができる。 いくつかの鍵管理システムが、手動鍵設定を含めてこれらの仕様で利用す ることが可能であると予想される。 現在、インターネット標準の鍵管理プロトコルを定義するための作業が、 IETF において進行中である。 鍵管理データが IP 層によって運ばれるような鍵管理手法をサポートする ことは、これらの IP 層セキュリティの仕組みの設計目的ではない。 これらの IP 層セキュリティの仕組みでは、主に鍵管理データが、UDP や TCP のような上位層プロトコルのある特定のポートによって運ばれるか、 あるいは鍵管理データが手動で配送されるような鍵管理方法が利用され る。 この設計により、鍵管理の仕組みを他のセキュリティの仕組みから明確に 分け、それによって他のセキュリティの仕組みの実装を修正することな く、代わりとなる新しい、改善された鍵管理方法を取り入れることができ る。 この仕組みの分離は、長い間鍵管理プロトコルの知らぬ間に作用する欠点 が発表されてきたことを考えると、明らかに賢いことである [NS78, NS81]。 この章の後には、鍵管理のいくつかの代替アプローチに関する簡単な議論 が続く。 相互に同意するシステムは、事前にそのシステム間で同意しておくことに よって、他の追加の鍵管理アプローチを使用しても良い。 4.1 手動鍵配送 鍵管理の最も単純な形態は手動鍵管理である。 手動鍵管理では、それぞれのシステムにおいて人が手動でそれ自身の鍵と 他の通信システムの鍵を設定する。 これは、規模の小さい、静的なシステム環境では非常に実用的であるが、 スケーラビリティに欠ける。 これは、中期的、あるいは長期的に利用できるアプローチではないが、多 くの環境では、短期的なものとしては適当なものであり、利用できるもの であるかもしれない。 例えば、規模の小さい LAN では、それぞれのシステムにおいて鍵を手動 で設定することは、まさに実用的である。 また、単一の管理ドメイン内で、経路制御データを保護し、侵入者がルー タに侵入する危険を減らすために、それぞれのルータにおいて鍵を設定す ることも実用的である。 その他には、ある組織が各サイトの内部ネットワークとインターネットと の間に暗号化ファイアウォールを設置し、インターネットを介して複数の サイトを接続している場合がある。 この場合は、暗号化ファイアウォールは、組織の他のサイトへのトラフィ ックに対しては、手動で設定された鍵を使用して選択的に暗号化をする が、他の宛先に対するトラフィックに対しては暗号化はしない。 これは、選択された通信のみを安全にする必要のある場合は、適切である かもしれない。 4.2 いくつかの既存の鍵管理手法 世の中の文献に記述されている鍵管理アルゴリズムには多くのものが存在 する。 Needham と Schroeder は、集中化鍵配送システムに頼る鍵管理アルゴリ ズムを提案した [NS78, NS81]。 このアルゴリズムは、MIT のアテナプロジェクトで開発されたケルベロス 認証システムで使用される [KB93]。 Diffie と Hellman は、集中化鍵配送システムを必要としないアルゴリズ ムを工夫した [DH76]。 あいにく、もともとの Diffie-Hellman 法は「中間一致攻撃」に弱い [Sch93, p. 43-44]。 しかし、この弱点は、Diffie-Hellman 交換へのブートストラップ時に、 署名された鍵を使用して認証することにより和らげることができる [Sch93, p. 45]。 4.3 自動鍵配送 IP セキュリティを広く展開し利用するには、インターネット標準規模の 鍵管理プロトコルが必要となる。 理想的には、そのようなプロトコルは IP セキュリティのみではなく、イ ンターネット・プロトコル群の多くのプロトコルをサポートするのが望ま しい。 現在、署名されたホスト鍵をドメイン名システムに加える作業が、IETF において進行中である [EK94]。 この DNS 鍵を利用すると、それを生成した組織は、非対称アルゴリズム を使用している他の鍵管理組織と鍵管理メッセージを認証することが可能 となる。 それによって 2 つの組織は認証通信チャネルを持つことができ、それを Diffie-Hellman などの手法を利用して共有セッション鍵を生成するため に利用することができる [DH76] [Sch93]。 4.4 IP における鍵管理のアプローチ IP のための鍵管理アプローチには 2 種類のものが存在する。 ホスト別鍵管理と呼ばれる一つ目のアプローチは、ホスト 1 上のすべて の利用者がホスト 2 上のすべての利用者宛てのトラフィックに対して同 じ鍵を共有し、利用するものである。 利用者別鍵管理と呼ばれる二つ目のアプローチは、ホスト 1 上の利用者 A が、ホスト 2 宛てのトラフィックに対して 1 つ以上のユニークなセッ ション鍵を持つというものである。 このセッション鍵は、ホスト 1 上の他の利用者とは共有されない。 例えば、利用者 A の FTP セッションは、利用者 A の TELNET セッショ ンと異なる鍵を使用する可能性がある。 マルチレベル・セキュリティを提供するシステムでは、利用者 A は使用 するセンシティビティレベルにつき、通常少なくとも 1 つの鍵を持つ (例えば、UNCLASSIFIED トラフィックに対して一つの鍵、SECRET トラフ ィックに対して二つ目の鍵、そして TOP SECRET トラフィックに対して三 つ目の鍵というように)。 同様に、利用者別鍵管理では、ある者は、マルチキャスト・グループに送 られた情報と、同じマルチキャスト・グループに送られた制御メッセージ に対して別々の鍵を使用する可能性がある。 多くの場合、一つのコンピュータシステムには、少なくとも 2 人の、互 いに信頼しない相互に疑い深い利用者 A と B が存在する。 ホスト別鍵管理が使用され、相互に疑い深い利用者が存在する場合、利用 者 A は、選択平文攻撃のような良く知られた方法によってそのホスト別 鍵を調べることができる。 一度、利用者 A が不当にその使用中の鍵を手に入れると、利用者 A は利 用者 B の暗号化されたトラフィックを読んだり、利用者 B からのトラフ ィックを偽造したりすることができる。 利用者別鍵管理が使用される場合には、ある利用者が他の利用者のトラフ ィックに対してある種の攻撃をすることはできない。 適切なアルゴリズムが使用されている場合、IP セキュリティは接続され た終端システムで動作しているアプリケーションに対して、認証とインテ グリティと機密性を提供できるようになる。 適切な動的鍵管理手法と適切なアルゴリズムが使用されている場合、イン テグリティと機密性はホスト別鍵管理によっても提供することができる。 しかし、終端システム上でアプリケーションを使用している主体 (principal) を認証するためには、アプリケーションを動作させるプロ セスが、それ自身のセキュリティ・アソシエーションを要求し、使用する ことができるようにする必要がある。 このようにすることで、アプリケーションは認証を提供する鍵配送機能を 使用することが可能となる。 それゆえに、利用者別鍵管理のサポートはすべての IP 実装において実現 される必要がある (SHOULD)。 これについては、後述の「IP 鍵管理要求事項」の章で記述される。 4.5 マルチキャスト鍵配送 執筆時点で発表されている文献の中においては、マルチキャスト鍵配送は 積極的な研究分野である。 比較的少数のメンバーを持つマルチキャスト・グループに対しては、手動 鍵配布や、修正 Diffie-Hellman のような既存のユニキャスト鍵配送アル ゴリズムの重ねての使用は利用できそうである。 非常に大きなグループに対しては、新しいスケーラブルな手法が必要とさ れる。 マルチキャスト経路制御と同時にセッション鍵管理を提供するコアベース ツリー (CBT) の利用は、将来利用されるアプローチとなる可能性がある [BFC93] 。 4.6 IP 鍵管理要求事項 この章では、すべての IPv6 の実装と、IP 認証ヘッダ、IP 暗号ペイロー ド、あるいはその両方を実装する IPv4 の実装に対しての鍵管理の要求事 項について定義する。 この要求事項は、IP 認証ヘッダと IP 暗号ペイロードにも同様に適用さ れる。 すべての実装は、セキュリティ・アソシエーションの手動設定をサポート しなければならない (MUST)。 すべての実装は、一度、インターネット標準のセキュリティ・アソシエー ション確立プロトコル (例えば、IKMP、Photuris など) がインターネッ ト・スタンダードトラック RFC として発行されたならば、そのプロトコ ルをサポートする必要がある (SHOULD)。 実装はまた、その他のセキュリティ・アソシエーションの設定方法をサポ ートしても良い (MAY)。 2 つの終点が与えられた場合、その間の通信に対して同時に複数のセキュ リティ・アソシエーションを持つことができるようにしなければならない (MUST)。 マルチユーザ・ホストでの実装は、ユーザ・グラニュラリティ (すなわ ち、「利用者別」) セキュリティ・アソシエーションをサポートする必要 がある (SHOULD)。 すべての実装は、ホスト別鍵管理の設定ができるようにしなければならな い (MUST)。 例えば、専用の IP 暗号化機器や暗号化ゲートウェイのような、他のシス テムで生成された IP パケットを暗号化または認証する機器は、一般に他 のシステムで生成されたトラフィックに対して利用者別鍵管理を提供する ことはできない。 このようなシステムは、追加として他のシステムで生成されたトラフィッ クに対する利用者別鍵管理のサポートを実装しても良い (MAY)。 あるシステムで鍵を設定する方法は、実装毎に定義される。 例えば、セキュリティ・アソシエーション識別子や鍵を含むセキュリテ ィ・パラメータをフラットファイルに書き込むことは、手動鍵配送での考 えられる方法の一例である。 IP システムは、セキュリティのすべてがその鍵にあるため、不正な調査 や改ざんから鍵やその他のセキュリティ・アソシエーション情報を保護す るための合理的な措置をとらなければならない (MUST)。 5. 利用法 この章では、セキュリティ・リスクを減らすためにこれらの仕組みがどう 利用されるのかということについてのより良い案を実装者と利用者に提供 するために、いくつかの異なる環境、そして異なるアプリケーションでの IP で提供されるセキュリティの仕組みの可能な利用法について記述す る。 5.1 ファイアウォールとの利用 ファイアウォールは、現在のインターネットにおいて珍しいものではない [CB94]。 ファイアウォールは接続性を制限するため、多くの人がその存在を嫌う が、それは近い将来に消滅しそうにはない。 これらの IP の仕組みの両方とも、ファイアウォールによって提供される セキュリティを強化するように利用することができる。 IP で使用されるファイアウォールは、しばしば使用されているトランス ポートプロトコル (例えば、UDP や TCP など) とそのプロトコルのポー ト番号を調べるために、そのヘッダとオプションを切り離す必要がある。 ファイアウォールは、ファイアウォールが適切なセキュリティ・アソシエ ーションに参加しているかどうかとは別に、認証ヘッダと共に利用するこ とが可能である。 しかし、適切なセキュリティ・アソシエーションに参加していないファイ アウォールは、通常、パケット毎のフィルタリングを実行するために必要 なプロトコル番号やポート番号を調べるためや、アクセス制御の決定のた めに使用されるデータ (例えば、送信元、宛先、トランスポートプロトコ ル、ポート番号など) が正しく、本物であることを確認するために必要で ある、暗号化された上位層プロトコルの復号化ができない。 このため、認証は組織やキャンパス内のみではなく、インターネットを介 した遠隔システムとの終点間で実行される可能性がある。 IP での認証ヘッダのこの利用法は、アクセス制御の決定のために使用さ れるデータが本物であることの、より確かな保証を提供する。 商用の IP サービスを利用して接続している複数のサイトをもつ組織は、 選択的に暗号化を行なうファイアウォールの利用を望むかもしれない。 企業の各サイトと商用の IP サービス・プロバイダとの間に暗号化ファイ アウォールが設置された場合、そのファイアウォールは企業のすべてのサ イト間に暗号化 IP トンネルを提供することができる。 また、そのファイアウォールは、その企業とその供給会社、顧客、そして 他の関連する場所との間のトラフィックを暗号化することもできる。 ただし、ネットワーク情報センター、公共のインターネット・アーカイ ブ、あるいは他のいくつかの組織のトラフィックは、標準の鍵管理プロト コルが利用できないため、あるいは、よりよい通信、ネットワーク性能の 改善、そして接続性の増加を容易にするためという理由で、故意に暗号化 しないかもしれない。 このようにすることによって、盗聴と改ざんから簡単にその会社の機密ト ラフィックを保護することができる。 いくつかの組織 (例えば、政府など) では、商用の IP サービス上に保護 された仮想ネットワークを構築するために、完全な暗号化ファイアウォー ルを利用することを望むかもしれない。 この暗号化ファイアウォールとバルク IP 暗号化機器との違いは、完全な 暗号化ファイアウォールは IP パケットを暗号化すると同時に、復号化さ れたトラフィックのフィルタリングも提供することである。 5.2 IP マルチキャストとの利用 過去数年の間に、マルチキャスト・バックボーン (MBONE) は、急激に成 長した。 IETF などの会議では、現在、リアルタイム・オーディオやビデオ、ホワ イトボードに対して定期的にマルチキャストを利用している。 現在、多くの人々が、インターネットや内部プライベート・ネットワーク で IP マルチキャストに基づくテレビ会議アプリケーションを利用してい る。 他には、分散シミュレーションなどのアプリケーションをサポートするた めに IP マルチキャストが利用されている。 よって、IP におけるセキュリティの仕組みが、マルチキャストが一般的 な環境での利用に適しているかどうかということは、重要なことである。 IP セキュリティの仕組みで使用されるセキュリティ・パラメータ・イン デックス (SPI) は受信側指向であるため、IP マルチキャストでの利用に よく適している [Atk95a, Atk95b]。 あいにく、現在発表されているほとんどのマルチキャスト鍵配送プロトコ ルはうまく動作していない。 しかし、この分野では積極的な研究がされている。 仮のステップとして、マルチキャスト・グループにおいて、すべての参加 者に鍵を配送するために、安全なユニキャスト鍵配送プロトコルを繰り返 し使用するか、あるいは、そのグループでは手動鍵配送を使用することに よって、鍵を前もって手配することができる。 5.3 QOS 保護を提供するための使用 最近の IAB セキュリティ・ワークショップでは、サービス品質の保護が 重要な関心分野とされた [BCCH]。 IP セキュリティの 2 種類の仕組みは、マルチキャスティングと同様にリ アルタイム・サービスに対しても上質のサポートを提供するものである。 この章では、サービス品質の保護を提供するための 1 つの可能なアプロ ーチについて記述する。 認証ヘッダは、パケットの認証を提供するために、適切な鍵管理と共に使 用されるかもしれない。 この認証は、実はルータでのパケット分類において重要である。 IPv6 フロー識別子は、低レベル識別子 (LLID) の役目をすることがあ る。 ルータが適切な鍵管理マテリアルを備えている場合には、共に使用するこ とによって、ルータでのパケット分類が正確になる。 性能の理由により、ルータはすべてのパケットではなく、すべての N 番 目のパケットのみを認証するかもしれない。 しかし、これは現在のインターネットの性能に対してのみ意味のある改良 である。 また、サービス品質を提供するために、フロー ID を RSVP [ZDESZ93] の ような帯域予約プロトコルと組み合わせて利用する可能性がある。 このように、分類されるパケットを認証することによって、各パケットが ルータ内部で適切な処理を受けることが保証される。 5.4 コンパートメントあるいはマルチレベル・ネットワークでの利用 マルチレベル・セキュア (MLS) ・ネットワークは、一つのネットワーク で異なるセンシティビティレベル (例えば、Unclassified や Secret な ど) のデータを伝送するものである [DoD85] [DoD87]。 多くの政府は、MLS ネットワーキングに対して強い関心を持っている [DIA]。 IP セキュリティの仕組みは、 MLS ネットワーキングをサポートするよう に設計されてきた。 MLS ネットワーキングでは、普通の利用者が制御したり、破ることのでき ない強力な強制アクセス制御 (MAC) の利用が要求される [BL73]。 この章では、MLS システム環境における、これらの IP セキュリティの仕 組みの利用のみに関して述べる。 認証ヘッダは、シングルレベル・ネットワークのホスト間に強力な認証を 提供するために利用することができる。 また、認証ヘッダは、マルチレベル・ネットワークにおける強制アクセス 制御の決定と、あらゆる種類のネットワークにおける任意アクセス制御の 決定の両方に対して、強い保証を提供するために利用することができる。 ある動作環境において明示的 IP センシティビティラベル (例えば、IPSO など) [Ken91] が使用され、機密性が必要であると考えられない場合、認 証ヘッダはパケット全体に対する認証を提供し、そのセンシティビティレ ベルと IP ヘッダおよび利用者データを暗号的に結合させるために使用さ れる。 これは、認証や、ラベルと IP ヘッダおよび利用者データとの暗号的な結 合が存在しないためにそのラベルが信頼できないものであっても、そのラ ベルが信頼されているものとされているラベル付 IPv4 ネットワークに対 する意味のある改良である。 IPv6 は、通常、明示的センシティビティラベルを使用する代わりに、セ キュリティ・アソシエーションの一部であり、各パケットでは送られるこ とのない暗黙的センシティビティラベルを使用する。 すべての明示的 IP センシティビティラベルは、ESP、AH、あるいはその 両方を使用して認証されなければならない (MUST)。 完全なマルチレベル・セキュア・ネットワーキングを提供するために、暗 号ペイロードを適切な鍵ポリシーと組み合わせることができる。 この場合、それぞれの鍵は、一つのセンシティビティレベルとコンパート メントでのみ使用されなければならない。 例えば、鍵「B」が Secret/No-compartment トラフィックに対してのみに 使用され、鍵「C」が Secret/No-Foreign トラフィックに対してのみに使 用されるのに対して、鍵「A」はセンシティビティレベルが Unclassified のパケットに対してのみに使用される可能性がある。 保護されるトラフィックのセンシティビティレベルは、そのトラフィック で使用されるセキュリティ・アソシエーションのセンシティビティレベル を支配してはならない (MUST NOT)。 セキュリティ・アソシエーションのセンシティビティレベルは、そのセキ ュリティ・アソシエーションに属している鍵のセンシティビティレベルを 支配してはならない (MUST NOT)。 鍵のセンシティビティレベルは、そのセキュリティ・アソシエーションの センシティビティレベルと同じである必要がある (SHOULD)。 また、認証ヘッダも同様の理由で異なる複数の鍵を持つことができ、その 鍵の選択はパケットのセンシティビティレベルに部分的に依存する。 すべてのホストが保護された環境の中にある場合でも、暗号化は非常に有 用であり、望まれるものである。 暗黙的センシティビティラベルか明示的センシティビティラベル (IPSO が IPv4 に対して提供するような [Ken91]) と関連して強力な任意アクセ ス制御 (DAC: Discretionary Access Control) を提供するために、イン ターネット標準の暗号化アルゴリズムを適切な鍵管理と共に使用すること ができる。 ある環境では、強制アクセス制御 (MAC) を提供するために、インターネ ット標準の暗号化アルゴリズムを十分に強いとみなすかもしれない。 コンピューティング環境が保護されていると考えられる場合でも、マルチ レベル・コンピュータかコンパートメントモード・ワークステーションの 間のすべての通信に対して、完全な暗号化を使用する必要がある (SHOULD)。 6. セキュリティに関する考慮事項 このメモの全体では、インターネット・プロトコルにおけるセキュリテ ィ・アーキテクチャについて議論している。 それは、インターネットにおけるセキュリティ・アーキテクチャの全体に ついてではないが、代わりに IP 層に焦点をあてている。 ブロック連鎖アルゴリズムを使用し、強いインテグリティの仕組みを持た ない ESP の暗号変換は、Bellovin によって記述されている、カットアン ドペースト攻撃に弱く、ESP 変換を使用するパケットで常に認証ヘッダが 使用されていないのであれば、その変換を使用するべきではない [Bel95] 。 複数の送信者が、ある宛先に対するセキュリティ・アソシエーションを共 有する場合、受信システムは、そのパケットがそれらのシステムの中の一 つから送られたということのみを認証できるのであって、それらのシステ ムのどれがそのパケットを送り出したのかということについては認証する ことができない。 同様に、受信システムが、あるパケットに対して使用されるセキュリテ ィ・アソシエーションが、そのパケットの送信元アドレスに対して有効で あるのかどうかをチェックしないのであれば、その受信システムは、その パケットの送信元アドレスが有効であるかどうかを認証することができな い。 例えば、送信者「A」と「B」のそれぞれが、宛先「D」に対するそれ自身 のユニークなセキュリティ・アソシエーションを持つとする。 この時、「B」は「D」に対しての有効なセキュリティ・アソシエーション を使用するが、「A」の送信元アドレスを偽造した場合、「D」がその送信 元アドレスが、使用されているセキュリティ・アソシエーションに関係し ているものかどうかを確認しない限り、そのパケットは「A」から来たも のであると信じ込まされる。 利用者は、これらの 2 種類の IP セキュリティの仕組みによって提供さ れるセキュリティの質は完全に、実装される暗号アルゴリズムの強度、使 用されている鍵の強度、暗号アルゴリズムの正確な実装、鍵管理プロトコ ルのセキュリティ、そしてすべての参加システムにおける IP といくつか のセキュリティの仕組みの正確な実装に依存することを理解する必要があ る。 実装のセキュリティは、セキュリティの実装を具体化するオペレーティン グシステムのセキュリティに部分的に関係する。 例えば、そのオペレーティングシステムが秘密の暗号鍵 (つまり、すべて の対称鍵と、秘密の非対称鍵) を秘密に保たないならば、それらの鍵を使 用するトラフィックは安全ではない。 これらのいずれかが不正確であり、または十分に安全でないのならば、本 当のセキュリティは利用者には全く提供されない。 同じシステム上の異なる利用者がお互いを信頼しない可能性があるため、 各利用者や各セッションは、通常、別々に鍵を管理するべきである。 これはまた、すべてのトラフィックが同じ鍵を使用するわけではないた め、そのトラフィックの暗号解析に要求される作業を増加させることにな る。 あるセキュリティの性質 (例えば、トラフィック解析からの保護など) は、これらの仕組みのいずれによっても提供されない。 トラフィック解析からの保護に対する一つの可能なアプローチは、リンク 暗号化を適切に利用することである [VK83]。 利用者は、自分達がどのセキュリティの性質を必要とするのかを慎重に考 え、自分達が必要とするものがこれらの仕組みや他の仕組みに確実に合う ものとなるように、積極的な措置を取らなければならない。 おそらく、あるアプリケーション (例えば、電子メールなど) では、その アプリケーション特有のセキュリティの仕組みを持つ必要がある。 アプリケーション特有のセキュリティの仕組みについては、この文書の範 囲外である。 電子メールのセキュリティに興味がある利用者は、インターネット・プラ イバシー・エンハンスド・メール・システムについて記述している RFC を調べるべきである。 その他のアプリケーション特有の仕組みについて関心がある利用者は、適 切なインターネット標準の仕組みが存在するかどうかを確かめるために、 オンラインの RFC を調べるべきである。 謝辞 ここの概念の多くは、米国政府の SDNS セキュリティ・プロトコルの仕 様、 ISO/IEC の NLSP の仕様、提案された swIPe セキュリティ・プロト コルの仕様から影響を受け、得られたものである [SDNS, ISO, IB93, IBK93]。 SNMP セキュリティと SNMPv2 セキュリティのためになされた作業は、デ フォルトの暗号アルゴリズムとモードの選択に影響を与えた [GM93]。 Steve Bellovin、 Steve Deering、Richard Hale、George Kamis、Phil Karn、Frank Kastenholz、 Perry Metzger、Dave Mihelcic、Hilarie Orman そして Bill Simpson からは、この文書の初期のバージョンにおい て注意深い批評を提供して頂いた。 参考文献 [Atk95a] Atkinson, R., "IP Authentication Header", RFC 1826, NRL, August 1995. [Atk95b] Atkinson, R., "IP Encapsulating Security Payload", RFC 1827, NRL, August 1995. [BCCH94] Braden, R., Clark, D., Crocker, S., and C. Huitema, "Report of IAB Workshop on Security in the Internet Architecture", RFC 1636, USC/Information Sciences Institute, MIT, Trusted Information Systems, INRIA, June 1994. [Bel89] Steven M. Bellovin, "Security Problems in the TCP/IP Protocol Suite", ACM Computer Communications Review, Vol. 19, No. 2, March 1989. [Bel95] Steven M. Bellovin, Presentation at IP Security Working Group Meeting, Proceedings of the 32nd Internet Engineering Task Force, March 1995, Internet Engineering Task Force, Danvers, MA. [BFC93] A. Ballardie, P. Francis, & J. Crocroft, "Core Based Trees: An Architecture for Scalable Inter-Domain Multicast Routing", Proceedings of ACM SIGCOMM 93, ACM Computer Communications Review, Volume. 23, Number 4, October 1993, pp. 85-95. [BL73] Bell, D.E. & LaPadula, L.J., "Secure Computer Systems: Mathematical Foundations and Model", Technical Report M74-244, The MITRE Corporation, Bedford, MA, May 1973. [CB94] William R. Cheswick & Steven M. Bellovin, Firewalls & Internet Security, Addison-Wesley, Reading, MA, 1994. [DIA] US Defense Intelligence Agency, "Compartmented Mode Workstation Specification", Technical Report DDS-2600-6243-87. [DoD85] US National Computer Security Center, "Department of Defense Trusted Computer System Evaluation Criteria", DoD 5200.28-STD, US Department of Defense, Ft. Meade, MD., December 1985. [DoD87] US National Computer Security Center, "Trusted Network Interpretation of the Trusted Computer System Evaluation Criteria", NCSC-TG-005, Version 1, US Department of Defense, Ft. Meade, MD., 31 July 1987. [DH76] W. Diffie & M. Hellman, "New Directions in Cryptography", IEEE Transactions on Information Theory, Vol. IT-22, No. 6, November 1976, pp. 644-654. [EK94] D. Eastlake III & C. Kaufman, "Domain Name System Protocol Security Extensions", Work in Progress. [GM93] Galvin J., and K. McCloghrie, "Security Protocols for version 2 of the Simple Network Management Protocol (SNMPv2) ", RFC 1446, Trusted Information Systems, Hughes LAN Systems, April 1993. [HA94] Haller, N., and R. Atkinson, "On Internet Authentication", RFC 1704, Bell Communications Research, NRL, October 1994. [Hin94] Bob Hinden (Editor) , Internet Protocol version 6 (IPv6) Specification, Work in Progress, October 1994. [ISO] ISO/IEC JTC1/SC6, Network Layer Security Protocol, ISO-IEC DIS 11577, International Standards Organisation, Geneva, Switzerland, 29 November 1992. [IB93] John Ioannidis and Matt Blaze, "Architecture and Implementation of Network-layer Security Under Unix", Proceedings of USENIX Security Symposium, Santa Clara, CA, October 1993. [IBK93] John Ioannidis, Matt Blaze, & Phil Karn, "swIPe: Network-Layer Security for IP", presentation at the Spring 1993 IETF Meeting, Columbus, Ohio. [Ken91] Kent, S., "US DoD Security Options for the Internet Protocol", RFC 1108, BBN Communications, November 1991. [Ken93] Kent, S., "Privacy Enhancement for Internet Electronic Mail: Part II: Certificate-Based Key Management", RFC 1422, BBN Communications, February 1993. [KB93] Kohl, J., and B. Neuman, "The Kerberos Network Authentication Service (V5) ", RFC 1510, Digital Equipment Corporation, USC/Information Sciences Institute, September 1993. [MS95] Metzger, P., and W. Simpson, "IP Authentication with Keyed MD5", RFC 1828, Piermont, Daydreamer, August 1995. [KMS95] Karn, P., Metzger, P., and W. Simpson, "The ESP DES-CBC Transform", RFC 1829, Qualcomm, Inc., Piermont, Daydreamer, August 1995. [NS78] R.M. Needham & M.D. Schroeder, "Using Encryption for Authentication in Large Networks of Computers", Communications of the ACM, Vol. 21, No. 12, December 1978, pp. 993-999. [NS81] R.M. Needham & M.D. Schroeder, "Authentication Revisited", ACM Operating Systems Review, Vol. 21, No. 1., 1981. [OTA94] US Congress, Office of Technology Assessment, "Information Security & Privacy in Network Environments", OTA-TCT-606, Government Printing Office, Washington, DC, September 1994. [Sch94] Bruce Schneier, Applied Cryptography, Section 8.6, John Wiley & Sons, New York, NY, 1994. [SDNS] SDNS Secure Data Network System, Security Protocol 3, SP3, Document SDN.301, Revision 1.5, 15 May 1989, published in NIST Publication NIST-IR-90-4250, February 1990. [VK83] V.L. Voydock & S.T. Kent, "Security Mechanisms in High-level Networks", ACM Computing Surveys, Vol. 15, No. 2, June 1983. [ZDESZ93] Zhang, L., Deering, S., Estrin, D., Shenker, S., and D. Zappala, "RSVP: A New Resource ReSerVation Protocol", IEEE Network magazine, September 1993. 否認事項 このノートにおいて示された見解は著者によるものであり、必ずしもその 雇い主によるものではない。 Naval Research Laboratory は、この成果の (もしあるならば) メリット に対する判断を下していない。 著者とその雇い主は、特に、正確/不正確な実装、および、この設計の利 用から生じるどのような問題への責任も放棄する。 著者の連絡先 Randall Atkinson Information Technology Division Naval Research Laboratory Washington, DC 20375-5320 USA Phone: (202) 767-2389 Fax: (202) 404-8590 EMail: atkinson@itd.nrl.navy.mil 翻訳者 東京都中央区新川1-21-2 茅場町タワー 株式会社 NTTデータ 技術開発本部 馬場 達也 EMail: baba@rd.nttdata.co.jp 著作権表示全文 Copyright (C) The Internet Society (1995) . All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.