English

IP 暗号ペイロード (ESP)
(IP Encapsulating Security Payload (ESP))

このメモの位置付け

この文書は、インターネット・コミュニティに対してインターネット・スタンダードトラックのプロトコルを規定するとともに、それを改良するための議論や提言を求めるものである。
このプロトコルの標準化状態、およびステータスについては、"Internet Official Protocol Standards" (STD 1) の最新版を参照すること。
このメモの配布に制限はない。

要旨

この文書では、IP 暗号ペイロード（Encapsulating Security Payload：ESP）$K$D$$$F5-=R$9$k!#
ESP は、IP データグラムにインテグリティと機密性を提供するための仕組みである。
また、ある状況では、IP データグラムに認証を提供することもできる。
この仕組みは IPv4 と IPv6 の両方で動作する。

1. はじめに

ESP は、IP データグラムにインテグリティと機密性を提供するための仕組みである。
それは、使用するアルゴリズムやアルゴリズムモードによっては、認証を提供することも可能である。
しかし、否認防止とトラフィック解析からの保護は ESP によっては提供されない。
IP 認証ヘッダ (AH) は、ある認証アルゴリズムを使用すれば、否認防止を提供することが可能である [Atk95b]。
また、IP 認証ヘッダは、認証を提供する際に ESP と組み合わせて使用される可能性がある。
機密性はなくても構わないが、インテグリティと認証を望む利用者は、ESP の代わりに IP 認証ヘッダ (AH) を使用するべきである。
この文書では、読者が関連文書である "IP Security Architecture" を深く理解していることを前提としている。
その文書では、IPv4 と IPv6 のためのインターネット層のセキュリティ・アーキテクチャの全体について定義されており、この仕様の重要な背景について記述されている [Atk95a]。

1.1 概要

IP 暗号ペイロード（ESP）は、保護するべきデータを暗号化し、その暗号化されたデータを IP 暗号ペイロードのデータ部に置くことによって、機密性とインテグリティを提供しようとするものである。
この仕組みは、利用者のセキュリティ要件によって、トランスポート層セグメント（例えば、TCP、UDP、ICMP、 IGMP など）か IP データグラム全体のどちらかを暗号化して使用される。
もとのデータグラム全体に対して機密性を提供するためには、保護するデータをカプセル化することが必要である。

この仕様を利用することによって、参加システムの IP プロトコル処理にかかるコストが増え、通信の待ち時間も増加する。
この待ち時間は、主に、暗号ペイロードを含むそれぞれの IP データグラムに必要な暗号化と復号化の処理によって増加する。

トンネルモード ESP では、もとの IP データグラムは、暗号ペイロード中の暗号化されている部分に置かれ、その ESP フレーム全体は、暗号化されていない IP ヘッダを持つデータグラムの中に置かれる。
暗号化されていない IP ヘッダの情報は、送信元から宛先まで安全なデータグラムを中継するために使 用される。
IP ヘッダと暗号ペイロードとの間には、暗号化されていない IP 経路制御ヘッダ（Routing Header）が含まれる可能性がある。

トランスポートモード ESP では、ESP ヘッダは IP データグラムのトランスポート層プロトコルヘッダ（例えば、TCP、UDP や ICMP など）の直前に挿入される。
このモードでは、IP ヘッダや IP オプションヘッダが暗号化されないため、帯域が保存される。

IP の場合、IP 認証ヘッダは、暗号化されていないパケットのヘッダとして、またトランスポートモード ESP パケットの IP ヘッダの後、ESP ヘッダの前のヘッダとして、またトンネルモード ESP パケットの暗号化された部分の中のヘッダとして存在する。
AH が一つのパケットの平文の IP ヘッダの中とトンネルモード ESP ヘッダの内部の両方に存在する場合、暗号化されていない IPv6 認証ヘッダは、主に、暗号化されていない IP ヘッダの内容を保護するために使用され、暗号化された認証ヘッダは、暗号化されている IP パケットに対する認証のみを提供するために存在する。
これについては、この文書の後で詳しく議論する。

暗号ペイロードは、他の IP ペイロードと少し異なった構造をしている。
ESP ペイロードの一つ目の構成要素は、ペイロードの暗号化されていないフィールドから成り、二つ目の構成要素は、暗号化されたデータから成る。
暗号化されていない ESP ヘッダのフィールドは、暗号化されたデータの適切な復号化方法と処理方法を受信側に知らせるためにある。
暗号化されたデータ構成要素には、セキュリティ・プロトコルの保護されたフィールドと暗号化されたカプセル化 IP データグラムが含まれる。

「セキュリティ・アソシエーション」の概念は、ESP の基本となるものである。
それは関連文書の "Security Architecture for the Internet Protocol" にて詳細に記述されており、ここでは参考文献 [Atk95a] によって取り入れられる。
実装者はこの文書を読む前に、その文書を読んでおくべきである。

1.2 要求事項に関する用語

この文書では、ある特別な要求事項の重要性を明確にするために使用する単語を、通常、大文字で表記する。
これらの単語は以下の通りである。

- しなければならない（MUST）

この単語、あるいは「要求される（REQUIRED）」という形容詞は、この項目が仕様の絶対的な要求事項であることを意味する。

- する必要がある（SHOULD）

この単語、あるいは「推奨される（RECOMMENDED）」という形容詞は、ある特定の状況では、この項目を無視できるような有効な理由が存在する可能性があることを意味する。
しかし、そこに含まれている意味はすべて理解される必要があり、別の方法を取る前に、その状況を慎重に考えるべきである。

- しても良い（MAY）

この単語、あるいは「選択できる（OPTIONAL）」という形容詞は、この項目が実に選択的であることを意味する。
あるベンダは、特定の市場がそれを必要とするか、または製品の質を高めるために、この項目を取り入れようとするかもしれない。
例えば、別のベンダは同じ項目を省略するかもしれない。

2. 鍵管理

鍵管理は IP セキュリティ・アーキテクチャの重要な部分である。
しかし、鍵管理アルゴリズムとそのプロトコルの知らぬ間に作用する欠点が、長い間文献で発表されてきたことを考慮し、ある特定の鍵管理プロトコルをこの仕様に含めないこととする。
IP では、セキュリティ・プロトコルの仕組みから鍵管理の仕組みを分離することを試みる。
唯一、鍵管理プロトコルとセキュリティ・プロトコルを結ぶものが、セキュリティ・パラメータ・インデックス（SPI）であり、これについてはこの後で詳しく述べる。
このように分離をすることによって、別の鍵管理の仕組みを利用することが可能となる。
さらに重要なことは、こうすることで、セキュリティ・プロトコルの実装にあまり影響を与えることなく、鍵管理プロトコルを変更したり、修正したりすることができるようになるということである。
したがって、IP のための鍵管理プロトコルはこのメモの中では指定されない。
"IP Security Architecture" では、鍵管理についてさらに詳細に記述されており、IP のための鍵管理の要求事項について指定している。
その鍵管理の要求事項は、ここでは参考文献 [Atk95a] によって取り入れられる。

鍵管理の仕組みは、通信する組織によって使用される鍵やその他の情報（例えば、暗号アルゴリズムとそのモード、もしあればセキュリティ分類レベルなど）を含む、セキュリティ・アソシエーションの多くのパラメータをやりとりするために使用される。
鍵管理プロトコルの実装では、通常、現在使用されているセキュリティ・アソシエーションのいくつかのパラメータを含む論理表を作成し、維持する。
ESP の実装は、ESP を含むそれぞれのデータグラムをどう処理するのか（例えば、どのアルゴリズム/モードと鍵を使用するのか）を決定するために、そのセキュリティ・パラメータ表を読み込む必要がある。

3. 暗号ペイロードの構文

暗号ペイロード (ESP) は、IP ヘッダの後、最終的なトランスポート層プロトコルの前のどこに現れても良い。
Internet Assigned Numbers Authority はプロトコル番号 50 を ESP に割り当てている [STD-2]。
ESP ヘッダの直前のヘッダには、常にその次ヘッダ・フィールド (IPv6)、プロトコル・フィールド (IPv4) に値 50 が含まれる。
ESP では、暗号化されたデータの前に、暗号化されていないヘッダを含む。
暗号化されたデータには、保護された ESP ヘッダ・フィールドと、IP データグラム全体か上位層プロトコル・フレーム（例えば、TCP や UDP など）のどちらかの保護された利用者データが含まれる。
安全な IP データグラムは以下の図の通りである。

  
  |<--        暗号化されていない       -->|<--    暗号化されている   -->|
  +-------------+--------------------+------------+---------------------+
  |  IP ヘッダ  | その他の IP ヘッダ | ESP ヘッダ |  暗号化されたデータ |
  +-------------+--------------------+------------+---------------------+
   

ESP ヘッダのより詳細な図は以下の通りである

　
  +-------------+--------------------+------------+---------------------+
  |     セキュリティ・パラメータ・インデックス (SPI)、32ビット          |
  +=============+====================+============+=====================+
  |                   不透明な変換データ、 可変長                       |
  +-------------+--------------------+------------+---------------------+
   

暗号化および認証アルゴリズムと、それに関連する不透明な変換データの正確な形式は「変換（transforms）」として知られる。
ESP の形式は、将来、新規あるいは追加の暗号アルゴリズムをサポートするように、新しい変換をサポートできるように設計されている。
この変換は、この仕様の主要部ではなく、個別に指定される。
IP での利用のための必須の変換は、別の文書 [KMS95] にて定義される。
その他のオプションの変換は別の仕様書に存在し、将来、追加の変換が定義される可能性もある。

3.1 暗号ペイロードのフィールド

SPI は、そのデータグラムに対するセキュリティ・アソシエーションを識別するための 32 ビットの擬似乱数値である。
セキュリティ・アソシエーションが確立されない場合は、SPI フィールドの値は 0x00000000 となる。
SPI は、他のセキュリティ・プロトコルで使用される SAID と似ている。
ここで使用される意味が他のセキュリティ・プロトコルで使用される意味と完全に同じではないので、名称が変更されたのである。

0x00000001 から 0x000000FF までの SPI 値は、将来の利用のために、 Internet Assigned Numbers Authority (IANA) によって予約されている。
通常、予約されている SPI 値は、その個々に割り当てられた SPI 値の利用法が RFC においてオープンに指定されない限り、IANA から割り当てられない。

SPI は、唯一、変換に対して独立の必須フィールドである。
個々の変換は、その変換に特有のフィールドを他に持っても良い。
変換については、この文書では指定されない。

3.2 ESP のセキュリティラベリング

通常、SPI はセンシティビティレベルを示すので、暗号化された IP データグラムには、どのような明示的セキュリティラベルも含まれないし、含む必要もない。
これは、明示的センシティビティラベルが、通常コンパートメントモード・ワークステーションや、その他のセキュリティラベルを必要とするシステムにおいて使用されている [Ken91] [DIA] 、IPv4 の現状を改良するものである。
ある状況では、利用者は ESP によって提供される暗黙的ラベルの利用に加えて、明示的ラベルを使用しようとしても良い（MAY）（例えば、RFC-1108 によって定義される IPSO ラベルは IPv4 で使用される可能性がある）。
明示的ラベルオプションは、IPv6 での利用において定義することができる（例えば、IPv6 終点オプションヘッダ（End-to-End Options Header）か IPv6 中継点オプションヘッダ（Hop-by-Hop Options Header）を使用する）。
実装は、暗黙的ラベルに加えて明示的ラベルをサポートしても良い（MAY）が、サポートする必要はない。
マルチレベルセキュリティを提供するシステムでの ESP の実装は、暗黙的ラベルをサポートしなければならない（MUST）。

4. 暗号プロトコルの処理

この章では、通信する 2 つの組織の間で ESP が使用される場合に取られるステップについて記述する。
マルチキャストは、鍵管理の領域のみにおいてユニキャストと異なる（これに関してのさらなる詳細については、前述の SPI の定義を参照のこと）。
ESP には、2 つのモードでの利用法がある。
一つ目のモード（「トンネルモード」と呼ばれる）は、IP データグラム全体を ESP 内にカプセル化する。
二つ目のモード（「トランスポートモード」と呼ばれる）は、トランスポート層（例えば、UDP や TCP など）フレームを ESP 内にカプセル化する。
ここで「トランスポートモード」という言葉を、TCP と UDP にその利用を制限するものとして誤解してはいけない。
例えば、場合によっては ICMP メッセージを「トランスポートモード」か「トンネルモード」のどちらかを利用して送っても良い（MAY）。
また、ESP の処理は、出力時には IP 分割の前に、入力時には IP 再構成の後に行なわれる。
この章では、これらの 2 つのモードのそれぞれでのプロトコル処理について記述する。

4.1 トンネルモードでの ESP

トンネルモード ESP では、ESP ヘッダは、すべての終点間ヘッダ（end-to-end header）（例えば、もし平文で存在するならば認証ヘッダも含む）の後に続き、トンネルを通る IP データグラムの直前に存在する。

送信側は、もとの IP データグラムを取り、それを正確なセキュリティ・アソシエーションを位置付けるためのデータとして少なくとも送信側の利用者 ID と宛先アドレスを利用して、ESP 内へカプセル化する。
そして、適切な暗号化変換を適用する。
ホスト別鍵管理を使用している場合は、与えられたシステム上のすべての送信側利用者 ID は、与えられた宛先アドレスに対して同じセキュリティ・アソシエーションを持つ。
鍵が確立されていない場合は、ESP を利用する前に、この通信セッションにおける暗号化鍵を確立するための鍵管理の仕組みが利用される。
そして（現在暗号化されている）ESP は、最終のペイロードとして平文の IP データグラムにカプセル化される。
厳密な red/black 分離がされている場合は、平文の IP ヘッダやオプションペイロード中のアドレス構造などの情報は、（現在、暗号化されてカプセル化されている）もとのデータグラムに含まれている値と異なっていても良い（MAY）。

受信側は、平文の IP ヘッダと平文のオプション IP ペイロード（もしあるならば）をすべて取り去り、それらを破棄する。
そして、このパケットで使用される正しいセッション鍵を位置付けるために、宛先アドレスと SPI 値の組み合せを使用する。
そして、先程このパケットに位置付けられたセッション鍵を使用して ESP を復号化する。

このセッションに対して有効なセキュリティ・アソシエーションが存在しない場合は（例えば、受信者がどの鍵も持たない場合）、受信側は暗号化された ESP を破棄しなければならない（MUST）。
そして、その失敗をシステムログ、または監査ログに記録しなければならない（MUST）。
このシステムログまたは監査ログエントリには、SPI 値、日付/時間、平文の送信元アドレス、平文の宛先アドレス、および平文のフロー ID が含まれる必要がある（SHOULD）。
そのログエントリには、別の識別用データが含まれても良い（MAY）。
受信者は、容易に搾取できるサービス妨害攻撃の可能性が大いにあるために、この失敗を送信側にすぐに知らせようとはしないかもしれない。

復号化が成功した場合は、もとの IP データグラムは（現在、復号化された） ESP から取り出される。
そして、そのもとの IP データグラムが通常の IP プロトコルの仕様によって処理される。
マルチレベルセキュリティを提供するシステムの場合（例えば、B1 やコンパートメントモード・ワークステーションなど）は、受信プロセスのセキュリティレベルと、このセキュリティ・アソシエーションのセキュリティレベルに基づいて、追加の適切な強制アクセス制御が適用されなければならない（MUST）。
もし、強制アクセス制御が失敗したならば、そのパケットを破棄する必要があり（SHOULD）、その失敗を実装特有の処理手順によって記録する必要がある（SHOULD）。

4.2 トランスポートモードでの ESP

トランスポートモード ESP では、ESP ヘッダは、すべての終点間ヘッダ（end-to-end header）（例えば、認証ヘッダなど）の後に続き、トランスポート層（例えば、UDP、TCP、ICMP など）ヘッダの直前に存在する。

送信側は、もとのトランスポート層（例えば、UDP、TCP、ICMP など）フレームを取り、それを ESP 内にカプセル化し、適切なセキュリティ・アソシエーションを位置付けるために、少なくとも送信側の利用者 ID と宛先アドレスを利用し、そして、適切な暗号化変換を適用する。
ホスト別鍵管理を使用している場合は、与えられたシステム上のすべての送信側利用者 ID は、与えられた宛先アドレスに対して同じセキュリティ・アソシエーションを持つ。
鍵が確立されていないならば、この通信セッションに対する暗号化鍵を確立するために、暗号化の前に鍵管理の仕組みが使用される。
そして、（現在暗号化されている） ESP は、平文の IP データグラムの最終のペイロードとしてカプセル化される。

受信側は、平文の IP ヘッダと平文のオプション IP ペイロード（もしあるならば）を処理し、一時的に該当情報（例えば、送信元アドレスや宛先アドレス、フロー ID、経路制御ヘッダなど）を格納する。
そして、このトラフィックに対して確立されたセッション鍵を使用して ESP を復号化する。
正しい鍵を位置づけるために、宛先アドレスとそのパケットのセキュリティ・アソシエーション識別子（SPI）の組み合わせを使用する。

このセッションに対して鍵が存在しないか、または復号化の試みが失敗した場合は、その暗号化された ESP は破棄されなければならず（MUST）、その失敗をシステムログまたは監査ログに記録しなければならない（MUST）。
そのような失敗が起こった場合には、記録されるログデータには、SPI 値、受け取った日付/時間、平文の送信元アドレス、平文の宛先アドレス、およびフロー ID が含まれる必要がある（SHOULD）。
ログデータには、その他の失敗したパケットに関する情報が含まれても良い（MUST）。
復号化の処理が何らかの理由で適切に動作しない場合には、その結果のデータは実装されたプロトコルエンジンによって分割できない。
したがって、復号化の失敗は一般に検出できる。

復号化が成功した場合は、もとのトランスポート層（例えば、UDP、TCP、ICMP など）フレームが、（現在、復号化された）ESP から取り出される。
平文の IP ヘッダと、先程復号化されたトランスポート層ヘッダの情報は、データがどのアプリケーションに送られるべきかを決定するために組み合わせて使用される。
そして、データは通常の IP プロトコルの仕様に沿って適切なアプリケーションに送られる。
マルチレベルセキュリティを提供するシステムの場合（例えば、B1 やコンパートメントモード・ワークステーションなど）には、追加の強制アクセス制御が、受信プロセスのセキュリティレベルと受信パケットのセキュリティ・アソシエーションのセキュリティレベルに基づいて、適用されなければならない（MUST）。

4.3. 認証

いくつかの変換では、機密性やインテグリティと同時に認証も提供する。
このような変換を使用しない場合には、暗号ペイロードと共に認証ヘッダを使用することができる。
ESP と共に認証ヘッダを使用する方法には、どのデータを認証するのかによって、2 つの利用法が存在する。
認証ヘッダの位置によって、どのデータセットが認証されているのかが明らかになる。

一つ目の利用法では、暗号化された部分と暗号化されていない部分の両方を含む受信データグラム全体が認証され、ESP ヘッダの後ろのデータのみが機密となる。
この利用法では、送信側は最初に ESP を保護するべきデータに適用する。
そして、別の平文の IP ヘッダが ESP ヘッダと先程暗号化されたデータに付与される。
そして最後に IP 認証ヘッダが、その結果生じたデータグラムに対して通常の方法で計算される。
受信時には、受信側は最初に、通常の IP 認証ヘッダの処理を使用して、データグラム全体の認証性を確認する。
認証が成功した場合、通常の IP ESP の処理を使用して復号化される。
復号化が成功した場合、その結果生じたデータが上位層まで渡される。

認証の処理がトンネルモード ESP によって保護されたデータだけに適用される場合、通常、IP 認証ヘッダはその保護されたデータグラムの中に置かれる。
しかし、トランスポートモード ESP が使用される場合には、IP 認証ヘッダは、 ESP ヘッダの前に置かれ、IP データグラム全体に対して計算される。

認証ヘッダがトンネルモード ESP ヘッダの中にカプセル化され、両方のヘッダがそれらに関連付けられた固有のセキュリティ分類レベルを持っており、その 2 つのセキュリティ分類レベルが異なる場合には、エラーが発生する。
エラーは、前記の手順によって、システムログか監査ログに記録される必要がある（SHOULD）。
認証ヘッダが ESP の外側に存在し、それが ESP ヘッダのセキュリティ分類レベルと異なる分類レベルを持つ場合には、エラーの必要はない。
データが ESP を使用して暗号化された後に、平文の IP ヘッダが異なる分類レベルを持つ可能性があるので、これは有効であるかもしれない。

5. 準拠に関する要求事項

この仕様に準拠するすべての実装は、ここで記述されたヘッダを完全に実装し（MUST）、このヘッダにおける手動鍵配布をサポートし（MUST）、"Security Architecture for the Internet Protocol" [Atk95a] のすべての要求条件に準じ（MUST）、"The ESP DES-CBC Transform" [KMS95] と題された関連文書で指定される DES-CBC の利用をサポートしなければならない（MUST）。
実装者は、他の ESP 変換を実装しても良い（MAY）。
実装者は、この文書のステータスについてさらに知るためには "IAB Official Standards" RFC の最新版を調べるべきである。

6. セキュリティに関する考慮事項

この文書の全体では、IP での利用におけるセキュリティの仕組みについて議論している。
この仕組みは万能ではないが、安全なインターネットワークを構築する際に役に立つ重要な構成要素を提供する。

ブロック連鎖アルゴリズムを使用し、強いインテグリティの仕組みを持たない ESP の暗号変換は、Bellovin によって記述されているカットアンドペースト攻撃に弱く、ESP 変換を使用するパケットで常に認証ヘッダが使用されていないのであれば、その変換は使用するべきではない [Bel95]。

利用者は、この仕様によって提供されるセキュリティの品質は、完全に、実装される暗号化アルゴリズムの強度、そのアルゴリズムの実装の正確さ、鍵管理の仕組みとその実装のセキュリティ、鍵の強度 [CN94] [Sch94, p233]、そして、すべての参加ノードにおける ESP と IP の実装の正確さに依存しているということを理解する必要がある。

これらの仮定のいずれかが守れない場合は、本当のセキュリティは全く利用者には提供されない。
高度な保証開発技法の使用が、IP 暗号ペイロードに望まれる。

トラフィック解析からの保護を求める利用者は、適切なリンク暗号化の利用を検討するかもしれない。
リンク暗号化についての説明と仕様については、このノートの範囲外である。

利用者別鍵管理が利用されていない状況では、使用するアルゴリズムはどのような種類の選択平文攻撃に対しても弱いアルゴリズムであってはならない。
DES に対する選択平文攻撃は、[BS93] と [Mat94] にて記述されている。
利用者別鍵管理は、どのような種類の選択平文攻撃をも排除し、一般に暗号解析をより難しくするため、その利用が推奨される。
実装は、"IP Security Architecture" [Atk95a] にて記述されている、利用者別鍵管理をサポートする必要がある（SHOULD）。

謝辞

この文書は、もともとは SIP、SIPP、最終的には IPv6 の著者によって定義された手法を一般化するために Bill Simpson、Perry Metzger、そして Phil Karn によってなされた成果から大いに利益を得た。

ここの概念の多くは、アメリカ政府の SP3 セキュリティ・プロトコルの仕様、 ISO/IEC の NLSP の仕様、また、提案された swIPe セキュリティ・プロトコルから得られ、影響を及ぼされたものである [SDNS89, ISO92a, IB93, IBK93, ISO92b]。
機密性のための DES の使用は、SNMPv2 [GM93] のためになされた成果をかなりの部分においてモデルとしている。
Steve Bellovin、Steve Deering、 Dave Mihelcic、そして Hilarie Orman からは、このメモの初期のバージョンにおいて役に立つ批評を頂いた。

参考文献

[Atk95a] Atkinson, R., "Security Architecture for the Internet Protocol", RFC 1825, NRL, August 1995.

[Atk95b] Atkinson, R., "IP Authentication Header", RFC 1826, NRL, August 1995.

[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.

[BS93] Eli Biham and Adi Shamir, "Differential Cryptanalysis of the Data Encryption Standard", Springer-Verlag, New York, NY, 1993.

[CN94] John M. Carroll & Sri Nudiati, "On Weak Keys and Weak Data: Foiling the Two Nemeses", Cryptologia, Vol. 18, No. 23, July 1994. pp. 253-280

[CERT95] Computer Emergency Response Team (CERT), "IP Spoofing Attacks and Hijacked Terminal Connections", CA-95:01, January 1995. Available via anonymous ftp from info.cert.org.

[DIA] US Defense Intelligence Agency (DIA), "Compartmented Mode Workstation Specification", Technical Report DDS-2600-6243-87.

[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.

[Hin94] Bob Hinden (Editor), Internet Protocol version 6 (IPv6) Specification, Work in Progress, October 1994.

[IB93] John Ioannidis & Matt Blaze, "Architecture and Implementation of Network-layer Security Under Unix", Proceedings of the 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.

[ISO92a] ISO/IEC JTC1/SC6, Network Layer Security Protocol, ISO-IEC DIS 11577, International Standards Organisation, Geneva, Switzerland, 29 November 1992.

[ISO92b] ISO/IEC JTC1/SC6, Network Layer Security Protocol, ISO-IEC DIS 11577, Section 13.4.1, page 33, International Standards Organisation, Geneva, Switzerland, 29 November 1992.

[Ken91] Kent, S., "US DoD Security Options for the Internet Protocol", RFC 1108, BBN Communications, November 1991.

[KMS95] Karn, P., Metzger, P., and W. Simpson, "The ESP DES-CBC Transform", RFC 1829, Qualcomm, Inc., Piermont, Daydreamer, August 1995.

[Mat94] Matsui, M., "Linear Cryptanalysis method for DES Cipher", Proceedings of Eurocrypt '93, Berlin, Springer-Verlag, 1994.

[NIST77] US National Bureau of Standards, "Data Encryption Standard", Federal Information Processing Standard (FIPS) Publication 46, January 1977.

[NIST80] US National Bureau of Standards, "DES Modes of Operation" Federal Information Processing Standard (FIPS) Publication 81, December 1980.

[NIST81] US National Bureau of Standards, "Guidelines for Implementing and Using the Data Encryption Standard", Federal Information Processing Standard (FIPS) Publication 74, April 1981.

[NIST88] US National Bureau of Standards, "Data Encryption Standard", Federal Information Processing Standard (FIPS) Publication 46-1, January 1988.

[STD-2] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700, USC/Information Sciences Institute, October 1994.

[Sch94] Bruce Schneier, Applied Cryptography, John Wiley & Sons, New York, NY, 1994. ISBN 0-471-59756-2

[SDNS89] SDNS Secure Data Network System, Security Protocol 3, SP3, Document SDN.301, Revision 1.5, 15 May 1989, as published in NIST Publication NIST-IR-90-4250, February 1990.

否認事項

この見解と仕様は著者によるものであり、必ずしもその雇い主によるものではない。
Naval Research Laboratory は、この成果の（もしあるならば）メリットにおける判断を下していない。
著者とその雇い主は、特に、正確/不正確な実装、および、この仕様の利用から生じるどのような問題への責任も放棄する。

著者の連絡先

Randall Atkinson
Information Technology Division
Naval Research Laboratory
Washington, DC 20375-5320
USA

Phone: (202) 404-7090
Fax: (202) 404-7942
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.