"IPsec セミナールーム第3回" コンピュータ&ネットワークLAN 1998年10月号

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

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

1999/03/12 図3. の崩れを修正。

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

8 月に入って IPsec に関するドラフトの動きがありました。基本となる仕様を記述したドラフトのステータスを Proposed Standard にすると言う勧告が IESG (※1)から出されたのです。これにより IPsec をフルサポートしたルータやファイアウォールの製品化(※2)が一層加速し、より身近で使用される機会が増えることでしょう。さて、今回は前回説明できなかった鍵管理と IPsec の今後の動向を紹介します。

第3回鍵管理と IPsec の行方

鍵管理

セキュリティ・アソシエーション (以降 SA と略す)を確立するためには、 SA のパラメータを通信の受信者が決めた後に、送信者へ安全に渡す必要があることは前回説明しました。 IPsec アーキテクチャ(※3)では、この方法として手動鍵管理と自動鍵管理の 2 つを定義していて、どちらも実装必須としています。

手動鍵管理とは、フロッピディスクやマスターカードなどのネットワークを使った通信以外の手段を用いてパラメータを相手に伝えます。鍵管理の責任はパラメータをシステムに設定して管理する部分だけなので、実装も非常に単純で自動鍵管理に比べて簡単に実現できます。ただし以下のような場合、その使用に限界があります。

SA が多数確立される環境(※4)
SA の確立と消滅が頻繁にされる環境
再送攻撃に対する耐性 (以降 Anti-replay と称す) が必要な環境

ソケット単位のSAを必要としている環境では、新たなセッションが始まるたびにポート番号を含めてパラメータを交換しなけれならないので、手動鍵管理ではおよそ不可能です。またIPアドレス単位のSAでも、通信する計算機が増加すれば、それだけ管理する手間もかかるので限界があります。 IP Encapsulating Security Payload (以降 ESP と略す) (※5)や IP Authentication Header (以降 AH と略す) (※6)ではカウンタを使用して Anti-replay を実現しています。カウンタが 1 巡した時には SA を再設定することになっていますが、この手動鍵管理では自動で SA を設定することはできないので、 Anti-replay を利用できません。この管理方法の使用が想定される環境としては、ネットワークの管理者が 1 人またはごく小数人であるような小規模な組織や、ネットワーク的に動きの無い組織が考えられます。

自動鍵管理

ノートPCを持ち歩いて会社のファイアウォールと SA を確立し社内のホストと通信したい時や、 SA に期限を設け自動で消滅・確立できるようにしたり、前述した様に Anti-replay を望む場合は、自動でパラメータを交換出来る仕組みが必要になります。 IPsec アーキテクチャでは The Internet Key Exchange (以降 IKE と略す) (※7) と呼ばれる仕組みを実装必須としています。これ以外にも、Simple Key-Management For Internet Protocols (SKIP) (※8) や Photuris (※9) などがあります。また SNMPv2 を独自に拡張した方法を採用している製品もあります。

IKE

IKE は Internet Security Association and Key Management Protocol (以降 ISAKMP と略す) (※10) を基に定義されています。ISAKMP は、SA に関係するパラメータを、認証付きで交換するための枠組を定義したプロトコルです。交換される個々のパラメータは IPsec Domain Of Interpretation (DOI) (※11) により定義されています。また、実際に交換する時の基本的なアイデアは、 OAKLEY (※12) や SKEME (※13) から得ています。 IKE は UDP のポート番号 500 を使って通信し、 IPv4 と IPv6 の両方で利用でき、プロセスとして実装可能が可能です。また IKE の通信は IPsec をバイパスするので、自身の通信を保護するために IPsec で確立される SA とは別の SA (以降 IKE-SA と称す)を独自で確立する必要があります。以降 SA は ESP や AH が使用する SA を差し、IKE のための SA は IKE-SA と表すことにします。

図1は UNIX を想定した IKE の位置付けです。他のOSやルータでも基本的には変わりありません。

     +------------+        +--------+                +--------------+
     !     DOI    !        !        !                !  Application !
     ! Definition ! <----> ! ISAKMP !                !    Process   !
     +------------+    --> !        !                !--------------!
    +--------------+   !   +--------+                ! Appl Protocol!
    ! Key Exchange !   !     ^  ^                    +--------------+
    !  Definition  !<--      !  !                           ^
    +--------------+         !  !                           !
                             !  !                           !
            !----------------!  !                           !
            v                   !                           !
        +-------+               v                           v
        !  API  !        +---------------------------------------------+
        +-------+        !                Socket Layer                 !
            !            !---------------------------------------------!
            v            !        Transport Protocol (TCP / UDP)       !
     +----------+        !---------------------------------------------!
     ! Security ! <----> !                     IP                      !
     ! Protocol !        !---------------------------------------------!
     +----------+        !             Link Layer Protocol             !
                         +---------------------------------------------+

	図1. IKE の位置付け

アプリケーションがカーネルに送信要求をし、それを受けてカーネルは SA が確立されているか調べます。対応した SA が存在しない場合、カーネルは IKE にパラメータ交換を依頼します。 IKE は IKE-SA を用いて安全にパラメータを交換し、それをカーネルに設定します。

                             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
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        !                          Initiator                            !
        !                            Cookie                             !
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        !                          Responder                            !
        !                            Cookie                             !
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        !  Next Payload ! MjVer ! MnVer ! Exchange Type !     Flags     !
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        !                          Message ID                           !
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        !                            Length                             !
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

	図2. IKEヘッダ


                             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 Payload  !   RESERVED    !         Payload Length        !
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        !                             Data                              !
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

	図3. IKEペイロード

IKE パケットは、IKE ヘッダ(図2)とIKE ペイロード(図3)から構成され、 IKE ペイロードは、ヘッダ部とデータ部に分けられます。 IKE ヘッダの始動者用クッキーと応答者用クッキーは、通信している当事者同士のセッションを識別する重要なフィールドです。 IKE ヘッダと IKE ペイロードのヘッダ部には、次ペイロード・フィールドが存在し、各ペイロードを数珠つなぎにできます。次ペイロード・フィールドに 0 が指定されていれば、そのペイロードが最後であることを意味します。

重要なペイロードに、SA のパラメータを含む SA ペイロード、鍵交換のための情報を含む鍵交換(Key Exchange)ペイロード、乱数情報(Nonce)ペイロード、自己情報(Identification)ペイロード、認証情報(Hash)ペイロードがあります。

IKE はフェーズ 1 とフェーズ 2 に分けられます。フェーズ 1 では通信を安全にするために IKE-SA を確立し、フェーズ 2 では確立された IKE-SA の下で ESP や AH のための SA のパラメータを交換します。それぞれのフェーズの細かい説明は技術的に複雑なるので、ここでは簡単に紹介することにします。(※14)

フェーズ 1

フェーズ 1 は、IKE 同士の通信を安全にするために IKE-SA を確立するフェーズです。 SA を確立するためには、メイン・モードとアグレッシブ・モードの 2 つが定義されています。それぞれ、ISAKMP で定義される自己情報保護交換、アグレッシブ交換を使用しています。自己情報は、メイン・モードでは SA 確立後に交換されるので保護されるのですが、アグレッシブ・モードでは、SA が確立される前に交換するので保護されません。ただし、認証方式に公開鍵暗号を使用したときのみアグレッシブ・モードでも自己情報の保護が可能になります。またアグレッシブ・モードは、メイン・モードに比べて交換する回数が少ないため時間を短縮するためにも使用されます。鍵を計算するための元となる情報の交換には Diffie-Hellman 鍵交換方式を採用しています。認証方法として電子署名、公開鍵暗号、既知共有鍵の 3 つが定義されていて、通信する IKE 同士がどれか 1 つの使用を合意し使用します。

フェーズ 2

フェーズ 2 は、フェーズ 1 で確立された IKE-SA の下で、 ESP や AH の SA のパラメータを安全に交換するフェーズです。交換方式としてクィック・モードが定義されています。フェーズ 2 では、複数の SA の情報がやりとりされるため、それらを識別するために IKE ヘッダのメッセージ識別子(Mid)を使います。またフェーズ 1 の 2 つのモードとクィック・モードを識別するために、 IKE ヘッダの交換方式フィールドを使います。

API

さて手動鍵管理やIKEを使って交換されたパラメータは、なんらかの方法でカーネルに設定されなければ意味がありません。その方法の一つとして PF_KEY Key Management API, Version 2 (PFKEYv2) (※15) があります。 PFKEYv2 では socket インターフェイスを使ってデータをやりとりするので、カーネルと鍵管理部分を切り離して考えることが可能です。図4 は PFKEYv2 の位置付けです。

                     +---------------+
                     |Key Mgmt Daemon|
                     +---------------+
                       |           |
                       |           |
                       |           |                   Applications
               ======[PF_KEY]====[PF_INET]==========================
                       |           |                   OS Kernel
               +------------+   +-----------------+
               | Key Engine |   | TCP/IP,         |
               |  or  SADB  |---| including IPsec |
               +------------+   |                 |
                                +-----------------+
                                       |
                                   +-----------+
                                   | Network   |
                                   | Interface |
                                   +-----------+

	図4. PFKEYv2 の位置づけ

プロセスが通信をはじめる時、必要なセキュリティを定義したり、自身の認証情報を定義したいと思うかもしれません。この方法の一つとして Network Security API for Sockets (※16)があります。しかし、この仕様については議論が十分でなく、実装も少ないので、あくまでも候補という位置づけです。

ドラフトの動き

冒頭で紹介したように 8 月に入って IPsec のドラフトのステータスに嬉しい変更がありました。図5は Proposed Standard (※17)になるドラフトです。

Security Architecture for the Internet Protocol
draft-ietf-ipsec-arch-sec-07.txt
IP Authentication Header
draft-ietf-ipsec-auth-header-07.xt
The Use of HMAC-MD5-96 within ESP and AH
draft-ietf-ipsec-auth-hmac-md5-96-03.txt
The Use of HMAC-SHA-1-96 within ESP and AH
draft-ietf-ipsec-auth-hmac-sha196-03.txt
The ESP DES-CBC Cipher Algorithm With Explicit IV
draft-ietf-ipsec-ciph-des-expiv-02.txt
IP Encapsulating Security Payload (ESP)
draft-ietf-ipsec-esp-v2-06.txt
The Internet IP Security Domain of Interpretation for ISAKMP
draft-ietf-ipsec-ipsec-doi-10.txt
Internet Security Association and Key Management Protocol (ISAKMP)
draft-ietf-ipsec-isakmp-10.txt
The Internet Key Exchange (IKE)
draft-ietf-ipsec-isakmp-oakley-08.txt
The NULL Encryption Algorithm and Its Use With IPsec
draft-ietf-ipsec-ciph-null-01.txt

	図5. Proposed Standard になるドラフト一覧

図6 のドラフトは Informational (※17)になります。

IP Security Protocol Working Group to consider IP Security Document Roadmap
draft-ietf-ipsec-doc-roadmap-02.txt
The OAKLEY Key Determination Protocol
draft-ietf-ipsec-oakley-02.txt

	図6. Informational になるドラフト一覧

これらは謝辞などが書き加えられ RFC として世に送り出されます。

相互接続実験

IPsec がいよいよ標準化されつつあるなかで、せっかく多くの実装があっても相互接続ができないと、あまり嬉しくありません。ポリシーにより他機種との接続を嫌う組織や製品があるかもしれませんが、ユーザとしては何処にいても気にせず IPsec の恩恵を受けたいものです。そこで不定期ですが、実装している人達が集まって相互接続試験をしています。またオンラインでテストが可能なサイトもあります。

古いですが S/WAN (※18)はオンラインでテスト可能なサイトのひとつです。最近(※19)では Microsoft 社が主催したテストがシアトルで予定され 14 実装が参加することになっています。また 10 月後半には IBM が主催してニューヨークで行われます。日本では NTT社やKAME プロジェクト(※20)等が主催して行われました。 IKEのテストに特化したサイトとしては、 National Institute of Standards and Technology (※21)や SSH IPSEC interoperability test node (※22)があります。

今後の動向

仕様が標準化されたと言ってもテストが十分にされたわけではありません。恐らく来期位には IPsec 準拠とうたった製品が多数出てくることになると思いますが、実際には広域的に長期に渡って運用されていないので、細かな問題が発生する可能性が無いとはいえません。特に相互接続性が必要な環境や自動鍵管理を使った環境などでは確立は高いと思います。その時は機能限定でリリースされたり、運用でカバーするしかないかもしれません。

さらに次世代インターネットプロトコル (以降 IPv6 と略す) では IPsec は実装必須になっています。しかし IPv6 は開発途中のプロトコルです。 IPv6 上で IPsec を使用した場合の問題点は、IPv4 のそれよりも、さらに明らかになっていません。つまり目に見えない問題が残っている可能性があるのです。

8 月の後半に開催された第42回IETFの IPsec セッションでは、 IPsecond として今後 1 年の間で、モバイル環境における自動鍵管理の問題点や様々な組織のポリシーを IPsec にどう翻訳するか等を議論することになりました。ホテルのロビーを陣取って行われた IPsecond BOF では、 IKE フェーズ 1 の他のモードの必要性や接続してきた相手の認証方式について議論されました。

こうしてみると問題だらけと思われるかも知れませんが、しかし一方では便利になるのも事実です。 IPsec をサポートしたファイアウォールがあると、相互接続性があるので予算にあわせた製品の組合せが可能となり、部門間ファイアウォールやファイアクロス(Fire Cloth)として幅広く利用できます。

最後に

さて第3回を向かえた IPsec セミナールームですが、今回で最終回です。駆け足で説明してきましたが、概要を把握して頂ければ幸いです。このセミナーを読んで IPsec に興味が湧いた方はフリーな実装を手に入れて試してみる事をお勧めします。(※20) また、疑問に思ったことがあれば遠慮無くメールして頂ければ、わかる範囲でお答えしたいと思っています。それでは、またの機会に。