|
ネットワーク WG Request for Comments： 2406 廃止： 1827 分類： スタンダードトラック |
S. Kent BBN Corp R. Atkinson @Home Network 1998年11月 |
この文書は、 インターネットコミュニティに対してインターネットスタンダードトラックのプロトコルを定義するとともに、 それを改良するための議論や提言を求めるものである。 このプロトコルの標準化状態およびステータスについては、「Internet Official Protocol Standards」(STD 1)の最新版を参照すること。 このメモの配布に制限はない。
Copyright (C) The Internet Society (1998). All Rights Reserved.
暗号ペイロード(ESP)ヘッダは、 IPv4とIPv6におけるセキュリティサービスを融合して提供するように設計されている。 ESPは、単独、あるいは、IP認証ヘッダ(AH)と組み合わせて、または、 例えばトンネルモード(「インターネットプロトコルのためのセキュリティアーキテクチャ(Security Architecture for the Internet Protocol)」 [KA97a] を参照のこと。 以降「セキュリティアーキテクチャ文書」と呼ぶ)の使用による入れ子状態で適用される。 セキュリティサービスは、通信するホスト間、 通信するセキュリティゲートウェイ間、 またはセキュリティゲートウェイとホストの間に提供される。 様々なネットワーク環境でのESPとAHの使用方法についての詳細は、 セキュリティアーキテクチャ文書 [KA97a] を参照のこと。
ESPヘッダは、IPヘッダの後、 上位層プロトコルヘッダの前(トランスポートモードの場合)あるいはカプセル化されたIPヘッダの前(トンネルモードの場合)に挿入される。 これらのモードの詳細については以下に説明する。
ESPは守秘性、データ生成元認証、コネクションレスインテグリティ、 リプレイ防止サービス(部分的なシーケンスインテグリティの形式)、 そして限定されたトラヒックフロー守秘性を提供するために使用される。 提供されるサービスは、 セキュリティアソシエーションの確立時に選択されたオプションとその実装の配置に依存する。 守秘性は、他のどのサービスとも独立して選択してもよい。 ただし、(ESP自身、 または別にAHを使用することによって提供される)インテグリティや認証を伴わないで守秘性を使用した場合、 そのトラヒックは守秘性サービスを弱めることになるある形態の積極的攻撃を受けやすくなる可能性がある([Bel96] を参照のこと)。 データ生成元認証とコネクションレスインテグリティは連携しているサービスであり(以降、 まとめて「認証」と呼ぶ)、 (オプションの)守秘性と組み合わせてオプションとして提供される。 リプレイ防止サービスは、データ生成元認証が選択される場合にのみ選択され、 これは完全に受信側の判断で選択される。 (デフォルトでは、 送信側でリプレイ防止に使用されるシーケンス番号をインクリメントすることが要求されるが、 このサービスは受信側がシーケンス番号をチェックする場合のみ有効となる)。 トラヒックフロー守秘性のためにはトンネルモードを選択する必要があり、 これは、 トラヒックを集約することによって実際の送信元と宛先を隠すことが可能な、 セキュリティゲートウェイに実装するのが最も効果的である。 ここで、守秘性と認証はいずれもオプションではあるが、 少なくともこのうち1つは選択されなければならない(MUST)ことに注意すること。
この文書では、 読者がセキュリティアーキテクチャ文書で説明されている用語と概念に精通していることを前提としている。 特に読者は、AHおよびESPが提供するセキュリティサービスの定義、 セキュリティアソシエーションの概念、 認証ヘッダ(AH)と組み合わせたESPの使用方法、 AHおよびESPで利用できるそれぞれの鍵管理オプションに精通している必要がある。 (最後の項目に関しては、現在、 AHとESPの両方に要求される鍵管理オプションとして、 マニュアル鍵管理とIKEによる自動鍵管理が存在する [HC98])。
しなければならない(MUST)、してはならない(MUST NOT)、 要求される(REQUIRED)、することになる(SHALL)、 することはない(SHALL NOT)、する必要がある(SHOULD)、 しないほうがよい(SHOULD NOT)、推奨される(RECOMMENDED)、 してもよい(MAY)、 選択できる(OPTIONAL)のキーワードが使用された場合は、 RFC 2119 [Bra97] における定義に沿って解釈されるものとする。
ESPヘッダの直前にくるプロトコルヘッダ(IPv4、IPv6、 または拡張ヘッダ)のプロトコルフィールド(IPv4)または次ヘッダフィールド(IPv6、 拡張ヘッダ)には、値50が含まれる [STD-2]。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ----
| Security Parameters Index (SPI) | ^Auth.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov-
| Sequence Number | |erage
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ----
| Payload Data* (variable) | | ^
~ ~ | |
| | |Conf.
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov-
| | Padding (0-255 bytes) | |erage*
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| | Pad Length | Next Header | v v
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------
| Authentication Data (variable) |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* 暗号同期データ(例えば初期ベクトル(IV、2.3 章を参照のこと))は、
がペイロードフィールドに含まれる場合、それはしばしば暗号文の一部
としてみなされることがあるが、通常、実際には暗号化されない。
以下の章では、ヘッダフォーマットのフィールドについて定義する。 「選択できる(optional)」は、そのオプションが選択されない場合には、 そのフィールドが省略されることを意味する。 すなわち、送信されるパケットにもインテグリティチェック値(ICV、 2.7章を参照のこと)の計算の際のパケットフォーマットにもそのフィールドは存在しない。 オプションは、 セキュリティアソシエーション(SA)の確立の際に決定される。 従って、与えられたSAにおけるESPパケットのフォーマットは、 SAの有効期間中は変化しない。 これとは対照的に、「必須」のフィールドは、 すべてのSA において、ESPパケットフォーマット中に常に存在する。
SPIは、 宛先IPアドレスとセキュリティプロトコル(ESP)と組み合わせることにより、 そのデータグラムに対するセキュリティアソシエーションを一意に識別する、 任意の32ビットの値である。 1から255までのSPI値は、Internet Assigned Numbers Authority (IANA)によって将来の利用のために予約されている。 割り当てられるSPI値の使用がRFCで指定されない限り、通常、 予約されたSPI値はIANAから割り当てられない。 SPIは、SAの確立時に宛先システムによって選択されるのが一般的である (詳細についてはセキュリティアーキテクチャ文書を参照のこと)。 SPIフィールドは必須である。
ゼロ(0)のSPI値は、ローカルな、実装固有の利用のために予約されており、 これを送信してはならない(MUST NOT)。 例えば、IPsecの実装の鍵管理エンティティが新しいSAを確立することをIPsec実装が要求したが、 SAがまだ確立されていない間に、 「セキュリティアソシエーションが存在しない」ことを意味するような場合に、 このゼロのSPI値を鍵管理実装が使用してもよい(MAY)。
この符号なし32ビットのフィールドには、 単純に増加するカウンタ値(シーケンス番号)が含まれる。 これは必須であり、 受信側がある特定のSAでリプレイ防止サービスの利用を選択しない場合でも常に存在する。 シーケンス番号フィールドの処理は受信側に任せられる。 すなわち、 送信側は常にこのフィールドを送信しなければならないが(MUST)、 受信側がそれを処理する必要はない (後の「入力パケット処理」の章の「シーケンス番号の検証」の議論を参照のこと)。
送信側のカウンタと受信側のカウンタは、 SAの確立時に0に初期化される(あるSAを使用して送信される最初のパケットは、 シーケンス番号1を持つ。 シーケンス番号の生成方法についての詳細は3.3.3章を参照のこと)。 リプレイ防止が有効である場合(デフォルト)、 送信されたシーケンス番号は絶対に一巡してはならない。 従って、送信側のカウンタと受信側のカウンタは、 あるSA上で232番目のパケットを送信する前に (新しいSAと、それにともなって新しい鍵を確立することによって) リセットされなければならない(MUST)。
ペイロードデータフィールドは、 次ヘッダフィールドで定義されるデータを含む可変長フィールドである。 このペイロードデータフィールドは必須であり、 その長さは整数バイト数である。 ペイロードの暗号化に使用されるアルゴリズムが、 暗号同期データ(例えば初期ベクトル(IV))を必要とする場合、 このデータはペイロードフィールド内で明示的に運ばれてもよい(MAY)。 このような明示的なパケット単位の同期データを必要とする暗号化アルゴリズムはすべて、 このようなデータの長さと構造、およびデータの位置を、 そのアルゴリズムのESPでの使用方法を指定するRFCの一部で示さなければならない(MUST)。 このような同期データが暗黙的である場合には、 そのデータを導出するアルゴリズムがRFCの一部で示されなければならない(MUST)。
ここで、IVが存在する場合に(実際の)暗号文の整列状態を保証するために以下のことに注意すること。
パディングフィールドを使用する必要性、 動機となる要因がいくつか存在する。
送信側は0から255バイトのパディングを追加して良い(MAY)。
ESPパケットにパディングフィールドを含むことはオプションであるが、
すべての実装ではパディングの生成と使用をサポートしなければならない(MUST)。
パディングバイトが必要とされるが、
そのパディングの中身を暗号化アルゴリズムが指定しない場合は、
デフォルトで次の処理をしなければならない(MUST)。
パディングバイトは(符号なし、1バイトの)連続した整数値に初期化される。
平文に追加される最初のパディングバイトには1と番号付けされ、
それに続くパディングバイトでは単純に1、2、3...と増加していく。
このパディング規則が使用される場合、
受信側はパディングフィールドを検査する必要がある(SHOULD)。
(この規則が選ばれた理由は、比較的単純であること、
ハードウェアでの実装が容易なこと、さらには、
受信側で復号時にパディングがチェックされる場合、
別にインテグリティへの対応がない場合に、
ある形態の「カットアンドペースト」攻撃に対する限定された保護が提供されるためである)。
上で示したデフォルト以外の方法によるパディングを必要とする暗号化アルゴリズムでは、 パディングの中身(例えば、ゼロ、乱数データ)と、 受信側で必要とされるパディングバイトの処理について、 そのアルゴリズムのESPでの使用方法を指定するRFCにおいて定義しなければならない(MUST)。 このような状況では、パディングフィールドの中身は、 暗号化アルゴリズムと選択されたモードによって決定され、 対応するアルゴリズムのRFCにおいて定義される。 関連するアルゴリズムのRFCでは、 受信側がパディングフィールドを検査しなければならないこと(MUST)、 または受信側によるパディングフィールドの処理方法を送信側に通知しなければならないこと(MUST)を指定してもよい(MAY)。
パディング長フィールドは、その直前のパディングバイトのバイト数を示す。 有効な値の範囲は0から255であり、 値0はパディングバイトが存在しないことを示す。 パディング長フィールドは必須である。
次ヘッダは、 ペイロードデータフィールドに含まれるデータタイプ (例えばIPv6の拡張ヘッダまたは上位層プロトコル識別子) を識別する8ビットのフィールドである。 このフィールドの値は、Internet Assigned Numbers Authority (IANA)から出されているRFC「Assigned Numbers」 [STD-2] の最新版において定義されるIPプロトコル番号のセットから選ばれる。 次ヘッダフィールドは必須である。
認証データは、ESPパケットから認証データを抜いたものから計算されたインテグリティチェック値(ICV)を含む可変長フィールドである。 このフィールドの長さは、選択される認証関数によって指定される。 認証データフィールドはオプションであり、 認証サービスが当該SAに対して選択された場合のみ、 このフィールドが含まれる。 認証アルゴリズムは、ICVの長さと、 検証時の比較ルールおよび処理ステップについて指定しなければならない(MUST)。
AHと同じように、ESPは2つのモード、 つまりトランスポートモードまたはトンネルモードで使用される。 前者のモードは、ホストでの実装にのみ適用可能であり、 上位層プロトコルの保護を提供するが、 IPヘッダの保護は提供しない。 (このモードでは、 セキュリティアーキテクチャ文書で定義される「bump-in-the-stack」または「bump-in-the-wire」実装の場合、 入力および出力IP断片は、この仕様に準拠し、 かつトランスペアレントなIPsecのサポートを提供するために、 追加のIP再構成/分割の処理をIPsec実装に要求する場合がある。 複数インタフェースを使用する場合、 実装内でこのような処理を実行するために特別な配慮が要求される)。
トランスポートモードでは、ESPはIPヘッダの後、 かつ上位層プロトコル(例えば TCP、UDP、ICMPなど)の前、 または既に挿入されている他のIPsecヘッダの前に挿入される。 IPv4では、ESPをIPヘッダ(およびIPヘッダが含むすべてのオプション)の後、 上位層プロトコルの前に配置することが要求される。 (ここで、「トランスポート」モードという用語が、 TCPおよびUDPの使用に限定されるという意味にとられるべきではないことに注意すること。 例えば、ICMPメッセージは、 「トランスポート」モードまたは「トンネル」モードのどちらを使用して送信しても良い(MAY))。 以下の図で、 一般的なIPv4パケットにおけるESPトランスポートモードの位置の「前後」関係を示す。 (「ESPトレイラー」にはすべてのパディングに加え、 パディング長フィールド、次ヘッダフィールドが含まれる)。
ESP 適用前
----------------------------
IPv4 |orig IP hdr | | |
|(any options)| TCP | Data |
----------------------------
ESP 適用後
-------------------------------------------------
IPv4 |orig IP hdr | ESP | | | ESP | ESP|
|(any options)| Hdr | TCP | Data | Trailer |Auth|
-------------------------------------------------
|<----- encrypted ---->|
|<------ authenticated ----->|
IPv6では、ESPは終点間ペイロードと見なされるため、 中継点(hop-by-hop)、経路制御 (routing)、 および断片 (fragmentation)拡張ヘッダの後にあらわれる必要がある。 終点オプション(destination options)拡張ヘッダは、 希望する意味に応じて、ESPヘッダの前または後に配置することができる。 ただし、ESPはESPヘッダの後のフィールドのみを保護するため、 ESPヘッダの後に終点オプションヘッダを配置するのが望ましい。 以下の図で、 一般的なIPv6パケットにおけるESPトランスポートモードの位置を示す。
ESP 適用前
---------------------------------------
IPv6 | | ext hdrs | | |
| orig IP hdr |if present| TCP | Data |
---------------------------------------
ESP 適用後
---------------------------------------------------------
IPv6 | orig |hop-by-hop,dest*,| |dest| | | ESP | ESP|
|IP hdr|routing,fragment.|ESP|opt*|TCP|Data|Trailer|Auth|
---------------------------------------------------------
|<---- encrypted ---->|
|<---- authenticated ---->|
* = 存在する場合、AH の前、AH の後、あるいはその両方に存在し得る
ESPおよびAHヘッダは様々なモードで組み合わせることが可能である。 IPsecアーキテクチャ文書では、 サポートしなければならないセキュリティアソシエーションの組み合わせが定義されている。
トンネルモードESPは、 ホストまたはセキュリティゲートウェイのどちらで使用しても良い。 (配送する加入者トラヒックを保護するために) ESPをセキュリティゲートウェイに実装する場合には、 トンネルモードが使用されなければならない。 トンネルモードでは、 「内側」IPヘッダには最終点である送信元アドレスと宛先アドレスが含まれ、 「外側」IPヘッダにはそれとは別のIPアドレス (例えばセキュリティゲートウェイのアドレス)が含まれることがある。 トンネルモードでは、 ESPは内側IPヘッダ全体を含む内側IPパケット全体を保護する。 外側IPヘッダに関して言えば、トンネルモードにおけるESPの位置は、 トランスポートモードにおけるESPのものと同様である。 以下の図で、 一般的なIPv4およびIPv6パケットにおけるESPトンネルモードの位置を示す。
-----------------------------------------------------------
IPv4 | new IP hdr* | | orig IP hdr* | | | ESP | ESP|
|(any options)| ESP | (any options) |TCP|Data|Trailer|Auth|
-----------------------------------------------------------
|<--------- encrypted ---------->|
|<----------- authenticated ---------->|
------------------------------------------------------------
IPv6 | new* |new ext | | orig*|orig ext | | | ESP | ESP|
|IP hdr| hdrs* |ESP|IP hdr| hdrs * |TCP|Data|Trailer|Auth|
------------------------------------------------------------
|<--------- encrypted ----------->|
|<---------- authenticated ---------->|
* = 存在する場合。外側 IP ヘッダ/拡張ヘッダの構成と
内側 IP ヘッダ/拡張ヘッダの修正については後で説明する。
実装に必須のアルゴリズムは、 5章の「準拠に関する要求事項」にて説明されている。 また、この他のアルゴリズムをサポートしてもよい(MAY)。 ここで、守秘性と認証はいずれもオプションであるが、 少なくともこのうち1つのサービスを選択しなければならない(MUST)、 つまり、両方同時にNULLとなってはならない(MUST NOT) ことに注意すること。
使用する暗号化アルゴリズムはSAによって指定される。 ESPは対称鍵暗号化アルゴリズムと共に使用するように設計されている。 IPパケットは異なる順番で到着することがあるため、 それぞれのパケットで、 受信側が復号の際の暗号同期を行うために必要なデータを運ばなければならない。 このデータは、ペイロードフィールド内で明示的に、 例えば(以前に説明した)IVとして運ばれるか、 またはパケットヘッダから導出される。 ESPが平文のパディングの準備を行うため、 ESPで使用される暗号化アルゴリズムは、 ブロックモードまたはストリームモード特性のどちらかを示す。 ここで、暗号化(守秘性)はオプションであることから、 このアルゴリズムは「NULL」となる可能性があることに注意すること。
ICVの計算に使用する認証アルゴリズムはSAによって指定される。 2点間での通信の場合に適切な認証アルゴリズムとして、 対称鍵暗号化アルゴリズム(例えばDES) をもとにした鍵付きメッセージ認証コード(MAC)や一方向性ハッシュ関数 (例えばMD5、SHA-1)があげられる。 マルチキャスト通信の場合には、 非対称署名アルゴリズムと組み合わせた一方向性ハッシュアルゴリズムが適切であるが、 その性能と空間を考慮すると、 現在このようなアルゴリズムの使用は除外される。 ここで、認証はオプションであることから、 このアルゴリズムは「NULL」となる可能性があることに注意すること。
トランスポートモードでは、 送信側は上位層プロトコル情報をESPヘッダ/トレイラーにカプセル化し、 指定されたIPヘッダ(およびIPv6におけるすべてのIP拡張ヘッダ)をそのまま保持する。 トンネルモードでは、 外側と内側のIPヘッダ/拡張ヘッダを様々な方法で相互に関連付けることが可能である。 カプセル化処理の際の外側IPヘッダ/拡張ヘッダの構造は、 セキュリティアーキテクチャ文書にて説明されている。 セキュリティポリシーによって複数のヘッダ/拡張ヘッダが要求される場合、 セキュリティヘッダの適用順序はセキュリティポリシーで定義されなければならない(MUST)。
ESPは、ESP処理を要求するSAとそのパケットが関連していることをIPsecの実装が判断した後でのみ、 出力パケットに適用される。 どのIPsec処理が出力トラヒックに適用されるかを判断する過程については、 セキュリティアーキテクチャ文書において説明されている。
この章では、 フォーマッティングのために常に適用される暗号化についてとりあげる。 「守秘性なし」の状態は、 NULL暗号化アルゴリズムを使用することによって提供されることを理解して頂きたい。 従って、送信側は以下の処理を行う。
外側IPヘッダを構成するための正確な過程は、 モード(トランスポートモードまたはトンネルモード)に依存し、 これはセキュリティアーキテクチャ文書にて定義されている。
認証が選択された場合は、暗号化が認証の前に最初に実行され、 暗号化には認証データフィールドは含まれない。 この順序で処理することによって、 受信側でリプレイパケットや偽パケットを迅速に発見して拒否することができ、 サービス妨害攻撃の影響を潜在的に減らすことができる。 さらにこれにより、受信側でパケットを並列処理することができる。 すなわち、復号と認証を並行して行うことができる。 ここで、認証データは暗号化によって保護されないため、 ICVの計算に鍵付き認証アルゴリズムを使用しなければならないことに注意すること。
送信側のカウンタは、SAの確立時に0に初期化される。 送信側は、このSA用のシーケンス番号をインクリメントして、 その新しい値をシーケンス番号フィールドに挿入する。 従って、与えられたSAを使用して送信される最初のパケットはシーケンス番号として1を持つことになる。
リプレイ防止が有効である場合(デフォルト)、送信側では、 新しい値をシーケンス番号フィールドに挿入する前に、 カウンタが一巡していないことをチェックする。 つまり、送信側はシーケンス番号が一巡した場合はパケットをSAに送信してはならない(MUST NOT)。 シーケンス番号のオーバーフローを引き起こすようなパケットを送信しようとする試みは、 監査対象イベントとなる。 (ここで、シーケンス番号管理に関するこのアプローチは、 モジュロ演算の使用を必要としないことに注意すること)。
受信側による通知がない限り、 送信側はデフォルトでリプレイ防止が有効であると仮定する (3.4.3章を参照のこと)。 従って、カウンタが一巡した場合、 送信側は新しいSAと鍵をセットアップすることになる (SAがマニュアル鍵管理で設定されていない限り)。
リプレイ防止が無効の場合 (例えばマニュアル鍵管理(5章を参照のこと)の場合)には、 送信側はカウンタの監視やリセットを行う必要がない。 ただし、送信側はカウンタをこれまでどおりインクリメントし、 カウンタが最大値に到達した場合はゼロに戻す。
SAに対して認証が選択された場合には、 送信側はESPパケットから認証データを抜いたものに対してICVを計算する。 従って、SPI、シーケンス番号、ペイロードデータ、 パディング(存在すれば)、パディング長、 次ヘッダの各フィールドがすべてICV計算に取り込まれる。 ここで、暗号化が認証の前に行われるため、 最後の4つのフィールドは暗号文の形式となることに注意すること。
一部の認証アルゴリズムでは、 ICVの計算の対象となるバイトストリングがアルゴリズムによって指定されるブロックサイズの整数倍でなければならない。 このバイトストリングの長さがアルゴリズムのブロックサイズの要求条件と一致しない場合は、 ICVの計算の前に、 暗黙的パディングがESPパケットの最後(次ヘッダフィールドの後) に追加されなければならない(MUST)。 パディングオクテットの値は0でなければならない(MUST)。 ブロックサイズ(とパディング長)はアルゴリズムの仕様によって指定される。 ここで、MD5とSHA-1はその内部パディング規則のために、 1バイトのブロックサイズを持つとみなされることに注意すること。
必要であれば、IPsec実装内でESP処理の後にIP分割が行われる。 従って、トランスポートモードESPは、 (IPの断片に対してではなく) IPデータグラム全体に対してのみ適用される。 ESPが適用されたIPパケット自身は、 配送経路上のルータによって分割される可能性があり、 これにより生じた断片は受信側でESP処理の前に再構成されなければならない。 トンネルモードでは、 ESPはそのペイロードが分割されたIPパケットの可能性のあるIPパケットに適用される。 例えば、セキュリティゲートウェイ、 または「bump-in-the-stack」および「bump-in-the-wire」IPsec実装では、 トンネルモードESPをこのような断片に対して適用する場合がある (詳細については、セキュリティアーキテクチャ文書を参照のこと)。
注釈：トランスポートモードの場合 -- 3.1章のはじめに説明されているように、 bump-in-the-stackおよびbump-in-the‐wire実装では、 ローカルのIP層で分割されたパケットを最初に再構成してからIPsecを適用し、 その結果生じるパケットを分割しなければならないことがある。
注釈： IPv6 の場合 -- bump-in-the-stackおよびbump-in-the‐wire実装では、断片ヘッダが存在し、 そしてその結果、 パケットをIPsec処理の前に再構成する必要があるかどうかを判断するために、 すべての拡張ヘッダを読み通す必要があるだろう。
必要であれば、ESP処理の前に再構成が行われる。 処理を行うためにESPに渡されるパケットがIPの断片である場合、つまり、 オフセットフィールドがゼロでないか、 断片継続(MORE FRAGMENTS)フラグがセットされている場合、 受信側はそのパケットを破棄しなければならず(MUST)、 これは監査対象イベントとなる。 このイベントに対する監査ログエントリには、SPI 値、日付/時間、 送信元アドレス、宛先アドレス、シーケンス番号、 (IPv6では)フローIDが含まれる必要がある(SHOULD)。
注釈：パケット再構成に関して言えば、 現在のIPv4の仕様では、オフセットフィールドをゼロにしたり、 断片継続(MORE FRAGMENTS)フラグをクリアすることは要求されていない。 再構成されるパケットを(明らかな断片として破棄するのとは対照的に) IPsec処理させるために、 IPのコードはパケットの再構成後に、 これら2つの処理を行わなければならない。
ESPヘッダを含む(再構成された)パケットを受信した際に、受信側は、 宛先IPアドレス、セキュリティプロトコル(ESP)、 およびSPIをもとに適切な(一方向) SAを決定する。 (この過程は、 セキュリティアーキテクチャ文書にてより詳細に説明されている)。 SAは、シーケンス番号フィールドをチェックするかどうか、 認証データフィールドが存在するかどうかを示し、 復号とICVの計算(適用可能であれば)に使用するアルゴリズムと鍵を指定する。
このセッションに対する有効なセキュリティアソシエーションが存在しない場合 (例えば受信側が鍵を持っていない場合)、 受信側はそのパケットを破棄しなければならず(MUST)、 これは監査対象イベントとなる。 このイベントに対する監査ログエントリには、SPI 値、日付/時間、 送信元アドレス、宛先アドレス、シーケンス番号、 (IPv6では)フローIDが含まれる必要がある(SHOULD)。
リプレイ防止サービスの利用はSA毎に受信側によって無効とされる場合があるが、 すべてのESP実装はこのサービスをサポートしなければならない(MUST)。 しかし、シーケンス番号フィールドのインテグリティは保護されないため、 認証サービスがそのSAに対して有効でない限り、 このサービスを有効としてはならない(MUST NOT)。 (ここで、トラヒックを1つのSAに送信する複数の送信側の間で、 (宛先アドレスがユニキャスト、ブロードキャスト、 あるいはマルチキャストであるかどうかに関係なく) 送信されるシーケンス番号の値を管理するための規定がないことに注意すること)。 従って、リプレイ防止サービスは、 1つのSAを使用する送信者が複数存在する環境では使用しないほうがよい(SHOULD NOT)。
受信側があるSAに対してリプレイ防止を無効にした場合は、 シーケンス番号の入力チェックは行われない。 しかし、送信側から見た場合、 デフォルトで受信側ではリプレイ防止が有効になっていると仮定される。 送信側に不必要なシーケンス番号の監視やSAのセットアップを行わせることを避けるために (3.3.3章を参照のこと)、 IKEのようなSA確立プロトコルが使用される場合は、 受信側がリプレイ防止保護を提供しないのであれば、 それをSA確立中に受信側から送信側に通知する必要がある(SHOULD)。
受信側がこのSAに対してリプレイ防止を有効にした場合、 そのSAに対する受信側のパケットカウンタはSAの確立時にゼロに初期化されなければならない(MUST)。 受信されたそれぞれのパケットについて、受信側は、 パケットに含まれるシーケンス番号が、 このSAの有効期間中に受信された他のどのパケットのシーケンス番号とも重複しないことを確認しなければならない(MUST)。 重複パケットを迅速に拒否するために、 パケットがSAとマッチされた後のESP処理の最初にこのチェックを行う必要がある。
重複はスライディング受信ウィンドウを使用することによって防がれる。 (このウィンドウの実装方法はローカルの問題であるが、 実装が持たなければならない機能を次に示す)。 最小ウィンドウサイズは32をサポートしなければならない(MUST)。 しかし、ウィンドウサイズ64が望ましく、 これをデフォルトとして使用する必要がある(SHOULD)。 その他のウィンドウサイズ(最小よりも大きいサイズ)を受信側で選択してもよい(MAY)。 (受信側は送信側にウィンドウサイズを通知しない)。
ウィンドウの「右」端は、 このSAで受信した中で最も大きい有効シーケンス番号値を表す。 ウィンドウの「左」端より小さいシーケンス番号を含むパケットは拒否される。 ウィンドウ内に収まるパケットは、 ウィンドウ内で受信したパケットのリストに対してチェックされる。 ビットマスクの利用をもとにしたこのチェックの効率的な実施法については、 セキュリティアーキテクチャ文書にて説明されている。
受信されたパケットがウィンドウに収まり、かつ新しい場合、 あるいは受信されたパケットがウィンドウの右側にある場合、 受信側はICVの検証に進む。 ICVの検証に失敗した場合、 受信側はIPデータグラムを無効として破棄しなければならず(MUST)、 これは監査対象イベントとなる。 このイベントの監査ログエントリには、SPI 値、日付/時間、 送信元アドレス、宛先アドレス、シーケンス番号、 (IPv6では)フローIDが含まれる必要がある(SHOULD)。 受信ウィンドウは、ICVの検証に成功した場合のみ更新される。
検討：ここで、パケットがウィンドウ内に収まり、かつ新しい場合、 あるいはウィンドウの「右」外側にある場合、 受信側はシーケンス番号のウィンドウデータを更新する前にパケットを認証しなければならない(MUST) ことに注意すること。
認証が選択された場合、受信側は、指定された認証アルゴリズムを使用して、 ESPパケットから認証データを抜いたものからICVを計算するとともに、 それがそのパケットの認証データフィールドに含まれているICVと同一であることを確認する。 その計算に関しての詳細を次に示す。
計算されたICVと受信されたICVが一致した場合、 そのデータグラムは有効となり受領される。 このテストに失敗した場合は、 受信側はIPデータグラムを無効として破棄しなければならず(MUST)、 これは監査対象イベントとなる。 このイベントの監査ログエントリには、SPI値、日付/時間、 送信元アドレス、宛先アドレス、シーケンス番号、 (IPv6では)平文のフローIDが含まれる必要がある(SHOULD)。
検討：まずICV値(認証データフィールド)の削除と保存を行う。 次に、ESPから認証データを抜いた分の全体の長さをチェックする。 認証アルゴリズムのブロックサイズに基づく暗黙的パディングが必要であれば、 次ヘッダフィールドの直後のESPパケットの最後にゼロで満たされたバイトを追加する。 ICVの計算を実行し、アルゴリズムの仕様で定義された比較ルールにより、 その結果と保存されている値を比較する。 (例えば、電子署名と一方向性ハッシュがICVの計算に使用される場合、 マッチング処理はより複雑になる)。
3.3.2章
の「パケットの暗号化」と同様に、 この章では、 フォーマッティングのために常に適用される暗号化についてとりあげる。 「守秘性なし」の状態は、 NULL暗号化アルゴリズムを使用することによって提供されることを理解して頂きたい。 従って、受信側は以下の処理を行う。オリジナルのデータグラムを再構成するための正確な過程は、 モード(トランスポートモードまたはトンネルモード)に依存し、 これはセキュリティアーキテクチャ文書にて定義されている。 最低でもIPv6では、受信側は、 次ヘッダフィールドで識別されるプロトコルの処理を迅速に行うために、 復号されたデータが8バイトで整列されていることを保証する必要がある(SHOULD)。
認証が選択された場合は、検証と復号を連続して、 または並行して行ってもよい(MAY)。 連続して行う場合は、ICVの検証を最初に行う必要がある(SHOULD)。 並行して行う場合には、復号されたパケットが次の処理に渡される前に、 検証を完了しなければならない(MUST)。 この順序で処理することによって、受信側で、 パケットの復号の前にリプレイパケットや偽パケットを迅速に発見して拒否することができ、 サービス妨害攻撃の影響を潜在的に減らすことができる。
注釈：
受信側で、復号と認証を並行して行う場合は、
パケットアクセスと復号されたパケットの再構成の競合の可能性を避けるようにしなければならない。
ここで、 復号に「失敗する」可能性がある場合がいくつかあることに注意すること。
ケース(a)または(c)では、 誤った復号処理の結果(無効なIPデータグラムまたはトランスポート層フレーム)は、 必ずしもIPsecによって発見される必要はなく、この場合、 後のプロトコル処理に任せられる。
ESPを実装するすべてのシステムが監査機能を実装するわけではない。 しかし、監査をサポートするシステムにESPが取り込まれる場合には、 ESP実装も監査をサポートしなければならず(MUST)、 システム管理者がESPの監査を有効または無効にすることができるようにしなければならない(MUST)。 たいていの場合、監査のグラニュラリティはローカルの問題である。 ただし、いくつかの監査対象イベントがこの仕様に記述されており、 これらのイベントに対して、 監査ログに含む必要のある(SHOULD)情報の最小セットが定義されている。 また、各イベントの監査ログには、 これに追加して他の情報を含んでもよい(MAY)。 さらに、これに追加してこの仕様で明示的に取り上げられていない他のイベントも監査ログエントリに含んでもよい(MAY)。 このアクションを介してサービス妨害を引き起こされる可能性があるため、 監査対象イベントの発見に応じて、 受信側が送信者を偽っている者に対してすべてのメッセージを送信してしまうような要求条件は存在しない。
この仕様に準拠する実装は、 ここで記述されているESPの構文と処理を実装するとともに(MUST)、 セキュリティアーキテクチャ文書のすべての要求条件を満たさなければならない(MUST)。 ICVの計算に使用される鍵がマニュアル配送される場合には、 リプレイ防止サービスを正確に提供するために、 鍵が置換されるまで送信側でカウンタ状態を正確にメンテナンスすることが要求される。 さらにこの場合、カウンタのオーバーフローが起こったとしても、 自動的なリカバリは提供されない。 従って準拠する実装は、マニュアルで鍵管理されるSAで、 このサービスを提供しないほうがよい(SHOULD NOT)。 準拠するESP実装は、 実装に必須のアルゴリズムとして以下のものをサポートしなければならない(MUST)。
ESPの暗号化と認証はオプションであることから、 2つの「NULL」アルゴリズムのサポートが、 これらのサービスをネゴシエートする方法との一貫性を維持するために必要である。 ここで、認証と暗号化はそれぞれ「NULL」となり得るが、 両方が「NULL」であってはならない(MUST NOT)ことに注意すること。
セキュリティはこのプロトコルの設計の中心的な事項であり、 セキュリティに関する考慮事項は仕様全体に含まれている。 また、IPsecプロトコルの利用に対してこれに追加されるセキュリティ関連事項が、 セキュリティアーキテクチャ文書で取り上げられている。
この文書はRFC 1827 [ATK95]とは幾つかの重要な点で異なっている。 主な相違点は、 この文書がESPの完全なフレームワークと周辺関係を指定しようとしているのに対し、 RFC 1827では、 変換の定義を通して完成される「外観」を提供していることにある。 変換の組み合わせの増加が、 ESPの仕様をESPにおいて提供されるセキュリティサービスのオプションを含んだより完全な文書として再編する動機となっている。 従って、以前に変換に関する文書において定義されていたフィールドは、 今回はESPの仕様の一部となっている。 例えば、認証(およびリプレイ防止)をサポートするために必要なフィールドは、 このサービスの提供はオプションであるが、今回ここで定義されている。 暗号化および次プロトコルの識別のためのパディングをサポートするために使用されるフィールドも同様にここで定義されている。 これらのフィールドの定義と一致するパケット処理についても今回の文書に含まれている。
この仕様に含まれている概念の多くは、 米国政府のSP3セキュリティプロトコル、ISO/IECのNLSP、 提案されたswIPeセキュリティプロトコルから導出されたもの、 または影響を受けたものである [SDNS89, ISO92, IB93] 。
3年以上に渡って、 この文書は様々なバージョンと繰り返しを経て発展してきた。 この間、 多くの人々が重要なアイディアと熱意を作業と文書の両方に注いでくれた。 レビュー、編集、背景調査、 およびコーディネーション作業で多大な貢献をしてくれたKaren Seoに感謝する。 また、IPsecおよびIPngワーキンググループのメンバー、 特に(アルファベット順で)、Steve Bellovin、Steve Deering、Phil Karn、Perry Metzger、David Mihelcic、Hilarie Orman、Norman Shulman、William Simpson、そしてNina Yuanの各氏の努力に感謝する。
| [ATK95] |
Atkinson, R., 「IP暗号ペイロード(ESP)(IP Encapsulating Security Payload (ESP))」, RFC 1827, 1995年8月. |
| [Bel96] | Steven M. Bellovin, "Problem Areas for the IP Security Protocols", Proceedings of the Sixth Usenix Unix Security Symposium, 1996年7月. |
| [Bra97] |
Bradner, S., 「RFCにおいて要請の程度を示すために用いるキーワード(Key words for use in RFCs to Indicate Requirement Level)」, BCP 14, RFC 2119, 1997年3月. |
| [HC98] |
Harkins, D., and D. Carrel, 「IKE：インターネット鍵交換(The Internet Key Exchange (IKE))」, RFC 2409, 1998年11月. |
| [IB93] | John Ioannidis & Matt Blaze, "Architecture and Implementation of Network-layer Security Under Unix", Proceedings of the USENIX Security Symposium, Santa Clara, CA, 1993年10月. |
| [ISO92] | ISO/IEC JTC1/SC6, Network Layer Security Protocol, ISO-IEC DIS 11577, International Standards Organisation, Geneva, Switzerland, 1992年11月29日. |
| [KA97a] |
Kent, S., and R. Atkinson, 「インターネットプロトコルのためのセキュリティアーキテクチャ(Security Architecture for the Internet Protocol)」, RFC 2401, 1998年11月. |
| [KA97b] |
Kent, S., and R. Atkinson, 「IP認証ヘッダ(IP Authentication Header)」, RFC 2402, 1998年11月. |
| [MD97] |
Madson, C., and N. Doraswamy, 「明示的IVを伴うESP DES-CBC暗号アルゴリズム(The ESP DES-CBC Cipher Algorithm With Explicit IV)」, RFC 2405, 1998年11月. |
| [MG97a] |
Madson, C., and R. Glenn, 「ESPおよびAHにおけるHMAC-MD5-96の使用法(The Use of HMAC-MD5-96 within ESP and AH)」, RFC 2403, 1998年11月. |
| [MG97b] |
Madson, C., and R. Glenn, 「ESPおよびAHにおけるHMAC-SHA-1-96の使用法(The Use of HMAC-SHA-1-96 within ESP and AH)」, RFC 2404, 1998年11月. |
| [STD-2] | Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700, 1994年10月. See also: http://www.iana.org/numbers.html |
| [SDNS89] | SDNS Secure Data Network System, Security Protocol 3, SP3, Document SDN.301, Revision 1.5, 1989年5月15日, as published in NIST Publication NIST-IR-90-4250, 1990年2月. |
この文書において示された見解と仕様は著者によるものであり、 必ずしもその雇い主によるものではない。 著者とその雇い主は、正確/不正確な実装、 およびこの設計の利用から生じるどのような問題への責任も拒否する。
Stephen Kent
BBN Corporation
70 Fawcett Street
Cambridge, MA 02140
USA
電話： +1 (617) 873-3988
EMail： kent＠bbn.com
Randall Atkinson
@Home Network
425 Broadway,
Redwood City, CA 94063
USA
電話： +1 (415) 569-5000
EMail： rja＠corp.home.net
株式会社 NTTデータ
開発本部
馬場 達也
EMail: babatt＠nttdata.co.jp
Copyright (C) The Internet Society (1998). All Rights Reserved.
本文書とその翻訳は、複製および他に提供することができる。 また、この文書に論評や説明を加えたり、その実装を補助するものは、 上記の著作権表示およびこの節を付加していれば、 全体あるいは一部であっても一切の制約を課されることなく作成、複製、 発表、配布できる。 ただし、この文書自体に対して、 著作権表示やインターネットソサエティもしくは他のインターネット関連団体への参照を取り除くなどの変更を加えてはならない。 インターネット標準化過程で定義されている著作権のための手続きに従って、 インターネット標準を開発するために必要な場合や、 RFCを英語以外の言語に翻訳する必要がある場合はそのかぎりでない。
上記の制限は永続的なものであり、 インターネットソサエティもしくはその継承者や譲渡者によって取り消されることはない。
本文書とここに含まれた情報は「無保証」で提供され、 インターネットソサエティおよびIETFはすべての保証を明示的にも暗黙的にもおこなわない。 その中には、この情報がいかなる権利も侵害していないという保証や、 商用利用および特定目的における適合性への保証が含まれる。