ネットワークワーキンググループ
Request for Comments: 1826
分類: スタンダードトラック

R. Atkinson
Naval Research Laboratory

1995年8月

IP 認証ヘッダ
(IP Authentication Header)

このメモの位置付け

この文書は、インターネットコミュニティに対してインターネットスタンダードトラックのプロトコルを規定するとともに、それを改良するための議論や提言を求めるものである。
このプロトコルの標準化状態、およびステータスについては、"Internet Official Protocol Standards" (STD 1) の最新版を参照すること。
このメモの配布に制限はない。
要旨
この文書では、IPv4 および IPv6 データグラムに暗号的な認証を提供するための仕組みについて記述する。
認証ヘッダ(Authentication Header:AH)は、通常 IP ヘッダの後、それ以外の認証される情報の前に挿入される。
1. はじめに
認証ヘッダは、IP データグラムに強力なインテグリティと認証を提供するための仕組みである。
それは使用する暗号アルゴリズム、鍵管理の方法によっては、否認防止を提供することも可能である。
例えば、RSA のような非対称デジタル署名アルゴリズムを使用することによって、否認防止を提供することが可能となる。

機密性とトラフィック解析からの保護は、認証ヘッダによっては提供されない。
機密性を望む利用者は、認証ヘッダの代わりに、あるいは認証ヘッダと組み合わせて IP 暗号ペイロード(ESP)を使用することを検討するべきである [Atk95b]
この文書では、読者が事前に関連文書の "IP Security Architecture" を読んでいることを前提としている。
その文書では、IP のためのセキュリティアーキテクチャの全体について定義されており、この仕様の重要な背景について記述されている [Atk95a]

1.1 概要
IP 認証ヘッダは、IP データグラムに認証情報を加えることによってセキュリティを提供しようとするものである。
この認証情報は、IP データグラムの配送中に変更されないフィールドのすべてを使用して計算される(IP ヘッダだけではなく、他のヘッダや利用者データも含まれる)。
配送中に変更される必要があるフィールドやオプション(例えば、「中継点数(hop count)」「TTL(time to live)」「識別子(ident)」「断片オフセット(fragment offset)」や「経路制御ポインタ(routing pointer)」など)は、認証データの計算の際に、ゼロであるとみなされる。
認証ヘッダは、現在の IPv4 に存在するものよりも強力なセキュリティを提供するものであり、その強度は多くの利用者の要求に対して十分なものであるかもしれない。

この仕様を利用することによって、認証に参加する終端システムの IP プロトコル処理にかかるコストが増え、通信の待ち時間も増加する。
この待ち時間は、主に、認証ヘッダを含むそれぞれの IP データグラムに対する送信側での認証データの計算にかかる時間と、受信側での認証データの計算およびその比較にかかる時間によって増加する。
その影響は、使用する認証アルゴリズムやその他の要素によって変化する。

インターネットの通信基盤全体を変更することなく、認証ヘッダが正確に動作するように、認証データはそれ自身のペイロードの中で運ばれる。
認証に参加しないシステムは、この認証データを無視しても良い(MAY)。
IPv6 で使用する場合は、認証ヘッダは通常、断片ヘッダ(Fragmentation header)や終点間ヘッダ(End-to-End headers)の後、ESP ヘッダやトランスポート層ヘッダの前に置かれる。
認証ヘッダ以外の IP ヘッダの情報は、送信元から宛先までデータグラムを中継するために使用される。
IPv4 で使用する場合は、認証ヘッダは IPv4 ヘッダのすぐ後に続く。

対称認証アルゴリズムが使用されていて、中間での認証が求められる場合、その中間で認証するノードには、適切な鍵が提供されている必要がある。
しかし、この鍵を所有するシステムは、正当な送信者から正当な受信者までのトラフィックを偽造したり、正当なトラフィックの内容を改ざんしたりすることができてしまう。
ある環境では、このような中間での認証が求められるかもしれない [BCCH94]
非対称認証アルゴリズムが使用されていて、ルータが適切な公開鍵と認証アルゴリズムを知っている場合、その認証用公開鍵を所有しているルータは、正当なトラフィックの偽造や改ざんはできないが、扱われるトラフィックを認証することができる。
また、IPv4 の場合で、認証ヘッダの中間での認証が求めらる場合には、この方法ではパケットの断片を認証することができないため、経路 MTU 探索が使用されなければならない(MUST)。

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

- しなければならない(MUST)

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

- する必要がある(SHOULD)

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

- しても良い(MAY)

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

2. 鍵管理
鍵管理は IP セキュリティアーキテクチャの重要な部分である。
しかし、鍵管理アルゴリズムとそのプロトコルの知らぬ間に作用する欠点が、長い間文献で発表されてきたことを考慮し、鍵管理はこの仕様に統合しないこととする。
IP 認証ヘッダでは、セキュリティプロトコルの仕組みから鍵管理の仕組みを分離することを試みる。
唯一、鍵管理プロトコルとセキュリティプロトコルを結ぶものが、セキュリティパラメータインデックス(SPI)であり、これについてはこの後で詳しく述べる。
このように分離をすることによって、別の鍵管理の仕組みを利用することが可能となる。
さらに重要なことは、こうすることで、セキュリティプロトコルの実装にあまり影響を与えることなく、鍵管理プロトコルを変更したり、修正したりすることができるようになるということである。

鍵管理の仕組みは、通信する組織によって使用される鍵やその他の情報(例えば、認証アルゴリズムとそのモードなど)を含む「セキュリティアソシエーション」の多くのパラメータをやりとりするために使用される。
鍵管理の仕組みでは、現在使用されているセキュリティアソシエーションのいくつかのパラメータを含む論理表を作成し、維持する。
IP 認証ヘッダの実装は、認証ヘッダを含むそれぞれのデータグラムをどう処理するのかを決定するために(例えば、どのアルゴリズム/モードと鍵を使用するのかを決定する)、このセキュリティパラメータの論理表を読み込む必要がある。

セキュリティアソシエーションは単方向である。
通常、両方向の通信セッションは各方向に 1 つずつのセキュリティアソシエーションを持つ。
例えば、 2 つのシステム A と B の間に TCP セッションが存在する場合は、通常、A から B へのセキュリティアソシエーションと、B から A への別のセキュリティアソシエーションが存在する。
受信側は、送信側が利用するセキュリティアソシエーションに対して SPI 値を割り当てる。
その他のセキュリティアソシエーションのパラメータは、鍵管理の仕組みで指定される方法で決定される。
この文書の第4章では、送出パケットに対するセキュリティアソシエーションの選択と、到来パケットに対するセキュリティアソシエーションの識別の過程について詳細に記述する。

鍵管理については、"IP Security Architecture" の文書に詳細に記述されている。
その文書では、このプロトコルに対する鍵管理の要求事項について指定されており、ここでは参考文献 [Atk95a] によって取り入れられる。

3. 認証ヘッダの構文
認証ヘッダ(AH)は、各中継点で調べられるヘッダの後、中間中継点で調べられることのないヘッダの前のどこに現れても良い。
認証ヘッダの直前の IPv6 または IPv4 ヘッダには、その次ヘッダ(または、プロトコル)フィールドに、値 51 が含まれる [STD-2]

認証ヘッダを含む IP データグラムの例は、以下の図の通りである。

  
  +------------+-------------------+------------+-------+---------------+
  | IPv6 ヘッダ| 中継点 / 経路制御 | 認証ヘッダ | その他| 上位プロトコル|
  +------------+-------------------+------------+-------+---------------+
図 1: IPv6 での例

IPv6 で使用される場合、通常、認証ヘッダは IPv6 中継点ヘッダ(Hop-by-Hop Header)の後、IPv6 終点オプションヘッダ(Destination Options)の前に現れる。

  
  +-------------+--------------+-------------------------------+
  | IPv4 ヘッダ |  認証ヘッダ  |上位プロトコル(例えば,TCP,UDP)|
  +-------------+--------------+-------------------------------+
図 2: IPv4 での例

IPv4 で使用される場合、通常、認証ヘッダは IPv4 基本ヘッダの後に続く。

3.1 認証ヘッダの構文
認証データは、IP データグラム全体に渡って計算された認証アルゴリズムの出力である。
これについてはこの文書の後でさらに詳細に記述する。
認証計算の際には、認証データフィールド自身と、通常、配送中に変更されるすべてのフィールド(例えば、TTL や中継限界数(Hop Limit)など)を、それらのフィールドにはすべてゼロが含まれているとして扱わなければならない。
通常、認証ヘッダのその他のフィールドはすべて、認証計算に含まれる。

IP 認証ヘッダの構文は、以下の通りである。

  +---------------+---------------+---------------+---------------+
  |    次ヘッダ   |     長さ      |              予約             |
  +---------------+---------------+---------------+---------------+
  |             セキュリティパラメータインデックス            |
  +---------------+---------------+---------------+---------------+
  |                                                               |
  +              認証データ(32 ビットワードでの変数)          |
  |                                                               |
  +---------------+---------------+---------------+---------------+
  1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8
図 3: 認証ヘッダの構文
3.2 認証ヘッダのフィールド

次ヘッダ
8 ビットの幅。
認証ペイロードの後の次ペイロードを識別する。
このフィールドの値は、Internet Assigned Numbers Authority (IANA) による最新の RFC "Assigned Numbers" [STD-2] に記述されている IP プロトコル番号である。

ペイロード長
8 ビットの幅。
32 ビットワードでの認証データフィールドの長さ。
最小値は 0 ワードであり、この場合は認証アルゴリズムが「null」で、認証データが生成されない場合のみに使用される。

予約
16 ビットの幅。
将来の利用のために予約されている。
送信時には、すべてゼロに設定されていなければならない(MUST)。
この値は、認証データの計算に含まれるが、受信側では無視される。

セキュリティパラメータインデックス(SPI)
このデータグラムに対するセキュリティアソシエーションを識別するための 32 ビットの擬似乱数値。
セキュリティパラメータインデックス値 0 は、「どのようなセキュリティアソシエーションも存在しない」ことを示すために予約されている。

1 から 255 までのセキュリティパラメータインデックス値は、将来の利用のために、Internet Assigned Numbers Authority (IANA) によって予約されている。
この予約された SPI 値は、通常、その割り当てられる SPI 値の利用法が RFC でオープンに指定されない限り、IANA によって割り当てられることはない。

認証データ
このフィールドの長さは可変であるが、必ず 32 ビットワードでの整数となる。

多くの実装では、性能を向上させる目的で 64 ビット毎などに整列させるためにパディングが必要となる。
すべての実装は、そのような SPI 毎の宛先によって指定されるパディングをサポートしなければならない(MUST)。
パディングフィールドの値は送信側によって任意に選択され、認証データの計算に含まれる。

通常、実装は、フィールドの長さとその利用を指定するセキュリティアソシエーションを位置付けるために、宛先アドレスと SPI の組合せを使用する。
このフィールドは、与えられた SPI と宛先アドレスの組が同じすべてのデータグラムでは同じ形式となる。

認証データによって、SPI フィールドのすぐ後から始まるフィールドが満たされる。
このフィールドの大きさが実際の認証データを格納するために必要な長さよりも長い場合は、その未使用のビットはここでは指定されない実装に依存した値で満たされる。

このフィールドの内容に関するさらなる情報については、それぞれの認証変換の仕様を参照すること。

3.3 センシティビティラベリング
"IP Security Architecture" の文書で、より詳細に議論されているように、 IPv6 では通常、現在 IPv4 で使用されている明示的セキュリティラベルではなく暗黙的ラベルを使用する [Ken91] [Atk95a]
ある状況では、利用者は認証ヘッダによって提供される暗黙的ラベルの使用に加えて、明示的ラベルを使用しても良い(MAY)(例えば、RFC-1108 で定義される IPSO ラベルは IPv4 で使用することができる)。
明示的ラベルオプションは、IPv6 での使用において定義することができる(例えば IPv6 終点間オプションヘッダ(end-to-end options header)や IPv6 中継点オプションヘッダ(hop-by-hop options header)を利用する)。
実装は、暗黙的ラベルに加えて明示的ラベルをサポートしても良い(MAY)が、サポートする必要はない。
明示的ラベルを使用する場合、その明示的ラベルは認証計算に含まれなければならない(MUST)。
4. 認証データの計算
IP 認証ヘッダによって運ばれる認証データは、通常、メッセージダイジェストアルゴリズム(例えば、MD5 など)を使用し、そのメッセージダイジェストを暗号化するか、または直接メッセージダイジェストに鍵が組み合わせられるかして計算される [Riv92]
IP 認証ヘッダでは、暗号的に強固な一方向性関数であると信じられるアルゴリズムのみを使用しなければならない。

従来のチェックサム(例えば、CRC-16 など)は、暗号的に強くないので、認証ヘッダでは使用してはならない(MUST NOT)。

送出 IP パケットの認証処理の際に、送信側のシステムが最初にすることは適切なセキュリティアソシエーションを位置付けることである。
すべてのセキュリティアソシエーションは単方向である。
送出 IP パケットに対するセキュリティアソシエーションは、少なくとも送信側の利用者 ID と宛先アドレスに基づいて適切に選択される。
ホスト別鍵管理が使用されている場合は、送信側のすべての利用者 ID は、与えられた宛先に対して同じセキュリティアソシエーションを共有する。
利用者別鍵管理が使用されている場合は、異なる利用者、あるいは、おそらく同じ利用者の異なるアプリケーションでも、異なるセキュリティアソシエーションを使用することができる。
選択されたセキュリティアソシエーションによって、送出パケットにどのようなアルゴリズム、アルゴリズムモード、鍵、そしてその他のセキュリティ特性を適用するのかということが示される。

送信側から受信側への配送中に変更される必要があり(例えば、IPv4 の TTL やヘッダチェックサム、あるいは、IPv6 の中継限界数)、受信側に現れる際のその値が送信側に確信を持って知られていないフィールドは、認証データの計算に含まれるが、特別に処理される。
配送中に変更されるこれらのフィールドは、認証データの計算の際に IP パケット中で運ばれるその値がゼロに置き換えられる。
フィールドを省略することはせず、代わりにその値をゼロに置き換えることによって、フィールドが整列した状態を認証計算の際に保つことができる。

送信側は、それが受信側に現れる状態のパケット全体に渡って認証計算をしなければならない(MUST)。
この要求条件は、受信側はパケットにそのようなオプションが含まれているのかどうかについて知らないかもしれないが、送信側は必然的に知っているような、将来の IP オプションヘッダを許すために存在する。
これはまた、配送中に変更されるが、最終的な受信側における値があらかじめ送信側によって確実に知られているようなデータの認証を可能にする。

送信側は、計算されたメッセージダイジェストアルゴリズムの出力を認証ヘッダの認証データフィールドに置く。
認証データの計算の際には、この認証データフィールドはゼロで満たされているとみなされる。

IPv4 の「TTL」と「ヘッダチェックサム」フィールドは、IPv4 基本ヘッダ中で認証データの計算の際に特別に処理される唯一のフィールドである。
分割されたパケットは、ローカルの IP 認証ヘッダの実装の処理の「前に」再構成される。
「継続(more)」ビットは、再構成の際にもちろんクリアされるので、 IP 認証ヘッダの実装からは、IPv4 ヘッダの他のどのフィールドも配送中に変更されていないように見える。
IPv4 基本ヘッダの「TTL」と「ヘッダチェックサム」フィールドは、認証データの計算の際にすべてゼロに設定されなければならない(MUST)。
IPv4 基本ヘッダの他のすべてのフィールドは、通常通り、実際の内容で処理される。
IPv4 パケットはルータによって中間で分割されることがありるため、IPv4 パケットの再構成は認証ヘッダ処理の前に行なわれることが重要である。
IP 認証ヘッダが使用される場合、IPv4 の実装は経路 MTU 探索を使用する必要がある(SHOULD)[MD90]
IPv4 では、すべてのオプションが RFC でオープンに指定されるわけではないので、通常、配送中に変更される可能性のあるオプションのすべてを、この文書で列挙することはできない。
IP セキュリティオプション (IPSO) が IP データグラム中に存在する場合は、常に、そのオプションを認証データの計算に含めなければならない(MUST)[Ken91]
受信システムが、IPv4 パケット中のオプションを認識できない場合には、そのオプションは認証データの計算の際に含まれる。
これは、送信側に予測できない方法で配送中に変更され、受信側に認識できないような IPv4 オプションを含む IPv4 パケットはすべて認証チェックに失敗し、その結果、受信側によって破棄されることを意味する。

IPv6 の「中継限界数」フィールドは、IPv6 基本ヘッダ中で認証データの計算の際に特別に処理される唯一のフィールドである。
その中継限界数フィールドの値は、認証データの計算の際にゼロにされる。
IPv6 基本ヘッダの他のすべてのフィールドは、通常の認証データの計算の手順に従って、認証データの計算に含めなければならない(MUST)。
すべての IPv6 の「オプション番号」値には、そのオプションデータを認証データの計算に含めるのかどうかを決定するために使用しなければならない(MUST)ビットが含まれる。
このビットは、 IPv6 オプション番号フィールドの上から 3 番目のビットである。
このビットがゼロに設定された場合、それに対応するオプションは、認証データの計算に使用される。
このビットが 1 に設定された場合、それに対応するオプションは、認証データの計算の際にオプションと同じ長さのすべてゼロのビット列に置き換えられる。
「タイプ 0」の IPv6 経路制御ヘッダでは、送信元から宛先への配送中に、そのパケット中のアドレスフィールドが再配列される。
しかしながら、受信側に現れるこのパケットの内容は、送信側とすべての中間中継点に知られているので、これは問題ではない。
したがって、「タイプ 0」の IPv6 経路制御ヘッダは、通常の手順に従って認証データの計算に含まれる。

受信側は、IP 認証ヘッダを含むパケットを受信する際、最初に正しいセキュリティアソシエーションを位置付けるために、宛先アドレスと SPI 値を使用する。
そして、受信側は、認証データフィールドと受信データパケットが一致することを独自に確認する。
ここで、認証データフィールドは認証計算を行なう際に再びゼロであるとみなされる。
この処理の方法は、アルゴリズムに依存する。
認証アルゴリズムの処理によって、データグラムが有効であることが示された場合、そのデータグラムは受け取られる。
アルゴリズムによって、データと認証ヘッダが完全に一致しないと判断された場合、受信側は受け取った IP データグラムを無効であるとして破棄する必要があり(SHOULD)、その認証の失敗を、システムログか監査ログに記録しなければならない(MUST)。
このような失敗が起こった場合、記録されるログデータには、SPI 値、受信日時、平文の送信元アドレス、平文の宛先アドレス、そして(存在するならば)平文のフロー ID が含まれなければならない(MUST)。
また、ログデータにはその他の失敗したパケットに関する情報も含めても良い(MAY)。

5. 準拠に関する要求事項
この仕様に準拠するすべての実装は、ここで記述されたヘッダを完全に実装し(MUST)、オプションとして使用できるように手動鍵配布をサポートし(MUST)、"Security Architecture for the Internet Protocol" [Atk95a] のすべての要求事項に準じ(MUST)、"IP Authentication using MD5" [MS95] と題された関連文書にて記述される鍵付 MD5 の利用をサポートしなければならない(MUST)。
また、実装者はその他の認証アルゴリズムを実装しても良い(MAY)。
実装者はこの文書のステータスについてのさらなる情報を得るために、"IAB Official Standards" RFC の最新のバージョンを調べるべきである。
6. セキュリティに関する考慮事項
この RFC の全体では、IP における認証の仕組みについて議論している。
この仕組みは、インターネットワークにおけるセキュリティの問題を解決するような万能なものではないが、安全なインターネットワークを構築する際に役に立つ重要な要素を提供するものである。

利用者は、この仕様によって提供されるセキュリティの品質は、完全に、実装する暗号アルゴリズムの強度、使用する鍵の強度、アルゴリズムの実装の正確さ、鍵管理の仕組みとその実装のセキュリティ、そして、すべての参加ノードにおける IP 認証ヘッダと IP の実装の正確さに依存しているということを理解する必要がある。
これらの仮定のいずれかが守られない場合には、本当のセキュリティは利用者には全く提供されない。
実装者は、製品のセキュリティに関するすべての部分を開発する際に、高い保証技法を利用することが望ましい。

機密性に関心がある利用者は、この仕様の代わりに、またはこの仕様と組み合わせて、IP 暗号ペイロード(ESP)を使用することを検討するべきである [Atk95b]
トラフィック解析からの保護を求める利用者は、適切なリンク暗号化の利用を検討することができる。
リンク暗号化についての記述と仕様については、このノートの範囲外である。
IP 認証ヘッダに IP 暗号ペイロードを組み合わせて使用することに関心がある利用者は、その詳細について IP 暗号ペイロードの仕様を調べるべきである。

ある状況では、ICMP によって報告を返す必要のあるエラーを起こしたパケットの大きさが、返される ICMP メッセージに完全に納まらないほど大きいことがあるという問題がある。
このような場合、ICMP メッセージの受信者は返されたメッセージの一部を独自に認証することができないかもしれない。
これは、このような ICMP メッセージを受け取るホストが、今度はそれが何らかのセキュリティ問題を引き起こすかもしれない認証されていない ICMP メッセージを信じるか、あるいは信じないために反応すべき正当な ICMP メッセージにも適切に反応できなくなってしまうかのどちらかとなるということを意味している。
最小の IP MTU 以上のサイズのパケットの存在に対して、この問題を完全に解決することができるのかどうかは明らかでない。
暗号化されたパケットが、送信される ICMP エラーメッセージを引き起こし、そのパケットが省略されてしまう場合も同様の問題が発生する。

インターネットには、能動的な攻撃が存在することが現在広く知られている [CER95]
能動的な攻撃が存在するということは、認証されていない指定経路制御は、それが単方向(受信専用)であるにしろ、もとの受け取った指定経路に従って応答するにしろ、受信された指定経路制御されているパケットのすべてが IP 認証ヘッダや他の暗号の仕組みを利用して認証されていないのであれば、重大なセキュリティリスクを引き起こす代表的な存在となることを意味している。
[CER95] に記述されている攻撃が、[Bel89] に記述されているもののサブセットを含むということは注目に値することである。

AH と共に IP トンネルを利用する場合、AH 処理を実行する可能性のある終点の組が複数作られることになる。
実装者と管理者は、受信トンネルパケットの認証に対してのトンネル化の影響について慎重に考慮するべきである。

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

ここの基本概念は、[GM93] に記述されている SNMPv2 セキュリティプロトコルの成果から大部分を得た。
Steve Bellovin、Steve Deering、Frank Kastenholz、Dave Mihelcic、そして Hilarie Orman からは、このノートの初期のバージョンにおいて思慮深い批評を頂いた。
Francis Dupont は、上記にて注記された低 IP MTU リンクにおける ICMP のセキュリティ上の問題を発見し、指摘して頂いた。

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

[Atk95b] Atkinson, R., "IP Encapsulating Security Payload", RFC 1827, 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.

[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, pp. 21-34.

[CER95] 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 in /pub/cert_advisories.

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

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

[Kno93] Knowles, Stev, "IESG Advice from Experience with Path MTU Discovery", RFC 1435, FTP Software, March 1993.

[MS95] Metzger, P., and W. Simpson, "IP Authentication with Keyed MD5", RFC 1828, Piermont, Daydreamer, August 1995.

[MD90] Mogul, J., and S. Deering, "Path MTU Discovery", RFC 1191, DECWRL, Stanford University, November 1990.

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

[Riv92] Rivest, R., "MD5 Digest Algorithm", RFC 1321, MIT and RSA Data Security, Inc., April 1992.

[VK83] V.L. Voydock & S.T. Kent, "Security Mechanisms in High-level Networks", ACM Computing Surveys, Vol. 15, No. 2, June 1983.

否認事項
この見解と仕様は著者によるものであり、必ずしもその雇い主によるものではない。
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: babatt@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.