$Id: report-ipsec-cnlan9809.html,v 1.2 1999/12/31 08:26:59 sakane Exp $

ここにある文章は「コンピュータ&ネットワークLAN 1998/9月号」に掲載された記事です。 オーム社編集部の許可を得て公開しています。 WEBで公開するため若干手を加えているので、表現や言葉使いに相違があります。

1999/03/03 認証に関して AH と ESP の違いを明確にした。
1999/01/21 図 7 の範囲を修正。(murakawa@rdnw.kme.mei.co.jp さんありがとうございます。)


%Hd: "IPsec セミナールーム第2回" コンピュータ&ネットワークLAN 1998年9月号

前回の記事でアルゴリズムをパケットに適用する規則をトランスフォームと呼ぶと 説明しました。これは古い定義で、規則には特に名前はつけられていません。 間違いを記述したことをお詫びします。

さて、この記事を書いている間にも、IPsec に関するドラフトが揃って出ました。 RFC として世に送り出されるまで、もう少しかかりそうです。 前回は IPsec の概要について簡単に説明しましたが、 今回は、そのアーキテクチャについて少し詳しく説明していきたいと思います。

第2回 IPsec のアーキテクチャ

IPsec の構成要素

IPsec の構成要素は大別すると以下の4つに分けられることは前回書きました。 それぞれの関係は図1の様になります。
	図 1. IPsec の構成要素の関係
鍵管理プロトコルが、送信者と受信者の間で使用するセキュリティプロトコルや アルゴリズムを交渉をして、SA を確立させます。 このようにシステムを分離することによって、より良いものが開発された時に、 比較的簡単に置き換えられるように設計されています。 これらのことは Security Architecture for the Internet Protocol (※1)に、 より詳しく記述されているので、参考にして下さい。

SA

SA とは、安全な通信を提供するための論理的なコネクションのことで、 これが確立すると、そこを流れるトラフィックは IPsec が提供するセキュリティの 範囲で安全であると言えます。IPsec が提供するセキュリティは前回説明した通りです。

SA の重要な特徴は『受信者が属性を決める片方向のコネクション』です。 これは、2点間で互いに通信を行うには、それぞれの方向に SA が 必要なことを意味します。(図2)

+------+   A -> B 向きのパケットのための SA   +------+
|      | ===================================> |      |
|HOST A|   B -> A 向きのパケットのための SA   |HOST B|
|      | <=================================== |      |
+------+                                      +------+
	図 2. 単一方向のコネクション
また、SA に適用されるセキュリティプロトコルは 1 つと決められています。 もし 2 点間で 2 つ以上のセキュリティプロトコルが必要なら、 その数だけ SA が必要になります。 この SA を管理するテーブルを セキュリティ・アソシエーション・データベース(以降 SAD と略す) と呼びます。

SA を構成するために必要なパラメータには以下のものがあります。

図3 の様に、ネットワーク A とネットワーク B の通信や、 ホスト X とホスト Y の通信のために SA を確立することが出来ます。 また、ホスト X のユーザがホスト Y の FTP を使うための SA を確立するなどと いうことも出来ます。 このために通信を行う 2 点間の識別子は、IPアドレス、ネットマスク、IPより上の層の プロトコル番号とポート番号があります。
	図 3. SA の単位
SPI は受信者がセキュリティプロトコル毎に SA を識別するために使うもので、 セキュリティプロトコルのヘッダに含まれます。 また、鍵を破るために必要な時間よりも少なく SA の生存時間を指定することで、 より強固なセキュリティを実現しようとしています。

SA を確立するためには、これらのパラメータを受信者が決定して 安全な方法を用いて送信者に知らせます。 安全な方法とは鍵管理と呼ばれる部分の仕事で、後で説明します。

さて、IPsec が提供するセキュリティには、いくつかの種類があると前回説明しました。 そこで、あるホストがデータを送信しようとした時、どのセキュリティを適用するのか 判断するためのテーブルが必要になります。 これをセキュリティポリシー・データベース(以降 SPD と略す)と呼びます。

送信者は、SPD を用いて適用するセキュリティを決めます。 そして SAD から必要な SA を選択し、そこに定義されたパラメータを使って 必要な処理をパケットに施し送信します。 受信者はセキュリティプロトコル番号とSPIにより、SAD から SA を選びだし パケットに必要な処理を施します。 そして、SPD を用いて十分なセキュリティが提供されていたか検査し、 最終的にパケットを受け取ることになります。(図4)

	図 4. SPD と SAD

セキュリティ・プロトコル

セキュリティプロトコルは、以下の 2 つが定義され実装必須になっています。 各プロトコルは、セキュリティプロトコルで処理されるデータの範囲を示す、 トランスポート・モードとトンネル・モードの 2 つのモードが用意されています。 前者は IP のデータ部分、後者は IP パケット全体がその対象になります。 トンネル・モードは、RFC 1853 (※4)に定義されている IP in IP Tunneling 技術を 利用したモードで、IP パケット全体を IP のデータと見なして新たな IP ヘッダを 付加します。(図9参照) それぞれは図5の様な場合で使用されます。
	図 5. トンネル・モードとトランスポート・モード
ESP と AH は組み合わせて使用が可能で、例えば図5の下の例の場合、 設定によっては図6の様なパケットになります。
	[IP2][ESP][IP1][AH][ESP][ULP]

	図 6. ESP と AH の組み合わせの例
注意しなければいけないのは、 ファイアウォールの様なセキュリティ・ゲートウェイ(※5)として振舞う場合は トランスポート・モードを使用してはいけない決まりになっています。

ESP

ESP は以下のセキュリティの全て、またはいくつかを組み合わせて 提供することが出来ます。 これらのセキュリティを提供するために暗号アルゴリズムや 認証アルゴリズム、カウンタを使用します。

図7 は、TCP と IPv4、そしてトランスポート・モードの SA を使用した時に、 ESP が IPパケットのどこに置かれるかを示したものです。

                     ESP 適用前
            ----------------------------
      IPv4  | IP     | TCP    | データ |
            | ヘッダ | ヘッダ |        |
            ----------------------------

                     ESP 適用後
            ---------------------------------------------------------------
      IPv4  | IP     | ESP    | TCP    | データ | ESP        | ESP        |
            | ヘッダ | ヘッダ | ヘッダ |        | 付加データ | 認証データ |
            ---------------------------------------------------------------
                              |<----- 暗号化される範囲 ----->|
                     |<---------- 認証される範囲 ----------->|

	図 7. トランスポート・モードにおける IPパケット内の ESP の位置
ESP のためにプロトコル番号 50 が IANA より割り当てられているので、 直前のヘッダの次ヘッダ番号には 50 が設定されます。

ESP の構成は図8の通りです。

    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.
   |                      Sequence Number                          | |Coverage
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | -----
   |                    Payload Data* (variable)                   | |   ^
   ~                                                               ~ |   |
   |                                                               | |   |
   +               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Confid.
   |               |     Padding (0-255 bytes)                     | |Coverage*
   +-+-+-+-+-+-+-+-+               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |   |
   |                               |  Pad Length   | Next Header   | v   v
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -------
   |                 Authentication Data (variable)                |
   ~                                                               ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

	図 8. ESP の構成
まず SA を識別するための SPI が先頭に、 次に Anti-replay (※6)のためのカウンタ(Sequence Number)があります。 これは SA が確立した時に 0 に初期化され、 送信者は ESP 処理をするたびにカウンタを 1 つ増やします。 受信者はこの番号を調べることにより、既に届いたパケットかどうかを判断します。 これにより同じパケットの処理を防ぎます。

Payload Data は SA のモードによって決められる ESP を適用するデータです。 暗号アルゴリズムによって処理するデータの単位が決まっているので、 データをその単位にそろえるために、Payload Data には埋め合わせのデータが 付加されます。これを Padding と呼びます。 そして Padding したバイト数(Pad Length)と Payload Data のプロトコル番号(Next Header)を Padding の最後の部分に置きます。 この Payload Data に Padding を付加した部分に暗号アルゴリズムを適用し 秘匿性等のセキュリティを提供することになります。

Authentication Data は、ESP から Authentication Data を引いた部分に対して、 認証アルゴリズムによる完全性を提供するために付加されるデータです。 これは Integrity Check Value (ICV) とも呼ばれます。 送信者は ICV を計算しパケットを送信します。 受信者は ICV を検査することで、伝送途中にパケットが改纂されたことがわかります。

AH

AH は以下のセキュリティのいくつか、または全てを組み合わせて 提供することが出来ます。 これらのセキュリティを提供するために認証アルゴリズム、カウンタを使用します。 暗号アルゴリズムは用いられないので、秘匿性に関しては提供されません。

図9 は、UDP と IPv4、そしてトンネル・モードの SA を使用した時に、 AH が IPパケットのどこに置かれるかを示したものです。

                     AH 適用前
            ----------------------------
      IPv4  | IP     | UDP    | データ |
            | ヘッダ | ヘッダ |        |
            ----------------------------

                     AH 適用後
            ------------------------------------------------
      IPv4  | 外側のIP | AH     | IP     | UDP    | データ |
            | ヘッダ   | ヘッダ | ヘッダ | ヘッダ |        |
            ------------------------------------------------
            |<-------------- 認証される範囲 -------------->|

	図 9. トンネル・モードにおける IPパケット内の AH の位置
AH のためにプロトコル番号 51 が IANA より割り当てられているので、 直前のヘッダの次ヘッダ番号には 51 が設定されます。

AH のヘッダは図10の通りです。

    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)                 |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

	図 10. AH ヘッダの構成
まず、AH の次に来るヘッダの番号(Next Header)、 AH のバイト単位の長さを 4 で割って 2 を引いた数が Payload Length として 置かれます。RESERVED は 0 で埋めなければいけません。 そして、SA を識別するための SPI、Anti-replay (※6)のための Sequence Number が置かれます。

最後に IP パケット全体に認証アルゴリズムを適用した結果のデータを Authentication Data (ICV)として置きます。 ESP と違い、ICV の計算対象には IPヘッダが含まれることに注目して下さい。 IP ヘッダの中には伝送途中に値が変わるフィールドが存在します。 これでは ICV を検査しても改纂されていたのか、 それとも正しい値なのか判断できません。 そのために AH では伝送途中に値が変わるフィールドは ICV の計算に 関係しないようにします。 この様なフィールドには以下の様なものがあります。

	IPv4:
		Type of Service (TOS)
		Flags
		Fragment Offset
		Time to Live (TTL)
		Header Checksum
	IPv6:
		Class
		Flow Label
		Hop Limit
		配送経路上変更可能ビットが立っているオプション
送信者は、ICV を計算するために、これらのフィールドを一時的に 0 で埋めてから 計算します。 受信者は、同様にして ICV を検査することで、 伝送途中にパケットが改纂されたことがわかります。

認証アルゴリズムと暗号アルゴリズム

ESP や AH でセキュリティを提供するための中核となるのが認証アルゴリズムと 暗号アルゴリズムです。 将来、より強いアルゴリズムが開発された時に、 使用しているアルゴリズムと交換できるように、 セキュリティプロトコルとは分離されて考えられています。

認証アルゴリズムは、MD5 (※7)等の一方向ハッシュと呼ばれる技術と HMAC と呼ばれる技術を組み合わせて(※8)、 元データから固定長のビットパターンを計算します。 このビットパターンとは、元となるデータの指紋とも呼ぶべきもので、

と言う性質を持っています。この特性を利用することにより、 送信した時と受信した時のビットパターンを比較して、 改纂されていたかを判断します。

ESP で使用される暗号アルゴリズムは、共有鍵暗号方式と呼ばれる方式が使用されます。 これは通信を行う 2 点間であらかじめ鍵を共有しておき、 送信者と受信者はその鍵を使って、データを暗号化、復号化します。 鍵を持っていない者がデータを取得しても、それを読むことが不可能になります。

ESP で使用可能で実装必須となる認証アルゴリズムは以下の通りです。

暗号アルゴリズムは、 この他にも、暗号アルゴリズムとして AH では、以下の通りです。 これらは、セキュリティプロトコルを選んだ後に、 それぞれに適切なアルゴリズムを選ぶことになります。

鍵管理

SA を構成するためのパラメータを管理する部分を鍵管理と呼びます。 SA を確立するためには、SA のパラメータを受信者が決めた後に、 送信者へ安全に渡すことが必要と前述しました。 この安全に渡すための枠組も鍵管理の範囲です。 鍵管理にはコマンドによるものと、デーモンによるものがあります。 次回は、この辺について詳しく説明していこうと思います。

捕捉

※1: ftp://ftp.isi.edu/internet-drafts/draft-ietf-ipsec-arch-sec-06.txt
※2: ftp://ftp.isi.edu/internet-drafts/draft-ietf-ipsec-esp-v2-06.txt
※3: ftp://ftp.isi.edu/internet-drafts/draft-ietf-ipsec-auth-header-07.txt
※4: ftp://ftp.isi.edu/in-notes/rfc1853.txt
※5: あるネットワークに対してセキュリティを提供しているゲートウェイのこと。
※6: 再送攻撃に対する耐性。詳しくは前回参照。
※7: ftp://ftp.isi.edu/in-notes/rfc1321.txt
※8: ftp://ftp.isi.edu/in-notes/rfc2104.txt
※9: ftp://ftp.isi.edu/in-notes/rfc2085.txt
※10: ftp://ftp.isi.edu/internet-drafts/draft-ietf-ipsec-auth-hmac-sha1-96-03.txt
※11: ftp://ftp.isi.edu/internet-drafts/draft-ietf-ipsec-ciph-des-expiv-02.txt
※12: ftp://ftp.isi.edu/internet-drafts/draft-ietf-ipsec-ciph-null-01.txt
※13: ftp://ftp.isi.edu/in-notes/rfc2144.txt
※14: ftp://ftp.isi.edu/in-notes/rfc2040.txt
第1回/ 第3回