|
ネットワーク WG Request for Comments： 2402 廃止： 1826 分類： スタンダードトラック |
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.
IP認証ヘッダ(IP Authentication Header (AH))は、 IPデータグラムに対してコネクションレスインテグリティとデータ生成元認証 (これ以降は、単に「認証」と呼ぶことにする)を提供し、 さらにリプレイに対する保護を提供するために使用される。 後者はオプションのサービスであり、 セキュリティアソシエーションが確立される際に受信側によって選択される場合がある (デフォルトでは、 リプレイ防止に使用されるシーケンス番号のインクリメントを送信側に要求するが、 受信側がシーケンス番号をチェックする場合のみサービスが有効となる)。 AHは上位層プロトコルに加え、 IPヘッダの可能な限り多くの部分の認証を提供する。 しかしながら、一部のIPヘッダフィールドは転送中に変化することがあり、 パケットが受信側に到達した時のこのフィールドの値が送信側に予測できないものとなることがある。 このようなフィールドの値はAHによっては保護されない。 従ってAHがIPヘッダに提供する保護は、ある程度断片的なものになる。
AHは単独で、 またはIP暗号ペイロード(ESP) [KA97b]と組み合わせて、 またはトンネルモード(「インターネットプロトコルのためのセキュリティアーキテクチャ」[KA97a]を参照のこと。 これ以降は、セキュリティアーキテクチャ文書と呼ぶことにする) を使用した入れ子形式で適用される。 セキュリティサービスは、通信するホストの間、 通信するセキュリティゲートウェイの間、 またはセキュリティゲートウェイとホストの間に提供することができる。 ESPは同様のセキュリティサービスを提供するために利用でき、 そして守秘性(暗号化)サービスをも提供する。 ESPとAHが提供する認証の主な違いは、そのカバーする範囲である。 特に、ESPでは、 IPヘッダがESPによってカプセル化(トンネルモード)されていない限り、 どのIPヘッダフィールドも保護しない。 様々なネットワーク環境でのAHおよびESPの使用方法についての詳細は、 セキュリティアーキテクチャ文書 [KA97a] を参照すること。
この文書では、 読者がセキュリティアーキテクチャ文書で説明されている用語と概念に精通していることを前提としている。 特に読者は、AHおよびESPが提供するセキュリティサービスの定義、 セキュリティアソシエーションの概念、ESPと連携したAHの使用方法、 そしてAHおよびESPで利用できる異なる鍵管理オプションに精通している必要がある (最後の項目に関して補足すると、 AHとESPの両方に要求される鍵管理オプションとしては、現在、 マニュアル鍵管理とIKEによる自動鍵管理がある [HC98])。
しなければならない(MUST)、してはならない(MUST NOT)、 要求される(REQUIRED)、することになる(SHALL)、 することはない(SHALL NOT)、する必要がある(SHOULD)、 しないほうがよい(SHOULD NOT)、推奨される(RECOMMENDED)、 してもよい(MAY)、 選択できる(OPTIONAL) のキーワードが使われた場合は、 RFC 2119 [Bra97] における定義に沿って解釈されるものとする。
AHヘッダの直前のプロトコルヘッダ(IPv4、IPv6、または拡張ヘッダ)には、 プロトコルフィールド(IPv4)または次ヘッダフィールド(IPv6、 拡張ヘッダ)内に値51が含まれる [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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Payload Len | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Security Parameters Index (SPI) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number Field |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Authentication Data (variable) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
以下の章では、AHフォーマットを構成するフィールドについて定義する。 ここで定義するすべてのフィールドは必須のものである。 すなわち、すべてのフィールドは常にAHフォーマットに存在し、 インテグリティチェック値(ICV)の計算に含まれる (2.6章と3.3.3章を参照のこと)。
次ヘッダは、 認証ヘッダの後の次ペイロードタイプを識別する8ビットのフィールドである。 このフィールドの値は、Internet Assigned Numbers Authority (IANA)から出されているRFC「Assigned Numbers」[STD-2] の最新版にて定義されるIPプロトコル番号のセットから選択される。
この8ビットのフィールドでは、 32ビットワード(4バイト単位)でのAHの長さから"2"を引いた値を指定する (IPv6のすべての拡張ヘッダでは、RFC 1883に従って、 その「拡張ヘッダ長」フィールドに、 ヘッダ長(64ビットワードで測定)から最初に1 (64ビットワード)を引いた値を入れる)。 AHはIPv6の拡張ヘッダである。 ただし、AHの長さは32ビットワードで測定されるため、 この「ペイロード長」は2 (32ビットワード)を引いて計算される。 96ビットの認証値に固定部分の32ビットワードでの3が足される「標準的な」ケースでは、 このフィールドは"4"となる。 「NULL」認証アルゴリズムは、デバッグ目的のみに使用してもよい。 これを使用した場合、対応する認証データフィールドがないため、 IPv4ではこのフィールド値は"1"、IPv6では"2"となる (3.3.3.2.1章の「認証データのパディング」を参照のこと)。
この16ビットのフィールドは将来の利用のために予約されており、 「ゼロ」にセットされなければならない(MUST)。 (ここで、この値は認証データの計算に含まれるが、 受信側には無視されることに注意すること)。
SPIは、宛先IPアドレスとセキュリティプロトコル(AH)と組み合わせて、 そのデータグラムに対するセキュリティアソシエーションを一意に識別する任意の32ビットの値である。 1から255の範囲のSPI値は、Internet Assigned Numbers Authority (IANA)によって将来の利用のために予約されており、 IANAは割り当てられるSPI値の使用がRFCで指定されない限り、 この予約されたSPI値を通常割り当てることはしない。 SPIは、SAの確立の際に宛先システムによって選択されるのが一般的である (詳細はセキュリティアーキテクチャ文書を参照のこと)。
値ゼロ(0)のSPIはローカルな、実装固有の利用のために予約されており、 これを送信してはならない(MUST NOT)。 例えば、 鍵管理エンティティが新しいSAを確立することをIPsec実装が要求したが、 まだSAが確立されていない間に、 「セキュリティアソシエーションが存在しない」ことを意味するために、 このゼロのSPI値を鍵管理の実装が使用してもよい(MAY)。
この符号なし32ビットのフィールドには、 単純に増加するカウンタ値(シーケンス番号)が含まれる。 これは必須であり、 受信側がある特定のSAでリプレイ防止サービスの利用を選択しない場合でも常に存在する。 シーケンス番号フィールドの処理は受信側に任せられる。 すなわち、 送信側は常にこのフィールドを送信しなければならないが(MUST)、 受信側がそれを処理する必要はない (後の「入力パケット処理」の章におけるシーケンス番号の検証についての議論を参照のこと)。
送信側のカウンタと受信側のカウンタは、 SAの確立時に0に初期化される (与えられたSAを使用して送信される最初のパケットは、 シーケンス番号1を持つ。 シーケンス番号の生成方法についての詳細は3.3.2章を参照のこと)。 リプレイ防止が有効である場合(デフォルト)、 送信されたシーケンス番号の反復は絶対に許可してはならない。 従って、受信側のカウンタと送信側のカウンタは、 あるSA上で232番目のパケットを送信する前に (新しいSA、従って新しい鍵を確立することによって) リセットされなければならない(MUST)。
これは、 このパケットに対するインテグリティチェック値(ICV)を含む可変長フィールドである。 このフィールドの長さは32ビットの整数倍でなければならない。 ICV計算についての詳細は、3.3.2章にて説明する。 このフィールドには、明示的パディングを含んでもよい。 このパディングは、 AHヘッダの長さが32ビット(IPv4)または64ビット(IPv6)の整数倍であることを保証するために含まれる。 すべての実装において、 このパディングをサポートしなければならない(MUST)。 要求されるパディングの長さの計算方法についての詳細は、後で説明する。 認証アルゴリズムの仕様では、ICVの長さ、 およびその検証のための比較のルールと処理ステップを指定しなければならない(MUST)。
ESPと同様に、AHは2つのモード、つまり、 トランスポートモードもしくはトンネルモードで使用される。 前者のモードは、ホストでの実装にのみ適用可能であり、 選択されたIPヘッダフィールドに加えて、 上位層プロトコルの保護を提供する。 (このモードでは、セキュリティアーキテクチャ文書で定義される「bump-in-the-stack」または「bump-in-the-wire」実装の場合、 入力および出力IP断片は、この仕様に準拠し、 かつ透過的なIPsecのサポートを提供するために、 追加のIP再構成/分割の処理をIPsec実装に要求する場合がある。 複数インタフェースを使用する場合、 実装内でのこのような処理を実行するために特別な配慮が要求される)。
トランスポートモードでは、AHはIPヘッダの後、かつ上位層プロトコル、 例えばTCP、UDP、ICMP等の前、 または既に挿入されている他のIPsecヘッダの前に挿入される。 IPv4では、AHをIPヘッダ(およびIPヘッダが含むすべてのオプション)の後、 上位層プロトコルの前に配置することが要求される。 (ここで、「トランスポート」モードという用語が、 TCPおよびUDPの使用に限定されるという意味にとられるべきではないことに注意すること。 例えば、ICMPメッセージを、 「トランスポート」モードまたは「トンネル」モードのどちらを使用して送ってもよい(MAY))。 以下の図で、一般的なIPv4パケットにおけるAHトランスポートモードの位置の「前後」関係を示す。
AH 適用前
----------------------------
IPv4 |orig IP hdr | | |
|(any options)| TCP | Data |
----------------------------
AH 適用後
---------------------------------
IPv4 |orig IP hdr | | | |
|(any options)| AH | TCP | Data |
---------------------------------
|<------- authenticated ------->|
except for mutable fields
IPv6では、AHは終点間ペイロードと見なされるため、 中継点(hop-by-hop)、経路制御(routing)、 および断片(fragmentation)拡張ヘッダの後にあらわれる必要がある。 終点オプション(destination options)拡張ヘッダは、 希望する意味に応じて、AHヘッダの前または後に配置することができる。 以下の図で、 一般的なIPv6パケットにおけるAHトランスポートモードの位置を示す。
AH 適用前
---------------------------------------
IPv6 | | ext hdrs | | |
| orig IP hdr |if present| TCP | Data |
---------------------------------------
AH 適用後
------------------------------------------------------------
IPv6 | |hop-by-hop, dest*, | | dest | | |
|orig IP hdr |routing, fragment. | AH | opt* | TCP | Data |
------------------------------------------------------------
|<---- authenticated except for mutable fields ----------->|
* = 存在する場合、AH の前、AH の後、あるいはその両方に存在し得る
ESPおよびAHヘッダは様々なモードで組み合わせることが可能である。 IPsecアーキテクチャ文書では、 サポートしなければならないセキュリティアソシエーションの組み合わせが定義されている。
トンネルモードAHは、ホストまたはセキュリティゲートウェイ(または、 セキュリティアーキテクチャ文書で定義されている、 「bump-in-the-stack」あるいは「bump-in-the-wire」)のどちらで使用しても良い。 (配送する加入者トラヒックを保護するために) AHをセキュリティゲートウェイに実装する場合には、 トンネルモードが使用されなければならない。トンネルモードでは、 「内側」IPヘッダには最終点である送信元および宛先アドレスを含み、 「外側」IPヘッダにはそれとは別のIPアドレス、 例えばセキュリティゲートウェイのアドレスが含まれる可能性がある。 トンネルモードでは、AHは内側IPヘッダ全体を含む、 内側のIPパケット全体を保護する。 外側IPヘッダに関して言えば、トンネルモードにおけるAHの位置は、 トランスポートモードにおけるAHのものと同様である。 以下の図で、 一般的なIPv4およびIPv6パケットにおけるAHトンネルモードの位置を示す。
------------------------------------------------
IPv4 | new IP hdr* | | orig IP hdr* | | |
|(any options)| AH | (any options) |TCP | Data |
------------------------------------------------
|<- authenticated except for mutable fields -->|
| in the new IP hdr |
--------------------------------------------------------------
IPv6 | | ext hdrs*| | | ext hdrs*| | |
|new IP hdr*|if present| AH |orig IP hdr*|if present|TCP|Data|
--------------------------------------------------------------
|<-- authenticated except for mutable fields in new IP hdr ->|
* = 外側 IP ヘッダ/拡張ヘッダの構成と内側 IP ヘッダ/拡張ヘッダの
修正については後で説明する。
ICVの計算に使用される認証アルゴリズムは、SAによって指定される。 2地点間での通信の場合に適切な認証アルゴリズムとして、 対称鍵暗号化アルゴリズム(例えばDES)または一方向ハッシュ機能(例えばMD5、 SHA-1)を基にした鍵付きメッセージ認証コード(MAC)があげられる。 マルチキャスト通信では、 非対称署名アルゴリズムと組み合わせた一方向性ハッシュアルゴリズムが適切であるが、 性能とスペースの問題のために、 現在このようなアルゴリズムの使用は除外されている。 実装に必須の認証アルゴリズムは、 5章の「準拠に関する要求事項」において説明されている。 その他のアルゴリズムをサポートしてもよい(MAY)。
以前に説明したように、トランスポートモードでは、AHヘッダは、 送信側においてIPヘッダの後、上位層プロトコルヘッダの前に挿入される。 トンネルモードでは、 外側および内側IPヘッダ/拡張ヘッダは様々な方法で相互に関連付けることが可能である。 カプセル化処理の際の外側IPヘッダ/拡張ヘッダの構造は、 セキュリティアーキテクチャ文書において説明されている。
複数のIPsecヘッダ/拡張ヘッダが要求される場合、 セキュリティヘッダの適用順序をセキュリティポリシーによって定義しなければならない(MUST)。 処理を単純化するために、 各IPsecヘッダは、後で適用されるIPsecヘッダの存在(すなわち、 内容が含まれていない、あるいは内容の予測を試みる)を無視する必要がある。 (ネイティブIPまたはbump-in-the-stack実装は、 自身が後で適用するIPsecヘッダの内容を予測することができるが、 ホストとネットワークの間のbump-in-the-wire実装によって追加されるIPsecヘッダを予測することは不可能である)。
出力パケットが、 AH処理を要求するあるSAと関連しているということをIPsecの実装が判断した後でのみ、 そのパケットにAHが適用される。 どのIPsec処理(もしあれば)が出力トラヒックに適用されるのかを判断する処理については、 セキュリティアーキテクチャ文書において説明されている。
送信側のカウンタは、SAの確立時に0に初期化される。 送信側はこのSA用のシーケンス番号をインクリメントし、 新しい値をシーケンス番号フィールドに挿入する。 従って、 与えられたSAを使用して送信される最初のパケットにはシーケンス番号1が含まれることになる。
リプレイ防止が有効になっている場合(デフォルト)、 送信側は新しい値をシーケンス番号フィールドに挿入する前に、 カウンタが一巡していないことをチェックする。 つまり、 送信側はシーケンス番号が一巡している場合はパケットをSA上に送信してはならない(MUST NOT)。 シーケンス番号のオーバーフローを引き起こすようなパケットの送信を行うことは、 監査対象イベントとなる。 (ここで、このシーケンス番号の管理に関するこのアプローチには、 モジュロ演算の使用は必要としないことに注意すること)。
受信側による通知がない限り、 送信側はリプレイ防止がデフォルトで有効であると仮定する (3.4.3章を参照のこと)。 従って、カウンタが反復した場合、 送信側は新しいSAと鍵をセットアップすることになる (SAがマニュアル鍵管理で設定されていない限り)。
リプレイ防止が無効になっている場合、 送信側はカウンタの監視やリセットを行う必要がない。 これはすなわち、 マニュアル鍵管理のケースである(5章を参照のこと)。 ただし、送信側はカウンタをこれまで通りにインクリメントし、 カウンタが最大値に達した場合にゼロに戻す。
AH ICVは以下の項目に渡って計算される。
フィールドが配送中に変更される可能性がある場合、 そのフィールドの値は、ICVの計算ではゼロにセットされる。 フィールドが変更可能であるが、(IPsec)受信側での値が予測可能な場合、 ICVの計算ではその値がフィールドに挿入される。 認証データフィールドもまた、この計算の準備のためにゼロにセットされる。 ここで、各フィールドを省略するのではなく、 値をゼロに置き換えることによって、 ICVの計算の際にもフィールドが整列している状態が保持されることに注意すること。 またさらに、このゼロで埋めていくアプローチによって、 フィールドの内容がICVに明示的に含まれていなくても、 ゼロで埋められたフィールドの長さが配送中に変更されないことが保証される。
新しい拡張ヘッダまたはIPv4オプションが作成された場合、 それ自身のRFCが定義され、さらに、 AHのICV計算の際の扱いに関する指示が (そのセキュリティに関する考慮事項の章に)含まれる必要がある(SHOULD)。 IP (IPv4またはIPv6)実装が認識できない拡張ヘッダに遭遇した場合、 実装はそのパケットを廃棄し、ICMPメッセージを送信する。 IPsecはそのパケットを決して見ることはない。 IPsec実装が認識できないIPv4オプションに遭遇した場合、 オプションの第2バイトをその長さとして使用して、 そのオプション全体をゼロにする必要がある。 (終点拡張ヘッダまたは中継点拡張ヘッダ内の) IPv6オプションには、 このようなオプションに対する適切な処理を決定する、 可変度(mutability)を示すフラグが含まれる。
IPv4の基本ヘッダフィールドは次のように分類される。
TOS -- IPの仕様ではTOSを可変ヘッダフィールドとみなしていないにも関わらず、 一部のルータによってこのフィールドの値が変更されることが知られているため、 このフィールドは除外される。
フラグ -- 送信元が選択していなくても、 中間ルータがDFビットをセットすることがあるため、 このフィールドは除外される。
断片オフセット -- AHは非分割IPパケットにのみ適用されることからオフセットフィールドは常にゼロでなければならないため、 これは(予測可能ではあるが)除外される。
TTL -- これはルータによる通常の処理によって配送経路上変更可能であり、 受信側における値を送信側が予測することはできない。
ヘッダチェックサム -- 他のどのフィールドでもそれが変更された場合にこの値が変更されるため、 受信側での値を送信側が予測することはできない。
IPv4では(IPv6と異なり)、 配送中に変更可能とするオプションタグを付ける仕組みが存在しない。 そのため、付録AでIPv4オプションを、不変、可変だが予測可能、 可変という分類で明示的に示している。 IPv4では、オプション全体がユニットと見なされているため、 ほとんどのオプションのタイプおよび長さフィールドが配送中に不変であるとしても、 オプションが可変として分類されている場合は、 ICV計算ではオプション全体がゼロとされる。
IPv6基本ヘッダフィールドは次のように分類される。
中継点および終点拡張ヘッダには、 配送中にオプションが(予測不可能な状態で)変更される可能性があるかどうかを示すビットが含まれる。 内容が配送経路上変更可能であるオプションについては、 ICVの計算または検証の際に「オプションデータ」フィールド全体をゼロ値オクテットとして扱わなければならない。 オプション番号フィールドとオプションデータ長フィールドは、 ICVの計算に含まれる。 不変を示すビットを含むオプションはすべてICVの計算に含まれる。 更なる情報についてはIPv6の仕様[DH95]を参照のこと。
オプションを含まないIPv6拡張ヘッダは付録 Aで、不変、可変だが予測可能、 可変という分類で明示的に示している。
2.6章で説明したように、 認証データフィールドには、 AHヘッダが32ビットの整数倍(IPv4)または64ビットの整数倍(IPv6)であることを保証するために、 明示的にパディングが含まれる。 パディングが要求される場合、その長さは次の2つの要素によって決定される。
例えば、選択したアルゴリズムの出力が96ビットである場合、 IPv4またはIPv6のどちらでもパディングは不要である。 しかし、違うアルゴリズムを使用して、違う長さのICVが生成された場合、 その長さとIPプロトコルのバージョンに応じたパディングが要求される。 パディングフィールドの中身は、送信側が任意に決定する。 (パディングは任意であるが、 セキュリティを確保するためにランダムである必要はない)。 このパディングバイトは、認証データの計算に含まれ、 ペイロード長の一部としてカウントされ、 そして受信側がICVの計算を行えるように認証データフィールドの最後に付けて送られる。
一部の認証アルゴリズムでは、ICVの計算が実行されるバイトストリングは、 アルゴリズムが指定するブロックサイズの整数倍でなければならない。 IPパケット長(AHを含む)がそのアルゴリズムのブロックサイズの要求条件にあわなければ、 ICVの計算の前に暗黙的パディングがそのパケットの最後に追加されなければならない(MUST)。 パディングオクテットは値として0を持たなければならない(MUST)。 ブロックサイズ(そして、 それゆえにパディング長)はアルゴリズムの仕様によって指定される。 このパディングはパケットとともに転送されない。 ここで、MD5およびSHA-1はその内部パディング規則のために、 1バイトのブロックサイズを持つとみなされることに注意すること。
必要であれば、IPsec実装内でAH処理の後にIP分割が行われる。 従って、トランスポートモードAHは、 (IPの断片に対してではなく)IPデータグラム全体に対してのみ適用される。 AHが適用されたIPパケット自体は、 配送経路上のルータによって分割される場合があり、 これにより生じた断片は受信側でAH処理の前に再構成されなければならない。 トンネルモードでは、AHはIPパケット、 分割されたIPパケットのペイロードに適用される。 例えば、セキュリティゲートウェイ、または、 「bump-in-the-stack」および「bump-in-the-wire」IPsec実装は、 トンネルモードAHをこのような断片に対して適用する場合がある (詳細については、セキュリティアーキテクチャ文書を参照のこと)。
複数のIPsecヘッダ/拡張ヘッダが存在する場合、 それぞれに対する処理では、 処理されるヘッダに続いて適用されるIPsecヘッダを無視する (ゼロにしない、使用しない)。
必要であれば、AH処理の前に再構成が行われる。 処理を行うためにAHに渡されるパケットがIP断片である場合、つまり、 オフセットフィールドがゼロではないか、 断片継続(MORE FRAGMENTS)フラグがセットされている場合、 受信側はそのパケットを破棄しなければならず(MUST)、 これは監査対象イベントとなる。 このイベントに対する監査ログエントリには、SPI 値、日付/時間、 送信元アドレス、宛先アドレス、 (IPv6では)フローIDが含まれる必要がある(SHOULD)。
注釈：パケットの再構成に関して言えば、現在のIPv4の仕様では、 オフセットフィールドをゼロにしたり、 断片継続(MORE FRAGMENTS)フラグをクリアをすることは要求されていない。 再構成されるパケットを(明らかな断片として破棄するのとは対照的に)IPsec処理させるために、 IPのコードはパケットの再構成後に、 これら2つの処理を行わなければならない。
IP認証ヘッダを含むパケットを受信した際に、受信側は、 宛先IPアドレス、セキュリティプロトコル(AH)、 およびSPIを基に適切な(一方向)SAを決定する。 (このプロセスは、 セキュリティアーキテクチャ文書にてより詳細に説明されている)。 シーケンス番号フィールドをチェックするかどうかを示すSAは、 ICVの計算に使用するアルゴリズムを指定し、 ICVの検証に要求される鍵を指示する。
このセッションに対する有効なセキュリティアソシエーションが存在しない場合 (例えば受信側が鍵を持っていない場合)、 受信側はパケットを破棄しなければならず(MUST)、 これは監査対象イベントとなる。 このイベントに対する監査ログエントリには、SPI値、日付/時間、 送信元アドレス、宛先アドレス、 (IPv6では)フローIDが含まれる必要がある(SHOULD)。
リプレイ防止サービスの利用はSA毎に受信側によって有効または無効とされる場合があるが、 すべてのAH実装はこのサービスをサポートしなければならない(MUST)。 (ここで、トラヒックを1つのSAに送信する複数の送信側の間で、 (宛先アドレスがユニキャスト、ブロードキャスト、 あるいはマルチキャストであるかどうかに関係なく) 送信されるシーケンス番号値を管理するための規定がないことに注意すること)。 従って、リプレイ防止サービスは、 1つのSAを使用する複数の送信側の環境では使用しないほうがよい(SHOULD NOT)。
受信側があるSAに対してリプレイ防止を無効にした場合、 シーケンス番号に関する入力チェックは行われない。 しかし送信側から見た場合、 デフォルトで受信側ではリプレイ防止が有効になっていると仮定される。 送信側に不必要なシーケンス番号の監視やSAのセットアップを行わせることを避けるために(3.3.2章を参照のこと)、 IKEのようなSA確立プロトコルが使用される場合は、 受信側がリプレイ防止保護を提供しないのであれば、 SA確立中に受信側から送信側に通知する必要がある(SHOULD)。
受信側がこのSAに対してリプレイ防止サービスを有効にした場合、 そのSAに対する受信側のパケットカウンタはSAの確立時にゼロに初期化されなければならない(MUST)。 受信されたそれぞれのパケットについて、受信側は、 パケットに含まれるシーケンス番号が、 このSAの有効期間中に受信された他のどのパケットのシーケンス番号とも重複しないことを確認しなければならない(MUST)。 重複パケットの拒否を迅速に行うために、 この処理はパケットがSAとマッチされた後に最初にパケットに適用されるAHチェックとなる必要がある。
重複はスライディング受信ウィンドウを使用することによって防がれる。 (このウィンドウの実装方法はローカルの問題であるが、 実装が提示しなければならない機能を次に示す)。 最小ウィンドウサイズとして32をサポートしなければならない(MUST)。 しかし、ウィンドウサイズ64が望ましく、 これをデフォルトとして使用する必要がある(SHOULD)。 その他のウィンドウサイズ (最小よりも大きいサイズ)を受信側で選択しても良い(MAY)。 (受信側は送信側にウィンドウサイズを通知しない)。
ウィンドウの「右」端は、 このSAで受信した中で最も大きい有効シーケンス番号値を表す。 ウィンドウの「左」端より小さいシーケンス番号を含むパケットは拒否される。 ウィンドウ内に収まるパケットは、 ウィンドウ内で受信したパケットのリストに対してチェックされる。 ビットマスクの利用を基にしたこのチェックの効率的な実施方法は、 セキュリティアーキテクチャ文書において説明されている。
受信されたパケットがウィンドウに収まり、かつ新しい場合、 あるいは受信パケットがウィンドウの右側にある場合、 受信側はICVの検証に進む。 ICVの検証に失敗した場合、 受信側はIPデータグラムを無効として破棄しなければならず(MUST)、 これは監査対象イベントとなる。 このイベントの監査ログエントリには、SPI値、日付/時間、送信元アドレス、 宛先アドレス、(IPv6では)フローIDが含まれる必要がある(SHOULD)。 受信ウィンドウは、ICVの検証に成功した場合のみ更新される。
受信側は、指定された認証アルゴリズムを使用して、 パケットの適切なフィールドに渡ってICVを計算するとともに、 そのパケットの認証データフィールドに含まれているICVと同一であることを確認する。 その計算に関しての詳細を次に示す。
計算されたICVと受信されたICVが一致した場合、 そのデータグラムは有効となり受領される。 このテストに失敗した場合は、 受信側はIPデータグラムを無効として破棄しなければならず(MUST)、 これは監査対象イベントとなる。 このイベントの監査ログエントリには、SPI値、日付/時間、送信元アドレス、 宛先アドレス、(IPv6では)フローIDが含まれる必要がある(SHOULD)。
AHを実装するすべてのシステムが監査機能を実装するわけではない。 しかし、監査機能をサポートするシステムにAHが取り込まれる場合には、 AH実装も監査機能をサポートしなければならず(MUST)、 システム管理者がAHの監査機能を有効/無効にすることができるようにしなければならない(MUST)。 監査のグラニュラリティの大部分はローカルの問題である。 ただし、いくつかの監査対象イベントはこの仕様に記述されており、 これらのイベントに対して、 監査ログに含む必要のある(SHOULD)情報の最小セットが定義されている。 また、各イベントの監査ログには、 これに追加して他の情報を含んでもよい(MAY)。 さらに、これに追加してこの仕様で明示的に取り上げられていない他のイベントも監査ログエントリに含んでもよい(MAY)。 このアクションを介してサービス妨害を引き起こされる可能性があるため、 監査対象イベントの発見に応じて、 受信側が偽証転送者に対してすべてのメッセージを送信するような要求条件は存在しない。
この仕様に準拠する実装は、 ここで記述されているAHの構文と処理を完全に実装するとともに(MUST)、 セキュリティアーキテクチャ文書のすべての要求条件を満たさなければならない(MUST)。 ICVの計算に使用される鍵がマニュアル配送される場合には、 リプレイ防止サービスが正確に提供されるために、 鍵が置換されるまで送信側でカウンタ状態を正確にメンテナンスすることが要求される。 さらにこの場合、カウンタのオーバーフローが起こったとしても、 自動的なリカバリは提供されないだろう。 従って準拠する実装は、マニュアルで鍵管理されるSAで、 このサービスを提供しないほうがよい(SHOULD NOT)。 準拠する実装は、 実装に必須のアルゴリズムとして以下のものをサポートしなければならない(MUST)。
セキュリティはこのプロトコルの設計の中心的な事柄であり、 セキュリティに関する考慮事項は仕様全体に含まれている。 IPsecプロトコルの利用に対してこれに追加されるセキュリティ関連の話題は、 セキュリティアーキテクチャ文書で取り上げられている。
このAHの仕様には、 RFC 1826 [ATK95]との幾つかの重要な相違点があるが、 AHの基本的側面は変更されていない。 RFC 1826を改訂する目的の1つは、AHの完全なフレームワークを提供し、 補助のRFCではアルゴリズムの仕様のみを記述するようにすることであった。 例えば、リプレイ防止サービスは現在、 他のRFCで定義される変換の機能ではなく、AHの必須部分となっている。 現在このサービスをサポートするためのシーケンス番号の配送は、 常時必要とされている。 セキュリティを強化するために、 相互接続性に要求されるデフォルトのアルゴリズムは (鍵付きMD5から)HMAC MD5またはHMAC SHA-1に変更されている。 ICVの計算から除外されるIPv4ヘッダのフィールドのリストは、 オフセットフィールドとフラグフィールドを含むように拡張されている。
その他の改訂の動機は、詳細を追加し、 あいまいであった点を明確にすることにあった。 この仕様では、AHの適用範囲から、 指定されたIPv4ヘッダフィールドを除外することに対する論理根拠を提供し、 IPv4およびIPv6におけるAHの挿入位置に関する例を提供している。 また、監査に関する要求条件が今回のバージョンの仕様で明確になっている。 トンネルモードAHはRFC 1826で付加的に取り上げられたに過ぎないが、 今回はAHの必須の機能とされている。 鍵管理およびセキュリティラベルとの連携に関する議論は、 セキュリティアーキテクチャ文書の方に移っている。
3年以上に渡って、 この文書は様々なバージョンと繰り返しを経て発展してきた。 この間、 多くの人々が重要なアイディアや熱意を作業と文書の両方に注いでくれた。 レビュー、編集、背景調査、 およびコーディネーション作業で多大な貢献をしてくれたKaren Seoに感謝する。 また、IPsecおよびIPngワーキンググループのメンバー、 特に(アルファベット順で)、Steve Bellovin、Steve Deering、Francis Dupont、Phil Karn、Frank Kastenholz、Perry Metzger、David Mihelcic、Hilarie Orman、Norman Shulman、William Simpson、そしてNina Yuanの各氏の努力に感謝する。
以下の表に、IPv4オプションの「可変度」に関する分類を示す。 2つの参照が示される場合は、2番目のものが1番目のものを入れ替える。 この表は、RFC 1700 「ASSIGNED NUMBERS」(1994年10月)が提供する情報に一部基いている。
Opt.
Copy Class # Name Reference
---- ----- --- ------------------------ ---------
IMMUTABLE -- included in ICV calculation
0 0 0 End of Options List [RFC791]
0 0 1 No Operation [RFC791]
1 0 2 Security [RFC1108(historic but in use)]
1 0 5 Extended Security [RFC1108(historic but in use)]
1 0 6 Commercial Security [expired I-D, now US MIL STD]
1 0 20 Router Alert [RFC2113]
1 0 21 Sender Directed Multi- [RFC1770]
Destination Delivery
MUTABLE -- zeroed
1 0 3 Loose Source Route [RFC791]
0 2 4 Time Stamp [RFC791]
0 0 7 Record Route [RFC791]
1 0 9 Strict Source Route [RFC791]
0 2 18 Traceroute [RFC1393]
EXPERIMENTAL, SUPERCEDED -- zeroed
1 0 8 Stream ID [RFC791, RFC1122 (Host Req)]
0 0 11 MTU Probe [RFC1063, RFC1191 (PMTU)]
0 0 12 MTU Reply [RFC1063, RFC1191 (PMTU)]
1 0 17 Extended Internet Proto [RFC1385, RFC1883 (IPv6)]
0 0 10 Experimental Measurement [ZSu]
1 2 13 Experimental Flow Control [Finn]
1 0 14 Experimental Access Ctl [Estrin]
0 0 15 ??? [VerSteeg]
1 0 16 IMI Traffic Descriptor [Lee]
1 0 19 Address Extension [Ullmann IPv7]
注釈：ルータ警告(Router Alert)オプションの利用は、 IPsecの利用とは潜在的に互換性のないものである。 このオプションは不変であるが、このオプションの使用によって、 パケットの経路上にある各ルータがパケットを「処理」し、 その結果パケットが変更される可能性がある。 これは、パケットがルータからルータへと移動する度に、 中継点毎に発生することになる。 オプションの内容が仕向けられるアプリケーション、 例えばRSVP/IGMP等によって処理される前に、 パケットにAH処理を施す必要がある。
ただしAH処理では、 経路上の各ルータがSPIによって定義されるマルチキャストSAのメンバーであることが要求される。 これは、厳密に指定経路制御(strictly source routed)されていないパケットに問題を引き起こす可能性があり、 現在のところまだ利用できないマルチキャストサポート技術が必要とされる。
注釈：パケットの経路上にあるシステムによって、セキュリティラベル(BSO, ESO, CIPSO)を追加したり削除したりすることは、 これらのIPオプションを不変とする分類と相反し、 IPsecの利用と非互換となる。
注釈：最終オプションリスト(End of Options List)オプションは、 IPヘッダが4バイトの境界で終わることを保証するために必要に応じて繰り返される必要がある(SHOULD)。 これは、隠れたチャネルに使用される可能性のある未指定バイトが存在しないことを保証するためである。
以下の表では、IPv6拡張ヘッダの「可変度」に関する分類を示す。
Option/Extension Name Reference ----------------------------------- --------- MUTABLE BUT PREDICTABLE -- included in ICV calculation Routing (Type 0) [RFC1883] BIT INDICATES IF OPTION IS MUTABLE (CHANGES UNPREDICTABLY DURING TRANSIT) Hop by Hop options [RFC1883] Destination options [RFC1883] NOT APPLICABLE Fragmentation [RFC1883]
中継点(Hop by Hop)および終点(Destination)拡張ヘッダのIPv6オプションには、 配送途中にそのオプションが(予測不可能な状態で)変更される可能性があるかどうかを示すビットが含まれる。 内容が配送経路上変更可能であるオプションに対しては、 ICVの計算または検証時には、 オプションデータフィールド全体をゼロ値オクテットとして扱わなければならない。 オプション番号とオプションデータ長は、ICV計算に含まれる。 変更されないことがこのビットによって示されているオプションはすべて、 ICVの計算に含まれる。 さらなる情報についてはIPv6の仕様[DH95]を参照のこと。
「タイプ0」のIPv6経路制御ヘッダは、 送信元から宛先への配送途中でパケット内のアドレスフィールドを再配置する。 ただし、受信側に出現することになるパケットの内容は、 送信側とすべての中継点に知られる。 従って、「タイプ0」のIPv6経路制御ヘッダは、 変更される可能性があるが、 予測可能のものとして認証ヘッダの計算に含まれる。 送信側は、ICVの計算を行う前に、 フィールドを受信側にあらわれるものと同じになるように調整しなければならない。
分割は出力IPsec処理の後(3.3章)に、 再構成は入力IPsec処理(3.4章)の前に発生する。 従って、断片拡張ヘッダ(Fragmentation Extension Header)が存在しても、 それをIPsec処理で見ることはない。
ここで、受信側のIP実装は、 再構成が行われる際に断片拡張ヘッダをそのままの位置に置くことができることに注意すること。 これが行われた場合、AHがパケットを受信する際には、 AHはICV処理の前にこのヘッダを「削除」(またはスキップ)し、 前のヘッダの「次ヘッダ」フィールドを、 断片拡張ヘッダの「次ヘッダ」フィールドの値に変更しなければならない(MUST)。
ここで、送信側のIP実装は、 オフセット0(最初の断片)と断片継続フラグ(More Fragments Flag) 0 (最終断片)の断片拡張ヘッダを持つパケットをIPsecコードに与えることができることに注意すること。 これが行われた場合、AHはICV処理の前に、 まずこのヘッダを「削除」(またはスキップ)し、 前のヘッダの「次ヘッダ」フィールドを、 断片拡張ヘッダの「次ヘッダ」フィールドの値に変更しなければならない(MUST)。
[ATK95] Atkinson, R.,
「IP 認証ヘッダ(The IP Authentication Header)」,
RFC 1826, 1995年8月.
[Bra97] Bradner, S., "Key words for use in RFCs to Indicate Requirement Level", BCP 14, RFC 2119, 1997年3月.
[DH95] Deering, S., and B. Hinden, "Internet Protocol version 6 (IPv6) Specification", RFC 1883, 1995年12月.
[HC98] Harkins, D., and D. Carrel,
「IKE： インターネット鍵交換(The Internet Key Exchange
(IKE))」,
RFC 2409, 1998年11月.
[KA97a] Kent, S., and R. Atkinson,
「インターネットプロトコルのためのセキュリティアーキテクチャ(Security
Architecture for the Internet Protocol)」,
RFC 2401, 1998年11月.
[KA97b] Kent, S., and R. Atkinson,
「IP 暗号ペイロード(ESP)(IP Encapsulating Security
Payload (ESP))」,
RFC 2406, 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
この文書において示された見解と仕様は著者によるものであり、 必ずしもその雇い主によるものではない。 著者とその雇い主は、正確/不正確な実装、 およびこの設計の利用から生じるどのような問題への責任も拒否する。
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はすべての保証を明示的にも暗黙的にもおこなわない。 その中には、この情報がいかなる権利も侵害していないという保証や、 商用利用および特定目的における適合性への保証が含まれる。