ネットワーク ワーキング グループ
Request for Comments： 1825
分類： スタンダードトラック		 R. Atkinson
Naval Research Laboratory

1995年8月

English

インターネットプロトコルのためのセキュリティアーキテクチャ
(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）。
セキュリティ・アソシエーションには、通常、以下にあげたパラメータが含まれるが、同様に追加のパラメータを含むことも可能である：

送信側ホストは、適切なセキュリティ・アソシエーション (と、それゆえ 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

翻訳者

〒135-6033
東京都江東区豊洲3-3-3
豊洲センタービル
NTTデータ通信株式会社
馬場 達也

EMail: baba@open.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.