ネットワークワーキンググループ
Request for Comments: 2402
廃止: 1826
分類: スタンダードトラック
S. Kent
BBN Corp
R. Atkinson
@Home Network
1998年11月

IP 認証ヘッダ
(IP Authentication Header)

このメモの位置付け 
この文書は、インターネットコミュニティに対してインターネットスタンダードトラックのプロトコルを定義するとともに、それを改良するための議論や提言を求めるものである。
このプロトコルの標準化状態およびステータスについては、「Internet Official Protocol Standards」(STD 1) の最新版を参照すること。
このメモの配布に制限はない。
著作権
Copyright (C) The Internet Society (1998). All Rights Reserved.
目次 
1. はじめに

2. 認証ヘッダのフォーマット

2.1 次ヘッダ
2.2 ペイロード長
2.3 予約
2.4 セキュリティパラメータインデックス(SPI)
2.5 シーケンス番号
2.6 認証データ
3. 認証ヘッダの処理
3.1 認証ヘッダの配置
3.2 認証アルゴリズム
3.3 出力パケット処理
3.3.1 セキュリティアソシエーションの検索
3.3.2 シーケンス番号の生成
3.3.3 インテグリティチェック値の計算
3.3.3.1 可変フィールドの扱い

3.3.3.1.1 IPv4 での ICV 計算

3.3.3.1.1.1 基本ヘッダフィールド
3.3.3.1.1.2 オプション

3.3.3.1.2 IPv6 での ICV 計算

3.3.3.1.2.1 基本ヘッダフィールド
3.3.3.1.2.2 オプションを含む拡張ヘッダ
3.3.3.1.2.3 オプションを含まない拡張ヘッダ

3.3.3.2 パディング

3.3.3.2.1 認証データのパディング
3.3.3.2.2 暗黙的パケットパディング

3.3.4 分割
3.4 入力パケット処理
3.4.1 再構成
3.4.2 セキュリティアソシエーションの検索
3.4.3 シーケンス番号の検証
3.4.4 インテグリティチェック値の検証
4. 監査

5. 準拠に関する考慮事項

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

7. RFC 1826 との相違点

謝辞

付録 A -- IP オプション/拡張ヘッダの可変度

A1. IPv4 オプション
A2. IPv6 拡張ヘッダ
参考文献

否認事項

著者の連絡先

著作権表示全文

1. はじめに 
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] における定義に沿って解釈されるものとする。

2. 認証ヘッダのフォーマット 
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 章を参照のこと)。
2.1 次ヘッダ 
次ヘッダは、認証ヘッダの後の次ペイロードタイプを識別する 8 ビットのフィールドである。
このフィールドの値は、Internet Assigned Numbers Authority (IANA) から出されている RFC 「Assigned Numbers」 [STD-2] の最新版にて定義される IP プロトコル番号のセットから選択される。
2.2 ペイロード長 
この 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 章の「認証データのパディング」を参照のこと)。
2.3 予約 
この 16 ビットのフィールドは将来の利用のために予約されており、「ゼロ」にセットされなければならない (MUST)
(ここで、この値は認証データの計算に含まれるが、受信側には無視されることに注意すること)。
2.4 セキュリティパラメータインデックス(SPI) 
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)

2.5 シーケンス番号 
この符号なし 32 ビットのフィールドには、単純に増加するカウンタ値(シーケンス番号)が含まれる。
これは必須であり、受信側がある特定の SA でリプレイ防御サービスの利用を選択しない場合でも常に存在する。
シーケンス番号フィールドの処理は受信側に任せられる。
すなわち、送信側は常にこのフィールドを送信しなければならないが (MUST)、受信側がそれを処理する必要はない(後の「入力パケット処理」の章におけるシーケンス番号の検証についての議論を参照のこと)。

送信側のカウンタと受信側のカウンタは、SA の確立時に 0 に初期化される(与えられた SA を使用して送信される最初のパケットは、シーケンス番号 1 を持つ。シーケンス番号の生成方法についての詳細は 3.3.2 章を参照のこと)。
リプレイ防御が有効である場合(デフォルト)、送信されたシーケンス番号の反復は絶対に許可してはならない。
従って、受信側のカウンタと送信側のカウンタは、ある SA 上で 2^32 番目のパケットを送信する前に(新しい SA、従って新しい鍵を確立することによって)リセットされなければならない (MUST)

2.6 認証データ 
これは、このパケットに対するインテグリティチェック値(ICV)を含む可変長フィールドである。
このフィールドの長さは 32 ビットの整数倍でなければならない。
ICV 計算についての詳細は、3.3.2 章にて説明する。
このフィールドには、明示的パディングを含んでもよい。
このパディングは、AH ヘッダの長さが 32 ビット(IPv4)または 64 ビット(IPv6)の整数倍であることを保証するために含まれる。
すべての実装において、このパディングをサポートしなければならない (MUST)
要求されるパディングの長さの計算方法についての詳細は、後で説明する。
認証アルゴリズムの仕様では、ICV の長さ、およびその検証のための比較のルールと処理ステップを指定しなければならない (MUST)
3. 認証ヘッダの処理 
3.1 認証ヘッダの配置 
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 ヘッダ/拡張ヘッダの
               修正については後で説明する。
3.2 認証アルゴリズム 
ICV の計算に使用される認証アルゴリズムは、SA によって指定される。
2 地点間での通信の場合に適切な認証アルゴリズムとして、対称鍵暗号化アルゴリズム(例えば DES)または一方向ハッシュ機能(例えば MD5、SHA-1)を基にした鍵付きメッセージ認証コード(MAC)があげられる。
マルチキャスト通信では、非対称署名アルゴリズムと組み合わせた一方向性ハッシュアルゴリズムが適切であるが、性能とスペースの問題のために、現在このようなアルゴリズムの使用は除外されている。
実装に必須の認証アルゴリズムは、5 章の「準拠に関する要求事項」において説明されている。
その他のアルゴリズムをサポートしてもよい (MAY)
3.3 出力パケット処理 
以前に説明したように、トランスポートモードでは、AH ヘッダは、送信側において IP ヘッダの後、上位層プロトコルヘッダの前に挿入される。
トンネルモードでは、外側および内側 IP ヘッダ/拡張ヘッダは様々な方法で相互に関連付けることが可能である。
カプセル化処理の際の外側 IP ヘッダ/拡張ヘッダの構造は、セキュリティアーキテクチャ文書において説明されている。

複数の IPsec ヘッダ/拡張ヘッダが要求される場合、セキュリティヘッダの適用順序をセキュリティポリシーによって定義しなければならない (MUST)
処理を単純化するために、各 IPsec ヘッダは、後で適用される IPsec ヘッダの存在(すなわち、内容が含まれていない、あるいは内容の予測を試みる)を無視する必要がある。
(ネイティブ IP または bump-in-the-stack 実装は、自身が後で適用する IPsec ヘッダの内容を予測することができるが、ホストとネットワークの間の bump-in-the-wire 実装によって追加される IPsec ヘッダを予測することは不可能である)。

3.3.1 セキュリティアソシエーションの検索 
出力パケットが、AH 処理を要求するある SA と関連しているということを IPsec の実装が判断した後でのみ、そのパケットに AH が適用される。
どの IPsec 処理(もしあれば)が出力トラフィックに適用されるのかを判断する処理については、セキュリティアーキテクチャ文書において説明されている。
3.3.2 シーケンス番号の生成 
送信側のカウンタは、SA の確立時に 0 に初期化される。
送信側はこの SA 用のシーケンス番号をインクリメントし、新しい値をシーケンス番号フィールドに挿入する。
従って、与えられた SA を使用して送信される最初のパケットにはシーケンス番号 1 が含まれることになる。

リプレイ防御が有効になっている場合(デフォルト)、送信側は新しい値をシーケンス番号フィールドに挿入する前に、カウンタが一巡していないことをチェックする。
つまり、送信側はシーケンス番号が一巡している場合はパケットを SA 上に送信してはならない (MUST NOT)
シーケンス番号のオーバーフローを引き起こすようなパケットの送信を行うことは、監査対象イベントとなる。
(ここで、このシーケンス番号の管理に関するこのアプローチには、モジュロ演算の使用は必要としないことに注意すること)。

受信側による通知がない限り、送信側はリプレイ防御がデフォルトで有効であると仮定する(3.4.3 章を参照のこと)。
従って、カウンタが反復した場合、送信側は新しい SA と鍵をセットアップすることになる(SA がマニュアル鍵管理で設定されていない限り)。

リプレイ防御が無効になっている場合、送信側はカウンタの監視やリセットを行う必要がない。
これはすなわち、マニュアル鍵管理のケースである(5 章を参照のこと)。
ただし、送信側はカウンタをこれまで通りにインクリメントし、カウンタが最大値に達した場合にゼロに戻す。

3.3.3 インテグリティチェック値の計算 
AH ICV は以下の項目に渡って計算される。
3.3.3.1 可変フィールドの扱い 
フィールドが配送中に変更される可能性がある場合、そのフィールドの値は、ICV の計算ではゼロにセットされる。
フィールドが変更可能であるが、(IPsec)受信側での値が予測可能な場合、ICV の計算ではその値がフィールドに挿入される。
認証データフィールドもまた、この計算の準備のためにゼロにセットされる。
ここで、各フィールドを省略するのではなく、値をゼロに置き換えることによって、ICV の計算の際にもフィールドが整列している状態が保持されることに注意すること。
またさらに、このゼロで埋めていくアプローチによって、フィールドの内容が ICV に明示的に含まれていなくても、ゼロで埋められたフィールドの長さが配送中に変更されないことが保証される。

新しい拡張ヘッダまたは IPv4 オプションが作成された場合、それ自身の RFC が定義され、さらに、AH の ICV 計算の際の扱いに関する指示が(そのセキュリティに関する考慮事項の章に)含まれる必要がある (SHOULD)
IP (IPv4 または IPv6)実装が認識できない拡張ヘッダに遭遇した場合、実装はそのパケットを廃棄し、ICMP メッセージを送信する。
IPsec はそのパケットを決して見ることはない。
IPsec 実装が認識できない IPv4 オプションに遭遇した場合、オプションの第 2 バイトをその長さとして使用して、そのオプション全体をゼロにする必要がある。
(終点拡張ヘッダまたは中継点拡張ヘッダ内の) IPv6 オプションには、このようなオプションに対する適切な処理を決定する、可変度 (mutability) を示すフラグが含まれる。

3.3.3.1.1 IPv4 での ICV 計算 
3.3.3.1.1.1 基本ヘッダフィールド 
IPv4 の基本ヘッダフィールドは次のように分類される。
不変
Version
Internet Header Length
Total Length
Identification
Protocol (これは AH 用の値となる必要あり)
Source Address
Destination Address (緩やかあるいは厳格な指定経路制御なし)
可変だが予測可能
Destination Address (緩やかあるいは厳格な指定経路制御あり)
可変 (ICV 計算の前にゼロにされる)
Type of Service (TOS)
Flags
Fragment Offset
Time to Live (TTL)
Header Checksum
TOS -- IP の仕様では TOS を可変ヘッダフィールドとみなしていないにも関わらず、一部のルータによってこのフィールドの値が変更されることが知られているため、このフィールドは除外される。

フラグ -- 送信元が選択していなくても、中間ルータが DF ビットをセットすることがあるため、このフィールドは除外される。

断片オフセット -- AH は非分割 IP パケットにのみ適用されることからオフセットフィールドは常にゼロでなければならないため、これは(予測可能ではあるが)除外される。

TTL -- これはルータによる通常の処理によって配送経路上変更可能であり、受信側における値を送信側が予測することはできない。

ヘッダチェックサム -- 他のどのフィールドでもそれが変更された場合にこの値が変更されるため、受信側での値を送信側が予測することはできない。

3.3.3.1.1.2 オプション 
IPv4 では(IPv6 と異なり)、配送中に変更可能とするオプションタグを付ける仕組みが存在しない。
そのため、付録 A で IPv4 オプションを、不変、可変だが予測可能、可変という分類で明示的に示している。
IPv4 では、オプション全体がユニットと見なされているため、ほとんどのオプションのタイプおよび長さフィールドが配送中に不変であるとしても、オプションが可変として分類されている場合は、ICV 計算ではオプション全体がゼロとされる。
3.3.3.1.2 IPv6 での ICV の計算 
3.3.3.1.2.1 基本ヘッダフィールド 
IPv6 基本ヘッダフィールドは次のように分類される。

不変

Version
Payload Length
Next Header (これは AH 用の値となる必要あり)
Source Address
Destination Address (経路制御拡張ヘッダなし)
可変だが予測可能
Destination Address (経路制御拡張ヘッダあり)
可変 (ICV 計算の前にゼロにされる)
Class
Flow Label
Hop Limit
3.3.3.1.2.2 オプションを含む拡張ヘッダ 
中継点および終点拡張ヘッダには、配送中にオプションが(予測不可能な状態で)変更される可能性があるかどうかを示すビットが含まれる。
内容が配送経路上変更可能であるオプションについては、ICV の計算または検証の際に「オプションデータ」フィールド全体をゼロ値オクテットとして扱わなければならない。
オプション番号フィールドとオプションデータ長フィールドは、ICV の計算に含まれる。
不変を示すビットを含むオプションはすべて ICV の計算に含まれる。
更なる情報については IPv6 の仕様 [DH95] を参照のこと。
3.3.3.1.2.3 オプションを含まない拡張ヘッダ 
オプションを含まない IPv6 拡張ヘッダは 付録 A で、不変、可変だが予測可能、可変という分類で明示的に示している。
3.3.3.2 パディング 
3.3.3.2.1 認証データのパディング 
2.6 章で説明したように、認証データフィールドには、AH ヘッダが 32 ビットの整数倍(IPv4)または 64 ビットの整数倍(IPv6)であることを保証するために、明示的にパディングが含まれる。
パディングが要求される場合、その長さは次の 2 つの要素によって決定される。
例えば、選択したアルゴリズムの出力が 96 ビットである場合、IPv4 または IPv6 のどちらでもパディングは不要である。
しかし、違うアルゴリズムを使用して、違う長さの ICV が生成された場合、その長さと IP プロトコルのバージョンに応じたパディングが要求される。
パディングフィールドの中身は、送信側が任意に決定する。(パディングは任意であるが、セキュリティを確保するためにランダムである必要はない)。
このパディングバイトは、認証データの計算に含まれ、ペイロード長の一部としてカウントされ、そして受信側が ICV の計算を行えるように認証データフィールドの最後に付けて送られる。
3.3.3.2.2 暗黙的パケットパディング 
一部の認証アルゴリズムでは、ICV の計算が実行されるバイトストリングは、アルゴリズムが指定するブロックサイズの整数倍でなければならない。
IP パケット長(AH を含む)がそのアルゴリズムのブロックサイズの要求条件にあわなければ、ICV の計算の前に暗黙的パディングがそのパケットの最後に追加されなければならない (MUST)
パディングオクテットは値として 0 を持たなければならない (MUST)
ブロックサイズ(そして、それゆえにパディング長)はアルゴリズムの仕様によって指定される。
このパディングはパケットとともに転送されない。
ここで、MD5 および SHA-1 はその内部パディング規則のために、1バイトのブロックサイズを持つとみなされることに注意すること。
3.3.4 分割 
必要であれば、IPsec 実装内で AH 処理の後に IP 分割が行われる。
従って、トランスポートモード AH は、(IP の断片に対してではなく) IP データグラム全体に対してのみ適用される。
AH が適用された IP パケット自体は、配送経路上のルータによって分割される場合があり、これにより生じた断片は受信側で AH 処理の前に再構成されなければならない。
トンネルモードでは、AH は IP パケット、分割された IP パケットのペイロードに適用される。
例えば、セキュリティゲートウェイ、または、「bump-in-the-stack」および「bump-in-the-wire」 IPsec 実装は、トンネルモード AH をこのような断片に対して適用する場合がある(詳細については、セキュリティアーキテクチャ文書を参照のこと)。
3.4 入力パケット処理 
複数の IPsec ヘッダ/拡張ヘッダが存在する場合、それぞれに対する処理では、処理されるヘッダに続いて適用される IPsec ヘッダを無視する(ゼロにしない、使用しない)。
3.4.1 再構成 
必要であれば、AH 処理の前に再構成が行われる。
処理を行うために AH に渡されるパケットが IP 断片である場合、つまり、オフセットフィールドがゼロではないか、断片継続 (MORE FRAGMENTS) フラグがセットされている場合、受信側はそのパケットを破棄しなければならず (MUST)、これは監査対象イベントとなる。
このイベントに対する監査ログエントリには、SPI 値、日付/時間、送信元アドレス、宛先アドレス、(IPv6 では)フロー ID が含まれる必要がある (SHOULD)

注釈:パケットの再構成に関して言えば、現在の IPv4 の仕様では、オフセットフィールドをゼロにしたり、断片継続 (MORE FRAGMENTS) フラグをクリアをすることは要求されていない。
再構成されるパケットを(明らかな断片として破棄するのとは対照的に) IPsec 処理させるために、IP のコードはパケットの再構成後に、これら 2 つの処理を行わなければならない。

3.4.2 セキュリティアソシエーションの検索 
IP 認証ヘッダを含むパケットを受信した際に、受信側は、宛先 IP アドレス、セキュリティプロトコル(AH)、および SPI を基に適切な(一方向) SA を決定する。(このプロセスは、セキュリティアーキテクチャ文書にてより詳細に説明されている)。
シーケンス番号フィールドをチェックするかどうかを示す SA は、ICV の計算に使用するアルゴリズムを指定し、ICV の検証に要求される鍵を指示する。

このセッションに対する有効なセキュリティアソシエーションが存在しない場合(例えば受信側が鍵を持っていない場合)、受信側はパケットを破棄しなければならず (MUST)、これは監査対象イベントとなる。
このイベントに対する監査ログエントリには、SPI 値、日付/時間、送信元アドレス、宛先アドレス、(IPv6 では)フロー ID が含まれる必要がある (SHOULD)

3.4.3 シーケンス番号の検証 
リプレイ防御サービスの利用は 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 の検証に成功した場合のみ更新される。

議論:

ここで、パケットがウィンドウ内に収まり新しい場合、あるいはウィンドウの「右」外側にある場合、受信側はシーケンス番号のウィンドウデータを更新する前にパケットを認証しなければならない (MUST) ことに注意すること。
3.4.4 インテグリティチェック値の検証 
受信側は、指定された認証アルゴリズムを使用して、パケットの適切なフィールドに渡って ICV を計算するとともに、そのパケットの認証データフィールドに含まれている ICV と同一であることを確認する。
その計算に関しての詳細を次に示す。

計算された ICV と受信された ICV が一致した場合、そのデータグラムは有効となり受領される。
このテストに失敗した場合は、受信側は IP データグラムを無効として破棄しなければならず (MUST)、これは監査対象イベントとなる。
このイベントの監査ログエントリには、SPI 値、日付/時間、送信元アドレス、宛先アドレス、(IPv6 では)フロー ID が含まれる必要がある (SHOULD)

議論:

まず ICV 値を保存してからその値(認証データのパディング以外)をゼロで置換する。
配送中に変更された、他のすべてのフィールドをゼロにする(ICV の計算を行う前にどのフィールドをゼロとするかに関する議論については 3.3.3.1 章を参照のこと)。
パケットの全体の長さをチェックし、認証アルゴリズムの要求に基く暗黙的パディングが必要であれば、パケットの最後にゼロが詰められたバイトを追加する。
ICV の計算を実行し、アルゴリズムの仕様で定義された比較ルールを使用して、その結果と保存されている値を比較する。
(例えば、電子署名と一方向ハッシュが ICV の計算に使用される場合、マッチング処理はより複雑になる)。
4. 監査 
AH を実装するすべてのシステムが監査機能を実装するわけではない。
しかし、監査機能をサポートするシステムに AH が取り込まれる場合には、AH 実装も監査機能をサポートしなければならず (MUST)、システム管理者が AH の監査機能を有効/無効にすることができるようにしなければならない (MUST)
監査のグラニュラリティの大部分はローカルの問題である。
ただし、いくつかの監査対象イベントはこの仕様に記述されており、これらのイベントに対して、監査ログに含む必要のある (SHOULD) 情報の最小セットが定義されている。
また、各イベントの監査ログには、これに追加して他の情報を含んでもよい (MAY)
さらに、これに追加してこの仕様で明示的に取り上げられていない他のイベントも監査ログエントリに含んでもよい (MAY)
このアクションを介してサービス妨害を引き起こされる可能性があるため、監査対象イベントの発見に応じて、受信側が偽証転送者に対してすべてのメッセージを送信するような要求条件は存在しない。
5. 準拠に関する要求事項 
この仕様に準拠する実装は、ここで記述されている AH の構文と処理を完全に実装するとともに (MUST)、セキュリティアーキテクチャ文書のすべての要求条件を満たさなければならない (MUST)
ICV の計算に使用される鍵がマニュアル配送される場合には、リプレイ防御サービスが正確に提供されるために、鍵が置換されるまで送信側でカウンタ状態を正確にメンテナンスすることが要求される。
さらにこの場合、カウンタのオーバーフローが起こったとしても、自動的なリカバリは提供されないだろう。
従って準拠する実装は、マニュアルで鍵管理される SA で、このサービスを提供しないほうがよい (SHOULD NOT)
準拠する実装は、実装に必須のアルゴリズムとして以下のものをサポートしなければならない (MUST)
6. セキュリティに関する考慮事項 
セキュリティはこのプロトコルの設計の中心的な事柄であり、セキュリティに関する考慮事項は仕様全体に含まれている。
IPsec プロトコルの利用に対してこれに追加されるセキュリティ関連の話題は、セキュリティアーキテクチャ文書で取り上げられている。
7. RFC 1826 との相違点 
この 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 の各氏の努力に感謝する。
付録 A -- IP オプション/拡張ヘッダの可変度 
A1. IPv4 オプション 
以下の表に、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)
これは、隠れたチャネルに使用される可能性のある未指定バイトが存在しないことを保証するためである。

A2. IPv6 拡張ヘッダ 
以下の表では、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] を参照のこと。
経路制御 (Routing)  (タイプ 0)
「タイプ 0」の IPv6 経路制御ヘッダは、送信元から宛先への配送途中でパケット内のアドレスフィールドを再配置する。
ただし、受信側に出現することになるパケットの内容は、送信側とすべての中継点に知られる。
従って、「タイプ 0」の IPv6 経路制御ヘッダは、変更される可能性があるが、予測可能のものとして認証ヘッダの計算に含まれる。
送信側は、ICV の計算を行う前に、フィールドを受信側にあらわれるものと同じになるように調整しなければならない。
分割 (Fragmentation)
分割は出力 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., "The IP Authentication Header", RFC 1826, August 1995.
[Bra97] Bradner, S., "Key words for use in RFCs to Indicate Requirement Level", BCP 14, RFC 2119, March 1997.

[DH95] Deering, S., and B. Hinden, "Internet Protocol version 6 (IPv6) Specification", RFC 1883, December 1995.

[HC98] Harkins, D., and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.

[KA97a] Kent, S., and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.

[KA97b] Kent, S., and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.

[MG97a] Madson, C., and R. Glenn, "The Use of HMAC-MD5-96 within ESP and AH", RFC 2403, November 1998.

[MG97b] Madson, C., and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and AH", RFC 2404, November 1998.

[STD-2] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994. See also: http://www.iana.org/numbers.html

否認事項 
この文書において示された見解と仕様は著者によるものであり、必ずしもその雇い主によるものではない。
著者とその雇い主は、正確/不正確な実装、およびこの設計の利用から生じるどのような問題への責任も拒否する。
著者の連絡先 
Stephen Kent
BBN Corporation
70 Fawcett Street
Cambridge, MA 02140
USA

Phone: +1 (617) 873-3988
EMail: kent@bbn.com
 

Randall Atkinson
@Home Network
425 Broadway,
Redwood City, CA 94063
USA

Phone: +1 (415) 569-5000
EMail: rja@corp.home.net
 

翻訳者

東京都中央区新川1-21-2 茅場町タワー
株式会社 NTTデータ
技術開発本部
馬場 達也

EMail: babatt@nttdata.co.jp

著作権表示全文 
Copyright (C) The Internet Society (1998). All Rights Reserved.

本文書とその翻訳は、複製および他に提供することができる。
また、この文書に論評や説明を加えたり、その実装を補助するものは、上記の著作権表示およびこの節を付加していれば、全体あるいは一部であっても一切の制約を課されることなく作成、複製、発表、配布できる。
ただし、この文書自体に対して、著作権表示やインターネットソサエティもしくは他のインターネット関連団体への参照を取り除くなどの変更を加えてはならない。
インターネット標準化過程で定義されている著作権のための手続きに従って、インターネット標準を開発するために必要な場合や、RFC を英語以外の言語に翻訳する必要がある場合はそのかぎりでない。

上記の制限は永続的なものであり、インターネットソサエティもしくはその継承者や譲渡者によって取り消されることはない。

本文書とここに含まれた情報は「無保証」で提供され、インターネットソサエティおよび IETF はすべての保証を明示的にも暗黙的にもおこなわない。
その中には、この情報がいかなる権利も侵害していないという保証や、商用利用および特定目的における適合性への保証が含まれる。