Comments
Description
Transcript
実証実験報告書
１３情経第１１７５号 電子政府情報セキュリティ技術開発事業 PKI 関連相互運用性に関する調査 PKI 環境下の IPsec 相互接続に関する調査 実証実験報告書 平成１４年 情報処理振興事業協会 セキュリティセンター 更新履歴 2002 年 8 月 2 日公開 目次 1. 概要 ............................................................................................................................................... 1 1.1. 背景 ..................................................................................................................................... 1 1.2. PKI 環境下の IPsec 相互接続性に関する問題概要.............................................................. 1 2. 実験環境 ........................................................................................................................................ 2 2.1. 実験参加 VPN 装置 ............................................................................................................. 2 2.2. 実験ネットワーク構成 ............................................................................................................ 3 3. 実験概要 ........................................................................................................................................ 4 3.1. VPN 装置の PKI に関するサポートパラメータ調査 ............................................................... 4 3.2. オフライン証明書取得時の動作確認実験 .............................................................................. 5 3.3. 電子署名認証方式の IPsec 相互接続実験............................................................................ 6 4. 実験結果 ........................................................................................................................................ 7 4.1. VPN 装置の PKI に関するサポートパラメータ調査 ............................................................... 7 4.2. オフライン証明書取得時の動作確認実験 .............................................................................. 7 4.3. 電子署名認証方式の IPsec 相互接続実験...........................................................................11 5. まとめ.......................................................................................................................................... 21 5.1. はじめに ............................................................................................................................. 21 5.2. 実験考察 ............................................................................................................................ 21 5.2.1. オフライン証明書取得時の動作確認実験 ..................................................................... 21 5.2.2. 電子署名認証方式の IPsec 相互接続実験................................................................... 22 5.3. PKI 環境下における IPsec 相互接続の問題点 ................................................................... 27 5.3.1. 証明書に含まれる項目について ................................................................................... 27 5.3.2. 証明書の失効.............................................................................................................. 29 5.3.3. IKE（Internet Key Exchange）......................................................................................... 30 5.3.4. 証明書の検証.............................................................................................................. 31 5.3.5. 階層 CA 環境での VPN 装置 ...................................................................................... 33 i 1. 概要 1.1. 背景 政府は、2003 年までに行政手続きを電子化する電子政府基盤を構築することを目指している。 個人情報を扱う電子政府において、情報セキュリティ対策は必要不可欠な分野である。電子政府 の根幹をなす重要なセキュリティ技術として PKI があり、日本政府においても GPKI の整備が着々 と進められている。 一方、企業では近年のインターネット接続料金の低廉化、ブロードバンド化に伴い、インター ネットの高度利用が促進されている。インターネットを使用した Virtual Private Network (以 下 VPN)もその一つであり、企業の新たな通信インフラとして定着しつつある。 IPsec はネットワーク層でセキュリティ保護を実現するため、上位層のアプリケーションや下 位層のネットワーク構成に依存する事無くセキュアな通信を行う際に使用できる汎用性の高い プロトコルであり、インターネットを使用した VPN では最も使用されているプロトコルであると ともに、電子政府でも使用されうるセキュリティプロトコルの一つである。また、IPsec は電子 署名による通信相手認証の機能が標準化されており、すでに多くの VPN 装置に実装されているこ とから、電子政府を始めとする PKI 環境下で使用されるセキュリティアプリケーションの一つと もいえる。 行政サービスや企業間で IPsec を使用してセキュアな通信を行う際には、それぞれの組織で自 由に IPsec を用いて VPN を構築するための装置(以下 VPN 装置と呼ぶ)を選択できなければならな いため、異機種間接続は必須と考えられる。しかし、VPN 装置はメーカによって標準の解釈に異 なる箇所があることは既に明白であり、これらを解消する為に多くの相互接続実証実験が実施さ れてきたが、PKI 環境下での相互運用性の実証実験はほとんど実施されてこなかった。 本報告書は、情報処理振興事業協会（IPA）が 「電子政府情報セキュリティ技術開発事業」の 一環として実施した「PKI 関連相互運用性に関する調査」について、公募の結果採択された NPO 日本ネットワークセキュリティ協会（JNSA）に委託した調査をまとめたものである。具体的には、 「PKI 関連相互運用性に関する調査」のうち「PKI 環境下の IPsec 相互接続に関する調査」の実 験結果について報告するものである。本調査では、PKI 環境下の VPN 装置の相互接続性を実証実 験を通して確認するとともに、PKI 環境下で VPN を構築する際の VPN 装置選定および、運用手順 書作成上の参考となる情報の提供を目的とした。 1.2. PKI 環境下の IPsec 相互接続性に関する問題概要 IPsec はネットワーク層でセキュリティ保護を行う技術であり、認証／暗号／改竄防止のセキ ュリティ保護機能を提供する。認証や暗号方式，改竄防止手順などは、IPsec 通信に先立ちそれ ぞれの VPN 装置で折衝される必要がある。IPsec ではこれらの機能を IKE と呼ばれるプロトコル に任せている。IPsec の相互接続性の問題のほとんどが、この IKE の実装が製品によって異なる ことに起因している。 IPsec を PKI 環境下で運用する時には、IKE の認証機能で電子署名認証方式を使用することに なる。これまで数多く実施されてきた IPsec 相互接続実験は既知共有鍵認証方式を使用しており、 電子署名認証方式を使用した実験はほとんど実施されてきていないのが現状である。したがって、 本実験では相互接続性の確認を通して、各 VPN 装置の IKE 実装の差異を明らかにするとともに、 各 VPN 装置の PKI に関する実装の差異を明らかにするために以下の実験を実施した。 (１) VPN 装置の PKI に関するパラメータ調査 (２) オフライン証明書取得時の動作確認実験 (３) 電子署名認証方式の IPsec 相互接続実験 1 2. 実験環境 2.1. 実験参加 VPN 装置 実験対象はすでに市販または、一般に公開されているハードウェアかソフトウェアであり、公 募に応じて供給元から実験参加の意思表明があったものとする。 以下の表は実際に参加表明が行われたもののリストである。開発・製造元および参加企業の名 称については略称で記載した。 実験参加機器VPN装置 No 製品名 Version 開発・製造元 1 VPN-1 Solaris v5.0 FP1 Checkpoint 2 3 4 5 VPN-1 Windows2000 VPN-1 Linux NOKIA IP Series RapidStream / Checkpoint v5.0 FP1 v5.0 FP1 v5.0 FP1 v5.0 FP1 Checkpoint Checkpoint NOKIA Rapid Stream 6 RapidStream Security Appliance v3.0.2 Rapid Stream 7 8 9 10 11 12 13 14 15 16 17 ※1 ※2 NetScreen Contivity VPN Switch Cryptopia100 VPN3000 AR720 ※1 参加企業 新日鉄ソリューションズ ソフトバンクコマース ソフトバンクテクノロジー 同上 同上 同上 ジェイズ・コミュニケーション エヌ・シ−・エル・コミュニケ−ション ジェイズ・コミュニケーション ジェイズ・コミュニケーション ネットワンシステムズ 三菱電機 ネクストコム アライドテレシス ヒューコム 工学院大学 LINCS ディアイティ ディアイティ ネットマークス SSH Communications Security v3.00R2 NetScreen v03_60.45 Nortel Networks v2.2.2 三菱電機 v3.5.2 Cisco Systems v2.3.2 アライドテレシス v7.0 Intel NetStructure VPN KAME (Racoon) 20011215a Free Alcatel (旧 TimeStep） 713X Secure VPN Gateway Series(Offline) ※2 v3.11.021 713X Secure VPN Gateway Series(Entrust) v3.11.021 Alcatel (旧 TimeStep） VPN VSU Systeme v3.1.60 AVYA (旧 VPNet） IPSEC Express Toolkit v4.2 SSH AR720 v2.3.2はテストファーム(実験結果は参考データ扱い) Alcatel 713X Secure VPN Gateway Series(Offline)は参考出品（実験結果は参考データ扱い） 実験使用CA No 1 2 3 4 製品名 SSH Certifier Entrust Authority Easy Cert 未発表製品 Version v2.0.4 v5.0 v090b - 開発・製造元 SSH Communication Security Entrust 名古屋工業大学 富士ゼロックス/富士ゼロックス情報システム 2 2.2. 実験ネットワーク構成 相互接続の実験を行うには多くの VPN 装置が要求される。実際に VPN 装置を使用する環境は、 Internet などの WAN 回線を介して使用されるのが一般的だが、これまでの経験上ローカルで得ら れた実験結果と Internet などの WAN を使用して実験で得られる結果に相違無い事が分かってい るため、実験環境はローカルとした。また、今回の実験では、運用に耐えうるシステムを構築す る際に必要となる技術およびノウハウを収集する為に、最低限必要となるネットワーク構成とし た。 サーバ クライアント クライアント IPSecGateway CA IPSecGateway Shared HUB アナライザ CA CA 3 ディレクト リ サーバ 3. 実験概要 今回の実験では多くの VPN 装置が公募により参加したため、実験を効率的に進める目的で VPN 装置および CA にリファレンスを設けた。VPN 装置のリファレンスの決定については、昨年度実施 した IPsec 相互接続実験の結果と、IKE の各種パラメータを自由に変更できる点を考慮し、SSH コミュニケーションズ・セキュリティ社の IPSEC Express Toolkit を選択した。（一部の実験に ついては、Checkpoint VPN-1 をリファレンス機に設定） また CA については、VPN 装置が CA をエンロールする際に使用する、CMP や SCEP などをサポー トし、発行する証明書の有効期限が最も短い時間を設定できる事を考慮し、SSH コミュニケーシ ョンズ・セキュリティ社の Certifier を選択した。 3.1. VPN 装置の PKI に関するサポートパラメータ調査 各 VPN 装置がサポートする PKI 関連のパラメータは、マニュアル等の製品資料を確認する事で 概ね判明するが、相互接続を行う上で確認が必要なパラメータについては製品資料には記載され ていない事が多い。今回のパラメータ調査では、製品資料で分からない項目については、以降の 実験によってサポートしているパラメータを明らかにした。 下記に今回調査した調査項目とその概要を示す。 (１) 証明書取得方法に関する項目 ① 証明書を CA に申請する方法 証明書発行申請の方法は従来の PKCS#10 で行うか、CPM や SCEP 等のネットワークを介し て行うかを確認。 ② 証明書を申請する際に VPN 装置側で入力する情報 通常 VPN 装置で PKCS#10 の発行要求を生成する際には、証明書の所有者である Subject （DN）を最低限設定する必要がある。ここでは DN を設定する際に設定可能な項目を調 査。 ③ 証明書に必要な情報または制限 CA から発行される証明書に必ず含まれていなければならない項目を調査。 ④ 複数証明書のサポート 複数の証明書を VPN 装置にエンロール可能かどうかを確認。また併せて Peer 毎に証明 書使い分けることが可能かどうかを実験にて確認 ⑤ 証明書の相手ごとの登録可否 同一 CA から複数の証明書が発行された場合に、VPN 装置に複数の証明書がエンロール可 能かどうかを確認。 ⑥ IKE ネゴシエーション時の証明書ユーザ確認方法 Peer から送信されてくる証明書を、どの属性を使用して検証しているかを確認。 (２) 公開暗号鍵に関する項目 ① 使用可能な RSA 鍵長 各 VPN 装置が生成可能な鍵長を確認。 ② 鍵のバックアップおよびリカバリ方法 秘密鍵のバックアップが可能かどうかを調査し、可能である場合はどのような形でバッ クアップを行うか確認。 ③ サポートしているハードウェアトークン ハードウェアトークンをサポートしているかを調査し、サポートしている場合は具体的 な製品名を確認。 4 (３) CA 登録に関する項目 ① 複数のルート CA の登録可否 複数の CA から発行される VPN 装置の証明書をエンロールする為の前提条件となる複数 のルート CA が登録可能かどうかを確認。 ② 中間 CA の登録可否 階層 CA やブリッジ CA 環境下で使用される CA の相互認証証明書を登録可能かどうかを 確認。 ③ CA のポリシー毎の登録可否 Peer 毎に CA の登録が可能かどうかを確認。 (４) 証明書有効期限に関する項目 ① 証明書の有効期限が切れた時の動作 VPN 装置にエンロールした証明書が有効期限切れになった際の動作を確認。 ② CRL のサポート 証明書の失効検証を行う CRL のサポートしているかどうかを確認。 ③ CRL を取得するときのプロトコル CRL を取得する際に使用するプロトコルを確認すると同時に、各 VPN 装置がサポートし ている CRLDP のフォーマットについて確認。 ④ CRL 以外の失効検証方法 OCSP などの CRL 以外の失効検証をサポートしているか確認。 ⑤ CRL チェックのタイミング VPN 装置が通信を行う際に、どのタイミングで失効検証を行っているか確認。 ⑥ CRL チェックのスキップ CRL を使用して失効検証を行っている VPN 装置において、失効検証をスキップ可能かど うかを確認。 3.2. オフライン証明書取得時の動作確認実験 オフライン証明書取得とは、今回の実験での便宜上の名称であり、広く一般に使用されている ものでは無い。この実験で定義しているオフライン証明書取得とは、PKCS#10 証明書発行要求を 生成し PKCS#7 でエンコードされた証明書を VPN 装置にエンロールする方法をいう。この実験で は、オフラインでの証明書の取得と、それに関連する下記項目について実験をおこなった。 (１) 証明書取得 オフライン証明書取得では使用する CA によって発行された証明書エンコード形式が異な る事が考えられる。この実験では、各 VPN 装置で証明書発行要求を作成してから、証明書を VPN 装置にエンロールするまでの一連の動作を行い、正常に証明書をエンロール可能である ことを確認するとともに、各 VPN 装置でエンロールが可能な証明書エンコード形式を確認す る。 (２) 証明書有効期限に関する動作 証明書には有効期限があるため、VPN 装置にエンロールした証明書も何時かは有効期限が 切れてしまう。自動的に証明書を更新するのが理想であるが、オフラインで取得した証明書 では自動更新は不可能である。この実験ではオフラインで取得した証明書の有効期限が切れ た際に、VPN 装置がどのようにして有効期限が切れたことを管理者に通知するかを確認する とともに、証明書の有効期限が切れたことによって、VPN 装置が異常な動作を起こさないか を確認する。 (３) CRL 取得方法確認 VPN 装置の証明書失効検証は CRL を使用する VPN 装置がほとんどである。CRL の取得方法や 5 更新タイミングは VPN 装置を実際に運用する際には大きな課題となるが、製品資料には明確 に記述されていない事が多い項目の一つである。今回の実験では CRL の取得方法と更新のタ イミングについて確認する。 3.3. 電子署名認証方式の IPsec 相互接続実験 電子署名認証方式を使用した VPN 装置の相互接続性確認実験は、これまでほとんど実施されて 来ていなかった。 この実験では、単一 CA から発行された証明書を使用し相互接続性を確認するほか、実際の運 用時に発生し得る証明書の「有効期限切れ」や「失効」された状況をつくり通信状態の確認を行 う。また、複数の CA を使用し各 VPN 装置の複数 CA への対応状況を確認する。 (１) 電子認証方式の相互接続性の確認 リファレンス CA から発行された証明書を各 VPN 装置にエンロールした環境で、各 VPN 装 置の相互接続性を確認する。また、VPN 装置の相互接続の際に必ず問題となる Re-Key 時の 動作も併せて確認する。 (２) 証明書失効時の相互接続性の確認 通信相手の証明書や自己の証明書が失効された際には、ネゴシエーション時の認証で証 明書が失効されている事を検知する必要がある。この実験では、最初に通信相手の証明書 が失効されている時に、それを検知できるかどうかを確認し、次に自己の証明書が失効さ れている時にどのような動作をするかどうかを確認する。 (３) 証明書有効期限切れ時の相互接続性確認 通信相手の証明書や自己の証明書の有効期限が切れている際には、ネゴシエーション時 の認証で証明書の有効期限が切れていることを検知する必要がある。この実験では最初に 通信相手の証明書の有効期限が切れている時に、それを検知できるかどうかを確認し、次 に自己の証明書の有効期限が切れている時にどのような動作をするかを確認する。 (４) 複数 CA への対応確認 １台の VPN 装置を、複数の組織に属する VPN で使用する場合、複数の CA に対応する必要 がある。この実験では、各 VPN 装置が複数の CA から発行された証明書をエンロール可能か どうかを確認するとともに、各 CA から発行された証明書を通信相手ごとに使い分ける事が 可能かどうかを確認する。 6 4. 実験結果 4.1. VPN 装置の PKI に関するサポートパラメータ調査 3.1 VPN 装置の PKI に関するサポートパラメータの各項目を調査した。 （調査結果は付録２を参照） 4.2. オフライン証明書取得時の動作確認実験 実験ではリファレンス CA を使用して各 VPN 装置に証明書を発行した。使用した証明書のプロ ファイルは付録 1 を参照。 また今回実験に参加した VPN 装置のうち、Intel NetStructure VPN および、Alcatel Secure VPN Gateway(Entrust)は、オフライン証明書取得には対応していない為、実験を行う事が出来なかっ た。それ以外の参加 VPN 装置の実験結果を以下に示す。 （１） 証明書取得 証明書取得の一連の動作について下記項目にいて確認した結果、実験を実施した全ての VPN 装置で問題は発生しなかった。しかし、VPN 装置に証明書をエンロールする際の証明書 エンコード形式については差異が確認できた。 CA から発行された証明書が VPN 装置のサポートするエンコード形式ではない場合、 Internet Explorer 等を使用しエンコード形式を変換する事で対応が可能であった。（結果 一覧表 表 4-1-(1) 証明書取得実験結果） 確認項目 （i） PKCS #10 証明書リクエストを作成 （ii） CA が証明書リクエストに対し証明書が発行できたか （iii）証明書は VPN 装置にエンロールできたか （iv） VPN 装置にエンロールした証明書は期待通りの内容か 7 表 4-1-(1) 証明書取得実験結果 チェック項目 No 製品名 PKCS#10 ﾘｸｴｽﾄ作成 ﾘｸｴｽﾄに対する 証明書発行 1 VPN-1 Solaris ○ ○ 2 VPN-1 Windows2000 ○ ○ 3 VPN-1 Linux ○ ○ 4 NOKIA IP Series ○ ○ 5 RapidStream / Checkpoint ○ ○ 6 RapidStream Security Appliance ○ ○ 7 NetScreen ○ ○ 8 Contivity VPN Switch ○ ○ 9 Cryptopia100 ○ ○ ○ ○ 10 VPN3000 11 AR720 ○ ○ 証明書ｴﾝﾛｰﾙ (証明書ｴﾝｺｰﾄﾞ形 式) ○ （DER/PEM/PKCS#7） ○ （DER/PEM/PKCS#7） ○ （DER/PEM/PKCS#7） ○ （DER/PEM/PKCS#7） ○ （DER/PEM/PKCS#7） ○ （PEM） ○ （PEM) ○ （DER/PEM/PKCS#7） ○ （DER/PEM/PKCS#7） ○ （DER/PEM/PKCS#7） ○ （DER/PEM） 試験対象外 12 NetStructure VPN 13 KAME (Racoon) ○ ○ 14 Secure VPN Gateway Series(Offline) ○ ○ 16 VPN VSU Systeme ○ ○ 17 IPSEC Express Toolkit ○ ○ ○ ○ （PKCS#7） 8 ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ※2 ○ （PEM) ○ （DER/PEM/PKCS#7） ※１ ：SCEPによるエンロールのみをサポートしているため試験対象外とした。 ※2 ：EntrustReady方式によるエンロールのみをサポートしているため試験対象外とした。 ○ ※1 （PEM） 試験対象外 15 Secure VPN Gateway Series(Entrust) 証明書の内容 ○ ○ （２） 証明書有効期限に関する動作 エンロールした証明書の有効期限が切れた際の動作として、期限切れを LOG 表示する VPN 装 置がほとんどであった。また有効期限切れが原因で、異常動作を起こす物はなかった事が確 認できた。 （結果一覧表 表 4-1-(2) 証明書取得実験結果） 表 4-1-(2) 証明書有効期限に関する動作実験結果 No 製品名 有効期限切れ間近 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 有効期限切れ 異常動作 VPN-1 Solaris 有効期限30日前からLog表示 Log表示 なし VPN-1 Windows2000 有効期限30日前からLog表示 Log表示 なし VPN-1 Linux 有効期限30日前からLog表示 Log表示 なし NOKIA IP Series 有効期限30日前からLog表示 Log表示 なし RapidStream / Checkpoint 有効期限30日前からLog表示 Log表示 なし RapidStream Security Appliance なし なし なし NetScreen なし なし なし Contivity VPN Switch なし Log表示 なし Cryptopia100 なし Log表示 なし VPN3000 なし Log表示 なし AR720 なし なし なし 試験対象外 ※1 NetStructure VPN KAME (Racoon) なし なし 停止※3 SecureVPN Gateway Series （OffLine) なし Log表示 なし ※2 試験対象外 SecureVPN Gateway Series（Entrust) VPN VSU Systeme なし Log表示 なし IPSEC Express Toolkit なし Log表示 なし ※1 ：SCEPによるエンロールのみをサポートしているため試験対象外とした。 ※2 ：EntrustReady方式によるエンロールのみをサポートしているため試験対象外とした。 ※3 ：Seucure VPN Gateway Series(Offline)はエンロールされた証明書の有効期限が切れると 停止する仕様となっているため、異常動作ではない。 9 （３） CRL 取得方法の確認 CRL の扱いは VPN 装置によって大きく異なることが確認できた。実験結果より手動で CRL ファイルを更新する VPN 装置では、CRL の有効期間も無視するため失効検証に問題が発生す る可能性がある。 （結果一覧表 表 4-1-(2) 証明書取得実験結果） 4-1-(3) CRL 取得方法の確認実験 No 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 ※１ ※2 製品名 CRL取得プロトコル CRL更新 ・機器起動時 VPN-1 Solaris LDAP，http ・ｷｬｯｼｭﾀｲﾑｱｳﾄ後のﾈｺﾞｼｴｰｼｮﾝ時 ・ｷｬｯｼｭを使用しない場合は、ﾈｺﾞｼｴｰｼｮﾝ時に ・機器起動時 VPN-1 Windows2000 LDAP，http ・ｷｬｯｼｭﾀｲﾑｱｳﾄ後のﾈｺﾞｼｴｰｼｮﾝ時 ・ｷｬｯｼｭを使用しない場合は、ﾈｺﾞｼｴｰｼｮﾝ時に ・機器起動時 VPN-1 Linux LDAP，http ・ｷｬｯｼｭﾀｲﾑｱｳﾄ後のﾈｺﾞｼｴｰｼｮﾝ時 ・ｷｬｯｼｭを使用しない場合は、ﾈｺﾞｼｴｰｼｮﾝ時に ・機器起動時 NOKIA IP Series LDAP，http ・ｷｬｯｼｭﾀｲﾑｱｳﾄ後のﾈｺﾞｼｴｰｼｮﾝ時 ・ｷｬｯｼｭを使用しない場合は、ﾈｺﾞｼｴｰｼｮﾝ時に ・機器起動時 RapidStream / Checkpoint LDAP，http ・ｷｬｯｼｭﾀｲﾑｱｳﾄ後のﾈｺﾞｼｴｰｼｮﾝ時 ・ｷｬｯｼｭを使用しない場合は、ﾈｺﾞｼｴｰｼｮﾝ時に ・手動でCRLを機器にｲﾝｽﾄｰﾙした場合は、手動で更 RapidStream Security Appliance 手動，LDAP 新 ・ﾈｺﾞｼｴｰｼｮﾝ時にCRLDP参照 NetScreen LDAP，http （使用上httpもｻﾎﾟｰﾄされているが、httpではCRLDP を参照不可であった。） ・指定した時間間隔で取得 Contivity VPN Switch LDAP ・Peerの証明書がRevokeされてた場合、ﾈｺﾞｼｴｰｼｮﾝ 時に再取得 Cryptopia100 手動 手動でﾌｧｲﾙを更新 ・機器起動時 VPN3000 LDAP，http ・CRL有効期間後 ・機器起動時 AR720 LDAP ・指定した時間間隔で取得 試験対象外 ※1 NetStructure VPN KAME (Racoon) CRLを使用しない CRLを使用しない SecureVPN Gateway Series（OffLine) 手動 手動でﾌｧｲﾙを更新 試験対象外 ※2 SecureVPN Gateway Series（Entrust) VPN VSU Systeme 手動 手動でﾌｧｲﾙを更新 IPSEC Express Toolkit LDAP，http ・ﾈｺﾞｼｴｰｼｮﾝ時にCRLDP参照 ：SCEPによるエンロールのみをサポートしているため試験対象外とした。 ：EntrustReady方式によるエンロールのみをサポートしているため試験対象外とした。 10 4.3. 電子署名認証方式の IPsec 相互接続実験 （１） 電子署名方式の相互接続性確認 実験は下記のパラメータを使用し、それぞれの組合せで実験対象機がイニシエータとなっ た場合とレスポンダとなった場合の両方向の通信を Ping を使用して確認した。また、通信 確認においては、Re-Key が発生するまで Ping を継続し、Re-Key による通信断の有無までを 確認した。 また、実験はリファレンス CA から発行された証明書を使用したため、Alcatel Secure VPN Gateway（Entrust）は実験には参加できなかった。 【パラメータ】 Phase1:MainMode z 暗号アルゴリズム z Hash アルゴリズム z Group Description z 認証アルゴリズム z Life Duration ：3DES ：SHA-1 ：DH-Group2(1024bit) ：Digital Signature ：10 分 Phase2:QuickMode z 暗号アルゴリズム z Hash アルゴリズム z PFS z 認証アルゴリズム z ペイロード z Life Duration ：3DES ：SHA-1 ：DH-Group2(1024bit) ：HMAC-SHA1 ：ESP ：5 分 実験結果一覧表の縦軸に対応する製品がイニシエータを示し、横軸はレスポンダであるこ とを示す。したがって、それぞれの VPN 装置を示した交差する箇所が実験結果を表している。 結果から、ほとんど組合せで相互接続性が確保されていることが確認できた。しかし一部 の組合せで接続できない事が確認された。 （既知共有鍵認証方式では接続可能） 。原因は一方 の VPN 装置が証明書要求ペイロードを送信するタイミングが他の VPN 装置とは異なる為であ った。 また、一部の組合せで Re-key 時に問題が発生することが確認できた。Re-key については 未だ標準が定まっていないため、 Re-key 時の各製品の動作が異なる事が原因と考えられる。 （結果一覧表 表 4-3-(1) 電子署名方式の相互接続性確認実験結果） 11 表 4-3-(1) 電子署名方式の相互接続性確認実験結果 2 3 4 ○ ○ ○ 1 VPN-1 Solaris ○ ○ ○ 2 VPN-1 Windows2000 ○ ○ ○ 3 VPN-1 Linux ○ ○ ○ 4 NOKIA IP Series ○ ○ ○ ○ 5 RapidStream/Checkpoint ○ ○ ○ ○ 6 RapidStream ○ ○ ○ ○ 7 NetScreen ○ ○ ○ ○ 8 Nortel Contivity VPN Switch ○ ○ ○ ○ 9 三菱電機 Cryptopia100 ○ ○ ○ ○ 10 Cisco VPN3000 ○ ○ ○ ○ 11 アライドテレシス AR720 ○ ○ ○ ○ 12 Intel NetStructure ○ ○ ○ ○ 13 KAME (Racoon) 14 SecureVPN Gateway Series(Offline) ○ ○ ○ ○ ○ ○ ○ ○ 15 AVYA VSU ○ ○ ○ ○ 16 ssh IPSEC Express Toolkit ○：通信可能（Phase-1/2 Re-Keyによる通信断無し） △：通信は可能だが、Re-Key時に問題が発生 ×：通信不可 Initiator No 製品名 1 12 Responder 8 9 10 ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ × ○ △ ○ ○ ○ ○ ○ △ ○ ○ × ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ × ○ ○ ○ ○ ○ 5 ○ ○ ○ ○ 6 ○ ○ ○ ○ ○ 7 ○ ○ ○ ○ ○ × 11 ○ ○ ○ ○ ○ ○ ○ ○ ○ 12 ○ ○ ○ ○ ○ ○ 13 ○ ○ ○ ○ ○ ○ 14 ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ × ○ ○ × ○ ○ ○ ○ ○ ○ 15 ○ ○ ○ ○ 16 ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ （２） 証明書失効時の相互接続性の確認 実験はリファレンス VPN 装置を使用して実施した。また実験は通信相手である「リファレ ンス VPN 装置の証明書を失効した時の相互接続性確認」、 「実験対象機の証明書を失効した時 の相互接続性確認」に分け実施した。 ① リファレンス VPN 装置証明書失効時の相互接続性確認 リファレンス VPN 装置の証明書を失効したうえで、実験対象機のクライアントから通信 を行った。この実験では、ネゴシエーション時に実験対象機でリファレンス VPN 装置の証 明書が失効されていることを検知可能であるかどうかを確認した。 実験結果から、実験を実施したほとんどの VPN 装置でリファレンス VPN 装置の証明書が 失効を検知出来ることが確認できた。この結果より、通信相手の証明書が失効されている 時には通信が行えないことが確認できた。 （結果一覧表 表 4-3-(2)-1 ﾘﾌｧﾚﾝｽ機証明書失効時の相互接続確認実験結果） ② 実験対象機の証明書失効時の相互接続性確認 実験対象機の証明書を失効したうえで、実験対象機のクライアントから通信を行った。 この実験では実験対象機が自己の証明書の失効検証を行っている事を確認した。 実験の結果から、自己の証明書の検証を行っている VPN 装置が少ないことが判明した。 通信相手が失効検証を行う事で、通信を行う事はできないと考えられるが、CRL を自動更 新しない製品との相互接続環境では運用上注意が必要である。 （結果一覧表 表 4-3-(2)-2 実験対象機の証明書失効時の相互接続性確認） 13 表 4-3-(2)-1 リファレンス VPN 装置証明書失効時の相互接続性確認実験結果 No 製品名 1 VPN-1 Solaris 2 VPN-1 Windows2000 3 VPN-1 Linux 4 NOKIA IP Series 5 RapidStream/Checkpoint 6 RapidStream 7 NetScreen 8 Nortel Contivity VPN Switch 9 三菱電機 Cryptopia100 10 Cisco VPN3000 11 アライドテレシス AR720 12 Intel NetStructure 13 KAME (Racoon) 14 SecureVPN Gateway Series(Offline) リファレンス機の エラー送信の有 証明書失効検証 失効検知した際のLOG表示 無 の有無 yes yes Invalid Certificate：Peer Certificate Revoked yes yes Invalid Certificate：Peer Certificate Revoked yes yes Invalid Certificate：Peer Certificate Revoked yes yes Invalid Certificate：Peer Certificate Revoked yes yes Invalid Certificate：Peer Certificate Revoked yes yes yes no PKI error:Invalid X509 Certificate yes yes Invalid cRL extensions yes yes CRL Revoked yes yes ISAKAMP certificate u0 found to be revoked yes no in CRL (u0はPeerの証明書を示す） no Invalid Certificate yes yes The Certificate does't have an issure 15 AVYA VSU 16 ssh IPSEC Express Toolkit yes 失効検証の有無 yes:：証明書失効検証を行い、ネゴシエーション中断 no：証明書失効検証を行わない エラー送信の有無 yes：IKE Nortificationを送信 no：IKE Nortificationを送信しない yes 14 Invalid Certificate 表 4-3-(2)-2 実験対象機の証明書失効時の相互接続性確認 自己の証明書の エラー送信の有 失効検知した際のLOG表示 No 製品名 失効検証の有無 無 1 VPN-1 Solaris no no 2 VPN-1 Windows2000 no no 3 VPN-1 Linux no no 4 NOKIA IP Series no no 5 RapidStream/Checkpoint no no 6 RapidStream no no 7 NetScreen no no 8 Nortel Contivity VPN Switch no no 9 三菱電機 Cryptopia100 yes no My Cert is revoked 10 Cisco VPN3000 no no 11 アライドテレシス AR720 yes no 12 Intel NetStructure 13 KAME (Racoon) no no 14 SecureVPN Gateway Series(Offline) no no 15 AVYA VSU 16 ssh IPSEC Express Toolkit no 失効検証の有無 yes：証明書失効検証を行いネゴシエーションを行わない no：証明書失効検証を行わない(ネゴシエーションを行う） エラー送信の有無 yes：IKE Nortificationを送信 no：IKE Nortificationを送信しない 15 （３） 証明書有効期限切れ時の相互接続性の確認 実験はリファレンス VPN 装置を使用して実施した。また実験は通信相手である「リファレ ンス VPN 装置の証明書の有効期限が切れた時の相互接続性確認」と、「実験対象機の証明書 が有効期限切れとなった時の相互接続性確認」に分け実施した。 ① リファレンス VPN 装置証明書有効期限切れ時の相互接続性確認 リファレンス機に有効期間 10 分の証明書をエンロールし、有効期限が切れたことを確 認してから実験対象機のクライアントから通信を行った。この実験ではネゴシエーション 時に実験対象機がリファレンス VPN 装置の証明書が有効期限を経過していることを検知可 能であるかどうかを確認した。 実験結果から実験を実施した全ての VPN 装置が証明書の有効期限経過を検知することが 確認できた。この結果より、通信相手の証明書の有効期限が切れているときには通信が行 えないことが確認できた。 （結果一覧表 表 4-3-(3)-1 ﾘﾌｧﾚﾝｽ機証明書有効期限切れの相互接続性確認） ② 実験対象機証明書有効期限切れ時の相互接続性確認 実験対象機で有効期間 10 分の証明書をエンロールし、有効期限が切れたことを確認し てから実験対象機のクライアントから通信を行った。この実験では実験対象機が自己の証 明書の有効期限が切れた際にネゴシエーションを起動するかどうかを確認した。 実験の結果から自己の証明書の有効期限確認を行っている VPN 装置が予想以上に少ない ことが判明した。しかし、通信相手が証明書の有効期限を確認することで通信を行うこと は出来ないため、セキュリティ上の問題が発生することは少ないと考えられる。 （結果一覧表 表 4-3-(3)-2 実験対象有効期限切れ時の相互接続性確認） 16 表 4-3-(3)-1 リファレンス VPN 装置証明書有効期限切れの相互接続性確認 No 製品名 1 VPN-1 Solaris 2 VPN-1 Windows2000 3 VPN-1 Linux 4 NOKIA IP Series 5 RapidStream/Checkpoint 6 RapidStream 7 NetScreen 8 Nortel Contivity VPN Switch 9 三菱電機 Cryptopia100 10 Cisco VPN3000 11 アライドテレシス AR720 リファレンス機の エラー送信の有 失効検知した際のLOG表示 証明書有効期限 無 切れ検知 yes yes Invalid Certificate yes yes Invalid Certificate yes yes Invalid Certificate yes yes Invalid Certificate yes yes Invalid Certificate yes yes yes no yes yes AUTHENTICATION FAILED yes yes Certificate Expire yes yes certificate u0 has expired yes no (u0はPeerの証明書を示す） yes yes yes yes The Certificate has expired 12 Intel NetStructure 13 KAME (Racoon) 14 SecureVPN Gateway Series(Offline) 15 AVYA VSU 16 ssh IPSEC Express Toolkit yes 失効検証の有無 yes:：証明書有効期限検証を行い、ネゴシエーション中断 no：証明書有効期限検証を行わない エラー送信の有無 yes：IKE Nortificationを送信 no：IKE Nortificationを送信しない yes 17 Invalid Autthnetication 表 4-3-(3)-2 実験対象機証明書有効期限切れ時の相互接続性確認 試験対象機の証 エラー送信の有 失効検知した際のLOG表示 明書有効期限切 無 れ検知 no no no no no no no no no no no no no no no no yes no bad my cert no no yes no No 製品名 1 VPN-1 Solaris 2 VPN-1 Windows2000 3 VPN-1 Linux 4 NOKIA IP Series 5 RapidStream/Checkpoint 6 RapidStream 7 NetScreen 8 Nortel Contivity VPN Switch 9 三菱電機 Cryptopia100 10 Cisco VPN3000 11 アライドテレシス AR720 12 Intel NetStructure 13 KAME (Racoon) no no no no 14 SecureVPN Gateway Series(Offline) 15 AVYA VSU 16 ssh IPSEC Express Toolkit no no 失効検証の有無 yes:：証明書有効期限検証を行いネゴシエーションを行わない no：証明書有効期限検証を行わない（ネゴシエーションを行う。） エラー送信の有無 yes：IKE Nortificationを送信 no：IKE Nortificationを送信しない 18 （４） 複数 CA への対応確認 実験は 4 台の CA を使用し、通信確認はリファレンス VPN 装置を使用した。 CA1 から発行された証明書をリファレンス VPN 装置と実験対象機にエンロールし、通信が行 えることを確認する。次に CA2 から発行された証明書を各々にエンロールし通信確認を行う。 この手順を CA4 まで繰り返し行った。 この実験では CA の差異による通信可否の確認を行うほか、実験対象機が複数の証明書をエ ンロール可能であるかどうかを確認した。 実験結果から証明書のエンロールが正常に行えれば IPsec 通信は正常に行える事が確認でき た。すなわち CA による通信の差異は確認できなかった。また複数の証明書をエンロール可能 な VPN 装置の多くは通信相手ごとに証明書を使い分けられる事が確認できた。証明書の使い分 けはネゴシエーション時の Cert Request を使用して行われるため、Cert Request を無視する 製品では、通信相手が証明書を使い分けできたとしても期待する結果が得られない事が考えら れる。 （結果一覧表 表 4-3-(4) 複数 CA への対応確認実験結果） 19 表 4-3-(4) 複数 CA の対応確認実験結果 No 製品名 通信確認 CA1 ssh Certifier ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ 1 VPN-1 Solaris 2 VPN-1 Windows2000 3 VPN-1 Linux 4 NOKIA IP Series 5 RapidStream/Checkpoint 6 RapidStream 7 NetScreen 8 Nortel Contivity VPN Switch 9 三菱電機 Cryptopia100 10 Cisco VPN3000 11 アライドテレシス AR720 12 Intel NetStructure 13 KAME (Racoon) 14 SecureVPN Gateway Series(Offline) 15 SecureVPN Gateway Series(Entrust) 16 AVYA VSU 17 ssh IPSEC Express Toolkit 通信確認 ○:：IPsec通信可能 ×：IPsec通信不可 複数証明書エンロールの可否 yes：複数の証明書エンロールに対応 no：複数の証明書エンロール未対応 通信相手ごとの証明書使い分け yes：通信相手ごとの証明書使い分け可能 no：通信相手ごとの証明書使い分け不可 CA2 Entrust v5．0 ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ CA3 Easy Cert ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ 20 CA4 富士ゼロックス ○ ○ ○ ○ ○ ○ ○ ○ ○ 複数証明書 ｴﾝﾛｰﾙの可否 通信相手ごとの 証明書の使い分け yes yes yes yes yes yes yse yse no yes(2枚まで） yes yes yes no no yes yes yes yes yes yes yes yes no yes yes yes yes no no yes yes 5. まとめ 5.1. はじめに 今回の実験を通し、VPN 装置を PKI 環境下で運用する際の注意点が幾つか見えてきた。各実験 の考察を先に述べた後に、PKI 環境下における IPsec 相互接続の注意点で、特に注意が必要な幾 つかの項目について総括を行う。 5.2. 実験考察 5.2.1. オフライン証明書取得時の動作確認実験 (１) 証明書取得 証明書は記載される情報や証明書の記述方法などが ITU-T X.509 で定義されている。IPsec の相互接続環境で使用する証明書の情報に対する注意事項については、後述の「PKI 環境下 における IPsec 相互接続の問題点」で詳しく述べると事とし、このセクションでは証明書の エンコード形式について考察する。 先にも述べたが、証明書の記述法は ANS.1 である。したがって X.509 証明書は本来 ANS.1 のバイナリデータである。しかし実際にはいくつかの証明書のエンコード形式が存在する。 下記によく使用される証明書エンコード形式を示す。 z X.509 DER 形式 z X.509 PEM 形式 z PKCS#7 DER 形式 z PKCS#12 DER 形式 DER(Distinguished Encoding Rules)形式は ANS.1 に 1 対 1 でバイト配列化したものであ り、PEM（Privacy Enhanced Mail）形式は、証明書のバイナリデータを BASE64 エンコード しテキスト化したものである。PKCS#7 DER 形式と PKCS#12 DER 形式は、それぞれ PKCS#7/12 を DER 形式にしたものである。 PKCS#10 は証明書発行要求のメッセージ構文規約であり、証明書と同様 ANS.1 のバイナリ 形式であるが、 今回の実験によりほとんどの VPN 装置が作成する PKCS#10 証明書発行要求は、 PEM 形式であることが明らかになった。また、ほとんどの VPN 装置で PEM 形式の証明書であ ればエンロール可能であることが確認できた。したがって PKI 環境下において VPN 装置の相 互接続環境を行う際には、証明書エンコード形式は PEM 形式を使用することを推奨する。た だし、VPN 装置により証明書ファイルの拡張子が指定されたものである必要があるので、こ の点については事前に調べておく必要がある。 (２) 証明書有効期限に関する動作 VPN 装置では証明書を認証に使用している。有効期限が切れた証明書を使用した際には認 証で失敗し通信できないことが 4-3-(3)で確認できている。したがって、証明書の有効期限 が間近に迫っている事や、証明書の有効期限が切れていることを管理者は把握しておく必要 がある。 今回の実験の結果では、証明書の有効期限が切れた時に VPN 装置がその旨を Log 等に表示 するなどして管理者通知する事が期待された。しかし、そのような動作を行う VPN 装置が意 外にも少ないことが確認できた。 通常の運用では証明書の有効期限は 1 年以上のものを使用することが多い。したがって、 管理者が証明書の有効期限を記憶しておくのは困難であると考えられるため、管理者は管理 する VPN 装置の証明書有効期限が切れた時にどのような動作をするか事前に確認しておく必 要がある。Log 等で証明書の有効期限が切れたことを通知しない VPN 装置を使用している場 21 合は、何らかの代換手段を事前に講じておく事が必要である。 また、証明書の有効期限が切れた時には、証明書を更新する必要があるが、オフラインで 証明書を VPN 装置にエンロールした場合、自動的に更新してくれる VPN 装置は少なくとも今 回の実験では確認できなかった。したがって、証明書の更新方法についても事前に検討して おく必要がある。 (３) CRL 取得方法の確認 発 行 さ れ た 証 明 書 は 意 図 的 に 失 効 (Revoke) す る 事 が で き 、 失 効 さ れ た 証 明 書 は CRL(Certificate Revocation List)に登録される。 一般に証明書が失効されるのは、証明書の所有者がその組織から存在しなくなった場合や、 鍵が危殆化した時などである。したがって、失効された証明書で Peer を認証してはならない。 ほとんどの VPN 装置では CRL を使用して Peer の証明書を検証するが、CRL をいつ取得する かについては明確な回答は無い。最適と思われるのは、VPN 装置の起動時や実際に証明書を 利用するときに、常に最新の CRL を取得することである。LDAP や http などを使用してオン ラインで CRL を取得した場合は再起動時に最新の CRL を取得し、その後定期的に CRL を更新 する事が確認できた。したがって、オンラインで CRL を取得できる製品では、可能な限りオ ンラインで証明書を取得し、常に最新の CRL を使用すべきである。 一方、管理者が手動で CRL を取得した場合は定期的に CRL が更新されることは無い事が確 認できた。したがって管理者は最新の内容を反映した CRL を確実にアップロードする必要が ある。 また、証明書を利用するときに常に最新の CRL を使用するには、証明書の CRLDP(CRL Distribution Point)を参照する必要がある。CRLDP については後述の「PKI 環境下における IPsec 相互接続の問題点」で詳しく述べる。 5.2.2. 電子署名認証方式の IPsec 相互接続実験 (１) 電子署名方式の相互接続性確認 電子署名認証方式の相互接続性確認実験では、ほとんどの組合せで正常に通信が行えるこ とが確認できた。しかし、結果では「○」になっている組合せにおいても幾つかの問題が発 生した。 1 つ目の問題は、IKE パケットがフラグメントされている場合にネゴシエーションが行えな い VPN 装置が確認できたことである。既知共有鍵認証方式では経路の MTU が 1500byte 以上で あれば、この問題が発生する事は無い。しかし電子署名認証方式の場合、Phase1 の Stage5， 6 で証明書を送信する。今回の場合は 1024bit の RSA 鍵長を使用したため証明書を送信する だけではフラグメントが発生することは無かったが、 一部の VPN 装置では証明書と一緒に CRL を送信する為にこの問題が発生した。また、証明書に 2048bit の鍵長を使用した場合などフ ラグメントが発生することが考えられるので運用上注意が必要である。 2 つ目の問題は、IKE Proposal ID に関する問題である。Proposal ID とはそのペイロード の番号を示すものであり、RFC2408 で規定されているが、具体的に何番を使用すべきかは明 記されていないことである。今回の実験では Proposal ID=0 を受入れられない VPN 装置が確 認できた。 この問題が発生した組合せでは Proposal ID=0 であった VPN 装置の設定を Proposal ID=1 に変更することで正常に通信できることが確認できた。なお、今回の実験に参加したほ とんどの VPN 装置が Proposal ID=1 を使用しているため、他の組合せではこの問題は発生し なかった。 ほとんどの VPN 装置では Proposal ID を設定で変更することが不可能であるため、 VPN 装置導入に際しては念のため確認した方が良い項目である。 3 つ目の問題は、Phase2 の Transform ペイロードに関する問題である。Phase2 の Transform ペイロードでは IPsec で使用する認証手順や SA の Life Time などを提案する。この提案 1 つ 22 で 1 つのパラメータセットとして扱われ、Phase2 ネゴシエーションでは複数の Transform ペ イロードを使用して複数のパラメータセットを提案しても良いことが、RFC2408 で規定され ている。 問題が発生した VPN 装置では、複数の提案を受信した VPN 装置が、その提案の中に自身が サポート可能なパラメータセットがあったとしても、他のパラメータセットに自身がサポー ト不可能なパラメータがあった時に No Proposal Chosen Information を Peer に送信しネゴ シエーションを中断する動作が確認できた。それ以外の VPN 装置ではこの問題は確認できな かった。この問題は運用で回避できることが出来る為、大きな問題になることは考えづらい。 実験結果で「△」の組合は、Re-Key の際に問題が発生した物である。昨年度の相互接続実 験でも Re-Key 時には幾つか問題が発生した。今回発生した具体的な現象の説明は割愛するが、 Re-Key に関する標準が規定されていないため、Re-Key 時の動作仕様が VPN 装置により異なる ことが原因である事は確実であり、VPN 装置導入時には必ず確認すべき項目である。 実験結果で「×」の組合せは、IKE のプロトコル解釈の違いにより接続できなかったと考 えられる。 １つ目の原因は電子認証方式で使用される Certificate Request ペイロードにあった。 Certificate Request ペイロードは Phase1 の認証で使用する証明書の送信を Peer に要求す る際に使用すると RFC2408 では規定されている。 今回問題となったのは、 Certificate Request ペイロードの内容ではなく、送信されるタイミングであった。Certificate Request ペイロ ードを送信するほとんどの VPN 装置では Stage3，4 でこれを送信するが、問題が発生した VPN 装置では Certificate Request を Stage1(レスポンダの時は Stage2)で送信していた。しかし RFC ではネゴシエーション中であれば、これをいつ送信しても良いと記述されているため、 受信できない VPN 装置側の問題と考えられる。 2 つ目の原因は INITIAL-CONTACT 通知メッセージにあった。INITIAL-CONTACT とは、ネゴシ エーションを行っている Peer と SA を確立するのが始めてであることを通知する為のメッセ ージで、RFC2407 で規定されている。今回の INTIAL-CONTACT は Phase2 のネゴシエーション 中にやりとりされていたため、通信が暗号されており詳細を調査するに至らなかったが、 Phase2 のネゴシエーション中に INITIAL-CONTACT を受信した機器が、それを理解できず Phase2 ネゴシエーションを中断していた事が確認できた。RFC2407 では INITIAL-CONTACT の ような通知メッセージはネゴシエーション中に送信しても良いと規定されているため、ネゴ シエーション中にこれを受信できない VPN 装置側に問題がある。 (２) 証明書失効時の相互接続性確認 実験では Peer の証明書が失効されている時の接続性の確認と、自身の証明書が失効されて いる時の接続性の確認を行った。 Peer の証明書が失効されている場合、それがイニシエータであってもレスポンダであって も通信を拒絶する必要がある。VPN 装置の証明書は Phase1 の Stage5，6 で送信される。Phase1 の SA 確立を拒絶するには Stage5，6 で Peer の証明書を受信したときに、Peer に対し受信し た証明書に問題があることを示すメッセージを返す事が望ましい。今回の実験で、Peer の証 明書が失効されている時の動作は、ほとんどの VPN 装置で期待された動作をする事が確認で きた。 自身の証明書が失効されている時の接続性の確認では、自身が証明書を Peer に送信する前 に、自身の証明書に対して失効検証を行う事を期待したが、ほとんどの VPN 装置でこのよう な動作は行われなかった。失効された証明書を受信した VPN 装置側で通信を拒絶することが 可能であることが確認されているため、自身の証明書の失効検証をしない事がネットワーク のセキュリティレベルを下げる事にはならないと考えられるが、自身の証明書を失効検証す ることで、無駄な IKE ネゴシエーションを無くすことによって VPN 装置の負荷軽減や、ネッ トワークトラフィックを抑制する事が出来ることを考えると、各 VPN 装置がこのような実装 をする事が望ましいと考える。 VPN 装置では CRL を使用して失効検証を行っているが、CRL は肥大化する特徴をもっている 23 ため、運用を続けると CRL での証明書検証は問題が発生する可能性が高い。今後 OCSP 等の CRL に代わる失効検証の機能が VPN 装置にも実装されていく事を期待したい。 (３) 証明書有効期限切れ時の相互接続性確認 実験では Peer の証明書が期限切れとなっている時の接続性の確認と、自身の証明書が期限 切れとなっているときの接続性の確認を行った。 Revoke 時と同様、Peer の証明書が期限切れとなっている場合、それがイニシエータであっ てもレスポンダであっても通信を拒絶する必要があり、Peer の証明書を受信した時に、その 証明書に問題があることを示すメッセージを返すことが望ましい。今回の実験の Peer の証明 書が期限切れとなっているときの動作では、ほとんどの VPN 装置で期待された動作をする事 が確認できた。 自身の証明書が期限切れとなっている時の接続性の確認では、自身が証明書を Peer に送信 する前に、有効期限を確認しネゴシエーションを中断する事が期待されたが、ほとんどの VPN 装置でこのような動作は行われなかった。また、一部の VPN 装置では、自身の証明書の有効 期限を確認しているが、ネゴシエーションを中断せずに他の方法を用いてネゴシエーション を故意に失敗させる動作を行う事が確認できた。今回の実験では以下のような方法で、ネゴ シエーションを失敗させていた。 z 有効期限切れの証明書を送信しない。 （Certificate ペイロードを送信しない。） z Peer から要求された証明書とは、異なる証明書を送信する。 IKE ネゴシエーションによる、VPN 装置の負荷やネットワークトラフィックを考えると、各 VPN 装置が自身の証明書の有効期限を確認し、期限切れであればネゴシエーションを行わな い実装をすることが望ましいと考える。 (４) 複数 CA への対応確認 今回の実験の結果から、証明書のエンロールさえ正常に行う事が出来れば、電子署名認証 方式で IPsec 通信が正常に行える事が確認できた。またこの時、証明書を発行した CA の違い によるネゴシエーションの差異は確認することが出来なかった。したがって、証明書さえ正 常にエンロールできれば、各組合せの相互接続性に差異は発生しないと言える。 オフラインでの証明書エンロールでは大きな問題は発生しなかったが、幾つかの VPN 装置 はオンラインの証明書取得をサポートしているものがあり、実験期間中にオンライン証明書 取得を行った。この時に発生した幾つかの問題について考察する。 この実験でオンライン証明書取得を行った VPN 装置は以下の製品である。 z SCEP ：VPN3000，NetStructure VPN，NetScreen z CMP ：AR720 z Entrust-Ready：Secure VPN Gateway，VPN-1 ① SCEP による証明書取得 SCEP はシスコシステムズ社とベリサイン社が共同開発した証明書管理プロトコルで、 証明書登録フォーマットとして PKCS#10、証明書発行フォーマットとして PKCS#7 を使用 し、トランスポートプロトコルとして HTTP を使用する。SCEP における証明書発行要求か ら取得までの流れは下記の通りである。 1. VPN 装置から、CA の証明書を要求する HTTP 要求メッセージを CA に送信し、CA の 証明書を取得、以後、CA の証明書を使用して CA との通信を保護する。 2. VPN 装置側で、SCEP メッセージを作成し、署名する。 3. CA の証明書を使用して PKCS#7 メッセージに同封し、HTTP 要求メッセージにて CA に送信する。 24 4. ポーリング要求を CA に送信し、証明書要求が受理されたかどうかを確認する。 5. CA 側で証明書要求を処理し、証明書を発行する。 6. VPN 装置側で、証明書を取得。 SCEP での証明書取得は、Cisco VPN3000 と Intel NetStructure VPN に関しては問題が 見られなかったが、NetScreen では証明書取得が出来なかった。 証明書発行要求時に VPN 装置側で設定するパラメータ項目は VPN 装置により相違が見 られた。 Cisco VPN3000 は、CA Identity Name、Enrollment URL、Challenge Password、Common Name(CN)、Organizational Unit(OU)、Organization(O)、Locality(L)、State/Province(SP)、 Country(C)、SubjectAltName (FQDN、e-mail Address)、Key Size を入力することが可能 であったのに対し、Intel NetStructure VPN は CA Identity Name、Enrollment URL、 Challenge Password、IP Address、FQDN、e-mail Address、Key Size のみを入力する形 式になっており、IP Address、FQDN、e-mail Address のうち、入力された値を Common Name(CN)と SubjectAltName としていた。 Intel NetStructure VPN は、CA Identity Name にスペースを入れることが出来ない。 そのため、CA 側でスペースの入った名前を設定した場合、VPN 装置側で設定ができない といった問題も発生した。 図 5-2-(1) SCEP 使用時の構成例 WWWサーバ レポジトリ (CGI Script) IPSec Gateway LDAP SCEP LDAP SCEP over HTTP RA (Registration Authority) CA SEP/CMP (Certification Authority) ② CMP による証明書取得 CMP は、IETF で標準化されている証明書管理プロトコルであり、トランスポートプロ トコルとして FTP や HTTP、e-mail を使用する。 リファレンス CA である SSH Certifier が CMPv2 のみのサポートであるのに対して、 AR720 は CMPv1 のみのサポートであったため、AR720 ではオンラインによる証明書取得が 出来なかったが、Entrust v5．0 では CMPv1 を使用して問題なく証明書をエンロールする 事が出来た。現状では CMP をサポートしている製品は非常に少ないが、SCEP よりもセキ ュリティを考慮されている点を考えると、今後 CMP をサポートする製品は増えていくと 考えられる。 ③ Entrust Ready による証明書取得 Entrust Ready は、Entrust/PKI との間でオンライン証明書取得・自動更新をするため の規格である。Entrust/PKI 独自の規格であるため、リファレンス機である SSH Certifier は未対応であり、Entrust v5．0 のみで接続実験を行った。 Entrust Ready では CA のアドレスや LDAP サーバのアドレス設定方法に 2 つの方法があ 25 る。1 つ目は管理者が手動でアドレスを設定する方法であり、2 つ目の方法として、 Entrust.ini ファイルという Entrust 社の CA の設定ファイルを VPN 装置にインストール し、CA のアドレスや LDAP サーバの設定をする方法である。Entrust Ready の製品では必 ずどちらかの方法を用いて CA と LDAP サーバのアドレスを設定しなければならない。ま た Entrust Ready で取得する証明書の Subject および SubjectAltName などは全て CA 側 で設定する必要がある。すなわち VPN 装置側では発行される証明書のフィールドに関す る項目は一切設定できない。 Peer ごとに証明書を使い分けられる VPN 装置では、相手とのネゴシエーション時に使用す る証明書を予め設定する。設定した内容はネゴシエーション時に Certificate Request ペイ ロードの内容に反映される。 前述の通り VPN 装置はネゴシエーション時に Certificate Request ペイロードを使用して Peer に証明書送信を要求する。Certificate Request ペイロードは必要に応じて複数送信す ることも、Request Data として、CA の DN 等の情報を含むことができると RFC2408 には規定 されている。 今回の実験で確認できた Certificate Request ペイロードの 3 つのパターンである。 ① VPN 装置にエンロールされている全ての Root の証明書を要求する。 (Request Data に Root CA の DN は含まれている。) ② VPN 装置で Peer が使用している証明書と設定した Root CA の証明書を要求する。 ③ VPN 装置で Peer が使用する証明書と設定しているにも関わらず、Certificate Request Data には何も含まれない。(どの証明書を要求しているかは明確ではない。) ①のパターンでは Request を受信した VPN 装置が送信する証明書と、VPN 装置で予め設定 した Peer の証明書が異なる可能性があるのであまり好ましい方法ではないと考える。また③ のパターンも Request Data が無い為に同様の問題が発生し得る。②のパターンは今回最も多 くの VPN 装置で確認されたパターンである。この方法であれば、Request を受信した VPN 装 置が送信する証明書と、VPN 装置で予め設定した Peer の証明書と異なることは無い。したが って、②パターンの Certificate Request を送信することが望ましいと考える。 26 5.3. PKI 環境下における IPsec 相互接続の問題点 PKI といっても、環境はさまざまである。CA サーバはもちろんだが、そのほかにも LDAP サー バ、 Web サーバ、 SCEP/CMP といったプロトコルに対応するモジュールといったものが必要となる。 Web サーバが必要なのか？と言った疑問もあるかもしれないが、これは CRL の取得のためである。 もちろん、LDAP に CRL を格納できる環境が通常ではあるが、リソースの少ない VPN 装置等に対し ては HTTP を利用したほうが、LDAP より効率的である場合がある。そして、肝となる CA サーバに て発行/管理される証明書についても、証明書のフォーマットとしては X.509 として統一されて いるが、非常に多種多様な項目の設定/管理が存在し、取り扱いの難しさを感じさせる。VPN 装置 に証明書が必要なのかといった疑問もあるが、やはり第三者による認証は強力である。認証を求 めるサービスにおいて証明書は必須と考える。今回の相互接続実験で、PKI 環境における VPN 装 置の証明書の取り扱いについて、いくつかの問題点が浮上した。これは、単一の CA ベンダーを 利用して証明書を管理していたとしても問題となる点も含まれている。以下に、いくつかの点に ついて VPN 装置が証明書を使って認証を行う場合のチェック項目を挙げる。 5.3.1. 証明書に含まれる項目について 証明書には、基本的なフィールドと拡張(エクステンション)フィールドが存在する。今回 の接続実験で、証明書の項目の扱い方が VPN 装置によって異なることが分かった。特に問題 となるのが、エクステンションのフィールドで、通常、証明書としては参照されない(クリテ ィカルではない)項目までもが、参照項目となることがわかった。 (１) Subject 「誰の」 証明書かを表すフィールドである。 このフィールドには、 DN 名(Distinguished Name) が記述される。VPN 装置の名前が定義されるわけだが、問題は DN 名の並びである。今回は、 cn(common name)に gateXX(XX には VPN 装置の番号),o(organization)に JNSA,c(country)に jp を指定した。しかし、この各パーツを組み立てるときの問題がある。 a) c=jp, o=JNSA, cn=gateXX b) cn=gateXX, o=JNSA, c=jp さて、どちらが正しいのだろうか。答えは「どちらも正しい」としておくが、一般的には a) のパターンである。CA サーバで DN 名の並び替えを行わない場合、Subject フィールドの DN 名は、PKCS#10 を作成した際の DN 名が使われてしまう。今回の実験で、この並びの順番によ って、VPN 装置によっては受け付けられない場合が存在することが分かった。例えば、自分の VPN 装置が a)のパターンの DN を使用し、相手の VPN 装置が b)のパターンを使用した場合で ある。従って、PKCS#10 を作成する際の DN 名の命名規則は統一しておく必要があるだろう。 (２) Key Usage 証明書には、証明書(および公開鍵)が「どのような用途」に使われるかを記述する項目が ある。これが Key Usage である。Key Usage は証明書のエクステンションとして取り扱われる。 Key Usage については、RFC 2459 の項番 4.2.1.3 に記述されている。 今回の接続実験で、すべての証明書の Key Usage に DigitalSignature を設定した。接続実 験中に Key Usage が問題となった VPN 装置はなかった。 しかし、 Key Usage に DigitalSignature を指定した場合、クリティカルとして指定されることが推奨ではある。今回の場合、VPN 装置 がクリティカルビットを判断して扱っているか、また、無条件にクリティカルとして扱って いるかは不明である。正確な実験が行われていないが、ほとんどの VPN 装置では Key Usage を 正 し く 処 理 ( 理 解 ) し て い な い の で は な い か と 思 わ れ る 。 出 来 れ ば 、 Key Usage に DigitalSignature 以外を設定した場合の、VPN 装置の動作確認まで行いたかったのだが、実 験期間中で確認することは出来なかった。 27 さらに、Key Usage に何も指定しない場合だが、この場合、接続できない VPN 装置が存在し た。 Key Usage はエクステンション(=拡張項目)のため問題が無い VPN 装置がほとんどである。 しかし、Key Usage に何も指定しなかった場合に、接続できない VPN 装置が存在したことで、 相互接続のためには必ず、VPN 装置に対する証明書の Key Usage に DigitalSignature を指定 するのが望ましいだろう。 (３) subjectAltName subjectAltName もエクステンションである。証明書の Subject に対しての代替名称として 用いられる。subjectAltName は RFC 2459 の項番 4.2.1.7 に記述されている。Subject が DN 名でなければならないのに対して、subjectAltName は E-Mail アドレス,IP アドレス,DNS 名,URI と指定できる内容がさまざまである。subjectAltName は subject が空の場合のみクリ ティカルとして扱われる。さて、ここまでは、X.509 の世界であるが、VPN 装置の場合は少々 異なる。実際の接続時のケースとしては次の 2 点が上げられる。 a) ID ペイロードに ID_DER_ANS1_DN を送信してくる b) ID ペイロードに ID_DER_ANS1_DN 以外を送信してくる。 それぞれのケースについて検討する。まず、a)のケースだが、VPN 装置が ID ペイロードに ID_DER_ANS1_DN(DN 名 ) を 設 定 し て 送 信 し て く る 場 合 、 Subject と 比 較 で き る た め subjectAltName は参照されない。では、b)のケースはどうだろうか。ID ペイロードに ID_DER_ANS1_DN(DN 名)以外を設定して送信してくる VPN 装置の場合、subject では比較でき ないため、クリティカルではないが subjectAltName が必須となる。 図 5-3-(1) ID ペイロードと Certficate ペイロードの関係 a) IDペイロード Certペイロード DN名 cn=xx,o=JNSA,c=JP 証明書 Subject:∼∼ IDペイロードのDNと Certペイロードの Subjectを比較 b) IDペイロード Certペイロード IPアドレス 192.168.x.x 証明書 Subject:∼∼ IDペイロードと subjectAltNameが 比較できない? Subject Alt Name :FQDN 今回の接続実験で、各 VPN 装置とも subjectAltName の扱い方が非常にあいまいであること が確認できた。各 VPN 装置とも、ID ペイロードをチェックする項目は存在する。しかし、ID ペイロードを判別して subjectAltName をチェックしているのか、クリティカルビットを判断 して扱っているか、は不明である。更に、VPN 装置によっては ID ペイロードのチェックを設定 で変えるといったことが出来る物もある。接続する VPN 装置によって、subjectAltName は非常 に重要な項目となってくる。subjectAltName と ID ペイロードについては、後述の、証明書の 検証の項でもさらに検討する。 (４) CRL Distribution Point CRL Distribution Point(CRLDP)もエクステンションである。RFC では、CRLDP はノンクリテ ィカルにすべきだが、サポートすることを推奨するといった、非常にあいまいな記述になって いる。ほとんどの VPN 装置が CRL をオンラインで取得できるが、CRLDP に記述する URI によっ て動作が異なる。更に、CRLDP には複数行、すなわち DN と HTTP といった組合せや、DN と LDAP といった組合せが可能である。 28 図 5-3-(2) CRLDP 記述パターン 証明書 A CRLDP: DN名(cn=xx,o=JNSA,c=JP) 証明書 B CRLDP: ①DN名 (cn=xx,o=JNSA,c=JP) ②HTTP://hostname/・・ 発行するCAによって 色々なCRLDPが記述される 証明書 C CRLDP: ①HTTP://hostname/・・ ②LDAP://hostname/・・ 今回の実験では、当初、CRLDP に DN のみを指定した。しかし、この CRLDP では、LDAP にア クセスする機能がサポートされている VPN 装置、すなわち LDAP クライアントになれる VPN 装 置しか取得できなかった。このため、LDAP クライアントの機能がない VPN 装置に対しても CRL が取得できるよう、HTTP での CRLDP を書き加えたものを使用した。この DN と HTTP が、CRLDP に記述されている証明書での相互接続は、問題が発生しなかったが、各 VPN 装置が DN と HTTP のどちらの CRLDP を使用して CRL を取得しているのかの確認までには至らなかった。CRL につ いては、後述の証明書の失効の項目や階層 CA 環境の項目でもさらに詳しく検討する。 5.3.2. 証明書の失効 発行された証明書は、永遠に使えるわけではない。証明書には有効期限があるし、証明書を 意図的に失効(revoke)することができる。失効された証明書は Certificate Revocation List(CRL)に登録され、LDAP や HTTP などを利用して、失効された証明書の一覧を取得する。 (１) CRL の取得 証明書が失効されているかを調べるためには CRL を取得する必要がある。では、CRL はいつ 取得するべきなのか？について明確な回答はない。最適だと思われるのは、VPN 装置の起動時 や実際に証明書を利用するときに、常に最新の CRL を取得することである。しかし、これでは トラフィックの増加や VPN 装置への負荷が非常に大きくなる。しかも、CRL 自体は肥大化する 一方であるため、ネゴシエーションに時間がかかるような問題も起きてくるであろう。一部の VPN 装置では、CRL をキャッシュする機能もついている。今回の接続実験で、CRL の更新日付を 判断している VPN 装置の確認までにはいたらなかった。 (２) CRL の適用 さらに、最新の CRL を取得したとして、この CRL をいつ適用するべきなのか？についても明 確な回答がない。やはり、VPN 装置の起動時や証明書を利用する時になるだろう。本来である ならば、署名を確認するときや、署名を添付する際には、最新の CRL を取得しておかなければ ならない。今回の接続実験で、CRL の適用が VPN 装置によって異なる事が確認できた。導入す る際には確認しなければならない点である。 (３) ファイルでの CRL 取得 VPN 装置によっては、CRL をオンラインで取得できず、ファイルとして提供しなければなら ないものがある。本来ならば、取りこんだ CRL の有効期限等のチェックをしなければならない。 チェックしなければ、古い CRL や更新されていない CRL を取りこんでしまうことになる。しか しながら、今回の接続実験で、ファイルとして提供される CRL の有効期限等を厳密にチェック 29 している VPN 装置は見当たらなかった。 5.3.3. IKE（Internet Key Exchange） 証明書の各項目がクリアーになったとしても、IKE にて証明書が正しく使われなければ、当 然接続も出来ない。ここでは、実際に IKE を使用して鍵交換を行う場合の問題点を検討してみ る。 (１) Certificate(証明書)ペイロード IKE 使用時に相手に対して送信される Cert(証明書)ペイロードだが、すべての VPN 装置が X.509 公開鍵証明書(タイプ=4)であった。一部の VPN 装置で PKCS#7(タイプ=1)をサポートして いたが、接続できない VPN 装置がほとんどであった。従って、証明書のタイプに PKCS#7 を使 用するのは現状では問題がある。一般的な電子署名方式を取るべきである。 (２) CRL 一部の VPN 装置では、Cert ペイロードに加えて CRL を付加して送信する。ほとんどの VPN 装 置は、この CRL を無視するようである。一見、無駄のようにも思えるが、受け取った側もまた CRL を参照しなければならないことを考えると、トラフィック的には同じである。ただし、IKE のネゴシエーションに時間がかかってしまう事や、送られてきた CRL が正しい物なのか、最新 の物なのか、の判断もしなければならない。さらに、次にあげる項目の問題点もある。 (３) フラグメント CRL を Cert ペイロードに付加して送信するのが問題ないとして、CRL が肥大化してきたらど うなるのだろうか。当然、MTU サイズを超えたパケットは送信できないため、IKE パケットの フラグメントが起こる。つまり、通常 6 回のやり取りで IKE(Phase1)が終了するのに対し、6 回以上のやり取りが発生することになる。 図 5-3-(3) IKE フラグメント ①通常（メインモード） イニシエータ ②フラグメント レスポンダ ① イニシエータ レスポンダ ① ② ③ ② ③ ④ ⑤ ④ ⑤-A ⑥ ⑤-B ⑤-C ⑥ IKE 自体が、通信としては信頼性の低い UDP を使用しているため、フラグメントされた途中 のパケットが経路上の何らかの問題で消えてしまうことも考えられる。前述の項目でも述べた が、受け取った側の VPN 装置が Cert ペイロードに付加された CRL を無視するため今のところ 30 問題はない。しかし、IKE パケットのフラグメント化によって引き起こされる問題は多いもの と思われる。 5.3.4. 証明書の検証 電子署名認証を使う場合、本文のハッシュを自分の秘密鍵で暗号化し電子署名として相手に 送信する。受け取った側は、相手の公開鍵で電子署名を複合化する。本文のハッシュを計算し、 この値が電子署名を複合化したハッシュ値と一致すれば、改ざんされていない事が確認できる。 では、IKE の場合はどうだろうか。IKE では本文と電子署名に加えて、自分の証明書も合わせ て送信する。このようにすることにより、受け取る側は相手の公開鍵も同時に入手できる。公 開鍵が入手できれば、電子署名を複合化することによりハッシュ値が得られ、本文が改ざんさ れていないことが確認できる。しかし、本文が改ざんされていないとしても、本当に受け取っ た証明書は正しいのだろうか。さらに、相手を識別するための手段はどのような方法があるの か。 以下は最新の CRL が取得できている状態で、かつ、自分と相手の証明書は revoke されてい ない(もちろん、証明書を発行した CA 自身も)と仮定する。 (１) 電子署名 今回の接続実験では、正しい証明書で正しく接続できることを目的としていた。従って、意 図的に改ざんした証明書を VPN 装置にエンロールしたり、経路の途中で IKE のパケットを書き 換えたりするような行為は行わなかった。電子署名は IKE の場合データ量が少ないので、比較 的処理が重いものではない。各 VPN 装置での署名の検証は行われていると思われる。 (２) ID ペイロード 相手をどのように識別するかを判断する。IKE では、Phase1 の Stage5 と Stage6 で交換され る。以下は、主に使われる ID ペイロードの種別である。 z ID_IPV4_ADDR ： IP アドレスによって識別 z ID_FQDN ：ホスト名(FQDN)によって識別 z ID_USER_FQDN ：ユーザー名([email protected])によって識別 z ID_DER_ASN1_DN ：DN 名(Distinguished Name)によって識別 ID ペイロードにはこれ以外にも存在するが、ここでは割愛する。VPN 装置によって ID ペイ ロードに何を使うかはまちまちである。さらに、VPN 装置によってサポートする ID ペイロード が異なる。これは非常に問題である。更に、ID ペイロードと証明書の Subject/subjectAltName との関連付けが、各 VPN 装置とも非常にあいまいである。いくつかの VPN 装置は ID ペイロー ドのチェックを任意に設定でき、subjectAltName のフィールドが必要ないように見うけられる 物も存在する。ちなみに、ID ペイロードと Subject/subjectAltName の比較検証は、Draft に て公開されていたが、すでにこの文章は expire されており、現状での明確な検証方法はない。 以下は、それぞれの証明書に subjectAltName に IP アドレスが入っているものとし、実際の環 境に置き換えて検証してみる。 A） イニシエータ ID_DER_ASN1_DN をサポートする。ID_FQDN を送信する。 B） レスポンダ ID_IPV4_ADDR と ID_FQDN と ID_DER_ASN1_DN をそれぞれを任意にサポートする(どれをチ ェックするかは設定する)。ID_IPV4_ADDR を送信する さて、このような VPN 装置同士の接続は問題ないだろうか。結論から述べると接続性は問題 ない。と、言うのも、どちらの VPN 装置も厳密にチェックしていないのである。以下に手順を 検証する。 31 図 5-3-(4) ID ペイロードの検証 イニシエータ IDペイロード レスポンダ ID_FQDN ID_FQDNをチェックしない Certペイロード Subject:DN名 Subject Alt Name: IPアドレス ID_IPV4_ADDRは サポートしていない IDペイロードとSubject Alt Nameの比較は行われない ID_IPV4_ADDR IDペイロード Subject:DN名 Subject Alt Name: IPアドレス Certペイロード ① イニシエータが自分の識別子として、レスポンダに ID_FQDN を送信する。 ② レスポンダは任意に設定されている(チェックしないと設定している)ID_FQDN を識別 できないため無視する。 ③ レスポンダは、問題がないと判断する。 ④ レスポンダは、自分の識別子として、ID_IPV4_ADDR をイニシエータに送信する。 ⑤ イニシエータは、サポートされていない ID_IPV4_ADDR を無視する。 このような状況である。この場合、どちらの VPN 装置にも問題があると考えられる。どち らの VPN 装置も証明書の subjectAltName を完璧に無視しているのである。これは、 subjectAltName がクリティカルに設定されていない為なのかもしれない。更に、どちらの VPN 装置も、識別子として送信する ID ペイロードが、subjectAltName にかかわらず固定に 設定されているのである。 本来の ID ペイロードと Subject/subjectAltName は、次のような解釈と考える。 1. ID ペイロードに ID_DER_ASN1_DN を使用するのであれば、 Subject の DN を送信する。 2. 何らかの理由で ID ペイロードに ID_DER_ASN1_DN を使用できないのであれば、 subjectAltName の内容、たとえば、subjectAltName が IP アドレスであれば ID_IPV4_ADDR を使用する。 いずれにしろ、subjectAltName はクリティカルではない。このような項目を、あたかもク リティカルのように、さらに項目の内容を無視して ID ペイロードを固定で扱う VPN 装置は 問題と考える。証明書に含まれる項目と、マッチングを行わないのも問題である。 (３) 証明パス 送られてきた証明書を使って、発行した CA を探し出し、ルートをたどり、検証しなけれ ばならない。自分の知らない CA から発行された証明書であれば、それは無効と判断しなけ ればならない。各 VPN 装置とも、自分の証明書を発行した CA の証明書をエンロールしてい る。しかし、前述のとおり誤った CA の証明書や誤った CA から発行した証明書をエンロール したわけではないので、実際に各 VPN 装置で、どのように検証しているかは不明である。更 に、後述の階層 CA 環境での対応も、各 VPN 装置ともに芳しくない状況である。 32 5.3.5. 階層 CA 環境での VPN 装置 今回の相互接続実験では、1 つの RootCA から発行した証明書をすべて使用した。しかし、実際 の PKI 環境では、複数の CA や、RootCA に認証された SubCA(中間証明局)が存在する。すなわち、 階層 CA の環境である。インターネットにおける階層構造として身近なところでは、DNS の名前解 決の仕組みがある。これと同様に、PKI 環境もまた階層構造を取れるようになっている。階層 CA では、RootCA が下位の CA を認証することにより、信頼性が保たれるというわけである。この項 では、階層 CA の詳しい説明はしない。階層 CA 環境下での VPN 装置の対応状況を検討する。 図 5-3-(5) CA のツリー構造のイメージ図 証明書発行 信頼 信頼点 RootCA (CA01) 下位認証局 (CA11) 下位認証局 (CA21) 下位認証局 (CA12) 証明書利用者 (H3) 証明書利用者 (H2) 証明書利用者 (R1) 証明書利用者 (H1) 今回の参加ベンダーで、明確にサポートしていると判明したのは 1 社のみであった。しかし、実 験期間中に確認をすることは出来なかった。今回の実験期間中にテストに使ったのは、CheckPoint Software technologies 社の CheckPoint VPN-1 NG(FP1)を Gateway に、SSH Communication Security 社の SSH Sentinel をクライアントとして使用した。CA 環境は、RootCA 配下にいくつかの CA を立 てて、階層構造にした。RootCA と VPN-1 が使用する証明書を発行した CA は固定とし、SSH Sentinel 側で、各 CA から発行された証明書を使い分けるような形を取った。 33 図 5-3-(6) 階層 CA の実験環境 証明書 RootCA 証明書 SubCA 証明書 SubCA SubCA 証明書 SubCA Sentinel IKEに証明書を使用 VPN-1 各SubCAの証明書を 使い分ける 結論から言えば、VPN-1 が階層 CA 環境をサポートしていなかった。マニュアルには、階層 CA 環境に対応しているような書き方になっているが、これは VPN-1 で使用できる SecuRemote や SecureClient と言った専用のクライアントを用いた場合のみである。Gateway の VPN 装置同士で は、まだサポートされていない。苦肉の策として、Sentinel が使用する証明書を、毎回インポー トし直し、参照する CA を変更することによって、接続にこぎつけることができた。が、これは 本来の姿ではない。 相手から送られてきた証明書の正当性を判断する。これは、非常に難しい問題である。証明書 のフィールドをチェックし、RootCA を探し出せるようにならなければならない。一方で、ネゴシ エーション時に、必要な証明書をすべて送りつけるといったことも考えられる。IKE では、証明 書ペイロードは複数あっても構わない。従って、このような方法も可能になるはずである。 各 CA から発行された証明書にも、また問題があった。一番大きかった問題は CRLDP である。 VPN-1 の場合、CRLDP に LDAP URI(ldap://hostname/...)といった記述を解釈できないのである。 CRLDP に LDAP が記述されていた場合、CRL が取得できずに接続ができなかった。 階層 CA 環境での VPN 装置の動作をまとめると、まだまだ実用に耐えられる物ではない事が判 明した。階層 CA のみならず、1 つの CA から発行された証明書を使うだけでも、これまで挙げて きたような問題点が多数存在する。しかし、PKI 自体は確実に成長しつづけている。CA もまだま だ成長段階で、未だはっきりしていない部分もある。このような状態で、VPN 装置に対して階層 CA の実装を期待するのは、時期尚早なのかもしれない。 34 付録１ 証明書プロファイル 実験で使用した各 CA が発行した証明書のプロファイルを以下に示す。 1 SSH Certifier 証明書プロファイル 証明書基本領域 version serialNumber signature algorithm parameters issuer countryName organizationName organizationalUnitName organizationalUnitName validity notBefore notAfter subject countryName organizationName organizationalUnitName organizationalUnitName commonName subjectPublicKeyInfo algorithm parameters subjectPublicKey issuerUniqueID subjectUniqueID signatureAlgorithm algorithm parameters signatureValue 自己署名 v3 ○ VPN装置 v3 ○ SHA1WithRSAEncryption SHA1WithRSAEncryption NULL NULL JP JNSA JP JNSA (3年) ○ ○ (1年) ○ ○ JP JNSA JP JNSA SSHRootCA ○ rsaEncryption NULL ○(2048bit) rsaEncryption NULL ○(1024bit) SHA1WithRSAEncryption SHA1WithRSAEncryption NULL NULL ○ ○ 証明書拡張 Field AuthorityKeyIdentifier keyIdentifier authorityCertIssuer authorityCertSerialNumber SubjectKeyIdentifier keyIdentifier KeyUsage digitalSignature nonRepudiation keyEncipherment dataEncipherment keyAgreement keyCertSign cRLSign encipherOnly decipherOnly PrivateKeyUsagePeriod certificatePolicies policyIdentifier policyQualifiers PolicyQualifierInfo qualifier PolicyMappings issuerDomainPolicy subjectDomainPolicy SubjectAltName rfc822Name dNSName iPAddress IssuerAltName rfc822Name dNSName iPAddress SubjectDirectoryAttributes BasicConstraints cA pathLenConstraint NameConstraints PolicyConstraints requireExplicitPolicy inhibitPolicyMapping ExtendedKeyUsage KeyPurposeId serverAuth clientAuth codeSigning emailProtection timeStamping その他 CRLDistributionPoints distributionPoint reasons cRLIssuer 自己署名 non-critical ○ VPN装置 non-critical ○ non-critical ○ non-critical TRUE non-critical ○ non-critical TRUE TRUE TRUE TRUE TRUE non-critical ○ critical TRUE CA non-critical DN 2 Entrust Authority 証明書基本領域 version serialNumber signature algorithm parameters issuer countryName organizationName organizationalUnitName organizationalUnitName validity notBefore notAfter subject countryName organizationName organizationalUnitName organizationalUnitName commonName subjectPublicKeyInfo algorithm parameters subjectPublicKey issuerUniqueID subjectUniqueID signatureAlgorithm algorithm parameters signatureValue 自己署名 v3 ○ VPN装置 v3 ○ SHA1WithRSAEncryption SHA1WithRSAEncryption NULL NULL JP JNSA JP JNSA (1年) ○ ○ (1年) ○ ○ JP JNSA JP JNSA ○ rsaEncryption NULL ○(1024bit) rsaEncryption NULL ○(1024bit) SHA1WithRSAEncryption SHA1WithRSAEncryption NULL NULL ○ ○ 証明書拡張 Field AuthorityKeyIdentifier keyIdentifier authorityCertIssuer authorityCertSerialNumber SubjectKeyIdentifier keyIdentifier KeyUsage digitalSignature nonRepudiation keyEncipherment dataEncipherment keyAgreement keyCertSign cRLSign encipherOnly decipherOnly PrivateKeyUsagePeriod certificatePolicies policyIdentifier policyQualifiers PolicyQualifierInfo qualifier PolicyMappings issuerDomainPolicy subjectDomainPolicy SubjectAltName rfc822Name dNSName iPAddress IssuerAltName rfc822Name dNSName iPAddress SubjectDirectoryAttributes BasicConstraints cA pathLenConstraint NameConstraints PolicyConstraints requireExplicitPolicy inhibitPolicyMapping ExtendedKeyUsage KeyPurposeId serverAuth clientAuth codeSigning emailProtection timeStamping その他 CRLDistributionPoints distributionPoint reasons cRLIssuer 自己署名 non-critical ○ VPN装置 non-critical ○ non-critical ○ non-critical non-critical ○ non-critical TRUE TRUE TRUE TRUE non-critical non-critical ○ critical TRUE NULL non-critical FALSE NULL non-critical DN non-critical DN，URI(ldap) 3 Easy Cert 証明書基本領域 version serialNumber signature algorithm parameters issuer countryName organizationName organizationalUnitName organizationalUnitName validity notBefore notAfter subject countryName organizationName organizationalUnitName organizationalUnitName commonName subjectPublicKeyInfo algorithm parameters subjectPublicKey issuerUniqueID subjectUniqueID signatureAlgorithm algorithm parameters signatureValue 自己署名 v3 ○ VPN装置 v3 ○ SHA1WithRSAEncryption SHA1WithRSAEncryption NULL NULL JP JNSA JP JNSA (1年) ○ ○ (1年) ○ ○ JP JNSA JP JNSA easycert ○ rsaEncryption NULL ○(512bit) rsaEncryption NULL ○(1024bit) SHA1WithRSAEncryption SHA1WithRSAEncryption NULL NULL ○ ○ 証明書拡張 Field AuthorityKeyIdentifier keyIdentifier authorityCertIssuer authorityCertSerialNumber SubjectKeyIdentifier keyIdentifier KeyUsage digitalSignature nonRepudiation keyEncipherment dataEncipherment keyAgreement keyCertSign cRLSign encipherOnly decipherOnly PrivateKeyUsagePeriod certificatePolicies policyIdentifier policyQualifiers PolicyQualifierInfo qualifier PolicyMappings issuerDomainPolicy subjectDomainPolicy SubjectAltName rfc822Name dNSName iPAddress IssuerAltName rfc822Name dNSName iPAddress SubjectDirectoryAttributes BasicConstraints cA pathLenConstraint NameConstraints PolicyConstraints requireExplicitPolicy inhibitPolicyMapping ExtendedKeyUsage KeyPurposeId serverAuth clientAuth codeSigning emailProtection timeStamping その他 CRLDistributionPoints distributionPoint reasons cRLIssuer 自己署名 VPN装置 non-critical ○ non-critical ○ critical TRUE TRUE TRUE TRUE non-critical ○ critical TRUE NULL non-critical FALSE NULL non-critical URI(http) non-critical URI(http) 4 富士ゼロックス 証明書基本領域 version serialNumber signature algorithm parameters issuer countryName organizationName organizationalUnitName organizationalUnitName validity notBefore notAfter subject countryName organizationName organizationalUnitName organizationalUnitName commonName subjectPublicKeyInfo algorithm parameters subjectPublicKey issuerUniqueID subjectUniqueID signatureAlgorithm algorithm parameters signatureValue 自己署名 v3 ○ VPN装置 v3 ○ md5WithRSAEncryption NULL md5WithRSAEncryption NULL JP JNSA GuruCA JP JNSA GuruCA (1年) ○ ○ (1年) ○ ○ JP JNSA GuruCA JP JNSA GuruCA ○ rsaEncryption NULL ○(1024bit) rsaEncryption NULL ○(1024bit) md5WithRSAEncryption NULL ○ md5WithRSAEncryption NULL ○ 証明書拡張 Field AuthorityKeyIdentifier keyIdentifier authorityCertIssuer authorityCertSerialNumber SubjectKeyIdentifier keyIdentifier KeyUsage digitalSignature nonRepudiation keyEncipherment dataEncipherment keyAgreement keyCertSign cRLSign encipherOnly decipherOnly PrivateKeyUsagePeriod certificatePolicies policyIdentifier policyQualifiers PolicyQualifierInfo qualifier PolicyMappings issuerDomainPolicy subjectDomainPolicy SubjectAltName rfc822Name dNSName iPAddress IssuerAltName rfc822Name dNSName iPAddress SubjectDirectoryAttributes BasicConstraints cA pathLenConstraint NameConstraints PolicyConstraints requireExplicitPolicy inhibitPolicyMapping ExtendedKeyUsage KeyPurposeId serverAuth clientAuth codeSigning emailProtection timeStamping その他 CRLDistributionPoints distributionPoint reasons cRLIssuer 自己署名 non-critical ○ 自己署名 non-critical ○ non-critical ○ non-critical non-critical ○ non-critical TRUE TRUE TRUE TRUE non-critical ○ critical TRUE CA non-critical FALSE NULL non-critical URI(http) non-critical URI(http) 付録２ VPN 装置の IKE に関する仕様 今回の実験に参加した各 VPN 装置の設定可能な IKE に関するパラメータ調査を行った。 それぞれの VPN 装置の情報は参加ベンダーから提出された。 パラメータ確認シート 製品名： VPN-1 製造メーカ：Checkpoint Software Technologies Ltd Version： v5.0(NG) 1．製品について 1) 製品形態 - ﾊｰﾄﾞｳｪｱ製品の場合は各ｼﾘｰｽﾞの型番とｻﾎﾟｰﾄIF - ｿﾌﾄｳｪｱ製品の場合は、ｻﾎﾟｰﾄするﾌﾟﾗｯﾄﾌｫｰﾑ 2) 製品定価 ソフトウェア Solaris 7/8,RedHat Linux6.1 Win2000,NOKIA IPSO ¥500,000∼ 2．鍵管理について 1) サポートしている鍵交換手法 2) IKEパラメータについて ①Phase１パラメータ ⅰ) サポートしているモード ⅱ) 相互認証方式 - 電子署名の場合の対応CA局 ⅲ) 暗号アルゴリズム ⅳ) 認証アルゴリズム ⅴ) DHグループ ⅵ) 有効期間 ｱ)Life Type (Time) ｲ) Life Duration (Time) ｳ) Life Type (KB) ｴ) Life Duration (KB) ⅶ) IDペイロード ②Phase2 パラメータについて ⅰ) サポートしているTransform ⅱ) 暗号アルゴリズム ⅲ) 認証アルゴリズム ⅳ) DHグループ ⅴ) 有効期間 ｱ)Life Type (Time) ｲ) Life Duration (Time) ｳ) Life Type (KB) ｴ) Life Duration (KB) ｵ）IPComp Compression Algorithms ｶ）NAT-Traversal ⅵ) IDペイロード ③PFSについて ⅰ) PFSのサポート ⅱ) PFSのON/OFFの可否 IKE Main Mode，Aggressive Mode Pre-Shared，電子署名 Entrust(Ready)，PKCS ＃7/10対応CA局 DES，3DES，CAST，AES(256bit) MD5，SHA-1 Group-1，Group-2，Group-5 サポート 5min ∼ 50日(72000min) サポート ----ESP，AH DES，3DES，CAST，AES(128/256bit) HMAC-MD5，HMAC-SHA1 Group-1，Group-2，Group-5 サポート 2min ∼ 24H サポート 1GB以上 Deflate --ID_IPV4_ADDR，IP_IPV4_SUBNET サポート 可 3．運用管理について ①設定方法について ⅰ) 設定方法 ⅱ) リモートからの設定変更の可否 - 可能な場合は、どの様に行うか？ ②運用管理について ⅰ) SAの状況確認の可否 - 可能な場合は、どの様に行うか？ ⅱ) SAの削除の可否 - 可能な場合は、どの様に行うか？ ⅲ) 相手毎のSA削除の可否 - 可能な場合は、どの様に行うか？ ⅳ) SA削除のリモート操作の可否 - 可能な場合は、どの様に行うか？ ③LOGについて ⅰ) IKEのネゴシエーションがLOGに残るか？ - 可能な場合は、LOGの確認方法 ⅱ) LOGの保存期間 ⅲ) LOGのExport機能の可否 - 可能な場合は、どの形式で可能か？ ④その他 ⅰ) Decrypt Keyを確認する事は可能か？ 専用ツール 可 専用ツール 可 コマンドで実施 可 コマンドで実施 可 コマンドで実施 可 各OSにリモートLogonし、コマンドを実施 残る 専用ツールでLOGを確認 特になし。 コマンドによるLogの切替えが行われるまで保存されている） 可 テキストファイル 可 4．IKE その他パラメータについて 1) IKE Config Mode 2) Xauth 3) Crack サポート ----- パラメータ確認シート 製品名： NOKIA IP Security Series 製造メーカ： NOKIA Version： v5.0(NG) 1．製品について 1) 製品形態 - ﾊｰﾄﾞｳｪｱ製品の場合は各ｼﾘｰｽﾞの型番とｻﾎﾟｰﾄIF - ｿﾌﾄｳｪｱ製品の場合は、ｻﾎﾟｰﾄするﾌﾟﾗｯﾄﾌｫｰﾑ 2) 製品定価 ハードウェア IP330：10/100Base-T IP440：10/100Base-T IP530：10/100Base-T IP650：10/100Base-T IP740：10/100Base-T ×3 ×4 ×4 ×4 ×4 ，拡張Slot ，拡張Slot ，拡張Slot ，拡張Slot ，拡張Slot × × × × × 1 3 3 4 4 ¥1，003，000 ∼ 2．鍵管理について 1) サポートしている鍵交換手法 2) IKEパラメータについて ①Phase１パラメータ ⅰ) サポートしているモード ⅱ) 相互認証方式 - 電子署名の場合の対応CA局 ⅲ) 暗号アルゴリズム ⅳ) 認証アルゴリズム ⅴ) DHグループ ⅵ) 有効期間 ｱ)Life Type (Time) ｲ) Life Duration (Time) ｳ) Life Type (KB) ｴ) Life Duration (KB) ⅶ) IDペイロード ②Phase2 パラメータについて ⅰ) サポートしているTransform ⅱ) 暗号アルゴリズム ⅲ) 認証アルゴリズム ⅳ) DHグループ ⅴ) 有効期間 ｱ)Life Type (Time) ｲ) Life Duration (Time) ｳ) Life Type (KB) ｴ) Life Duration (KB) ｵ）IPComp Compression Algorithms ｶ）NAT-Traversal ⅵ) IDペイロード ③PFSについて ⅰ) PFSのサポート ⅱ) PFSのON/OFFの可否 IKE Main Mode，Aggressive Mode Pre-Shared，電子署名 Entrust(Ready)，PKCS ＃7/10対応CA局 DES，3DES，CAST，AES(256bit) MD5，SHA-1 Group-1，Group-2，Group-5 サポート 5min ∼ 50日(72000min) サポート ----ESP，AH DES，3DES，CAST，AES(128/256bit) HMAC-MD5，HMAC-SHA1 Group-1，Group-2，Group-5 サポート 2min ∼ 24H サポート 1GB以上 Deflate --ID_IPV4_ADDR，IP_IPV4_SUBNET サポート 可 3．運用管理について ①設定方法について ⅰ) 設定方法 ⅱ) リモートからの設定変更の可否 - 可能な場合は、どの様に行うか？ ②運用管理について ⅰ) SAの状況確認の可否 - 可能な場合は、どの様に行うか？ ⅱ) SAの削除の可否 - 可能な場合は、どの様に行うか？ ⅲ) 相手毎のSA削除の可否 - 可能な場合は、どの様に行うか？ ⅳ) SA削除のリモート操作の可否 - 可能な場合は、どの様に行うか？ ③LOGについて ⅰ) IKEのネゴシエーションがLOGに残るか？ - 可能な場合は、LOGの確認方法 ⅱ) LOGの保存期間 ⅲ) LOGのExport機能の可否 - 可能な場合は、どの形式で可能か？ ④その他 ⅰ) Decrypt Keyを確認する事は可能か？ 専用ツール 可 専用ツール 可 コマンドで実施 可 コマンドで実施 可 コマンドで実施 可 各OSにリモートLogonし、コマンドを実施 残る 専用ツールでLOGを確認 特になし。 コマンドによるLogの切替えが行われるまで保存されている） 可 テキストファイル 可 4．IKE その他パラメータについて 1) IKE Config Mode 2) Xauth 3) Crack サポート ----- パラメータ確認シート 製品名： RapidStream６１００ 製造メーカ：RapidStream, Inc. Version： Next Generation Feature Pack1 1．製品について 1) 製品形態 - ﾊｰﾄﾞｳｪｱ製品の場合は各ｼﾘｰｽﾞの型番とｻﾎﾟｰﾄIF - ｿﾌﾄｳｪｱ製品の場合は、ｻﾎﾟｰﾄするﾌﾟﾗｯﾄﾌｫｰﾑ 2) 製品定価 ハードウェア 3,300,000円（ソフトウェアは別売） 2．鍵管理について 1) サポートしている鍵交換手法 2) IKEパラメータについて ①Phase１パラメータ ⅰ) サポートしているモード ⅱ) 相互認証方式 - 電子署名の場合の対応CA局 ⅲ) 暗号アルゴリズム ⅳ) 認証アルゴリズム ⅴ) DHグループ ⅵ) 有効期間 ｱ)Life Type (Time) ｲ) Life Duration (Time) ｳ) Life Type (KB) ｴ) Life Duration (KB) ⅶ) IDペイロード ②Phase2 パラメータについて ⅰ) サポートしているTransform ⅱ) 暗号アルゴリズム ⅲ) 認証アルゴリズム ⅳ) DHグループ ⅴ) 有効期間 ｱ)Life Type (Time) ｲ) Life Duration (Time) ｳ) Life Type (KB) ｴ) Life Duration (KB) ｵ）IPComp Compression Algorithms ｶ）NAT-Traversal ⅵ) IDペイロード ③PFSについて ⅰ) PFSのサポート ⅱ) PFSのON/OFFの可否 IKE Main Mode，Aggressive Mode Pre-Shared，電子署名 Entrust(Redy)，PKCS #7/#10 対応CA局 DES，3DES，CAST，AES MD5，SHA-1 1,2,5 サポート 5min ∼50日 ------送信：ID_IPV4_ADDR ESP，AH DES，3DES，CAST，AES HMAC-MD5，HMAC-SHA1 1,2,5 サポート 2min ∼ 24h サポート 1GB以上 LZS ---ID_IPV4_ADDR，ID_IPV4_SUBNET ○ ○ 3．運用管理について ①設定方法について ⅰ) 設定方法 ⅱ) リモートからの設定変更の可否 - 可能な場合は、どの様に行うか？ ②運用管理について ⅰ) SAの状況確認の可否 - 可能な場合は、どの様に行うか？ ⅱ) SAの削除の可否 - 可能な場合は、どの様に行うか？ ⅲ) 相手毎のSA削除の可否 - 可能な場合は、どの様に行うか？ ⅳ) SA削除のリモート操作の可否 - 可能な場合は、どの様に行うか？ ③LOGについて ⅰ) IKEのネゴシエーションがLOGに残るか？ - 可能な場合は、LOGの確認方法 ⅱ) LOGの保存期間 ⅲ) LOGのExport機能の可否 - 可能な場合は、どの形式で可能か？ ④その他 ⅰ) Decrypt Keyを確認する事は可能か？ 専用ツール 可 専用ツールで行う。 残る 専用ツールでLOGを確認 特に無し（コマンドによるLOGの切替えまで保存されて いる。) 可 テキストファイル ○ 4．IKE その他パラメータについて 1) IKE Config Mode 2) Xauth 3) Crack サポート ------- パラメータ確認シート 製品名： RapidStream Security Appliance 製造メーカ：RapidStream Version： 3.0.2 1．製品について 1) 製品形態 - ﾊｰﾄﾞｳｪｱ製品の場合は各ｼﾘｰｽﾞの型番とｻﾎﾟｰﾄIF - ｿﾌﾄｳｪｱ製品の場合は、ｻﾎﾟｰﾄするﾌﾟﾗｯﾄﾌｫｰﾑ 2) 製品定価 RSSA-500(10/100BASE-T) RSSA-1000(10/100BASE-T) RSSA-2000(10/100BASE-T) RSSA-6000(10/100BASE-T) RSSA-8000(10/100BASE-T、1000BASE-SX)] 18万5000円∼ 2．鍵管理について 1) サポートしている鍵交換手法 2) IKEパラメータについて ①Phase１パラメータ ⅰ) サポートしているモード ⅱ) 相互認証方式 - 電子署名の場合の対応CA局 ⅲ) 暗号アルゴリズム ⅳ) 認証アルゴリズム ⅴ) DHグループ ⅵ) 有効期間 ｱ)Life Type (Time) ｲ) Life Duration (Time) ｳ) Life Type (KB) ｴ) Life Duration (KB) ⅶ) IDペイロード ②Phase2 パラメータについて ⅰ) サポートしているTransform ⅱ) 暗号アルゴリズム ⅲ) 認証アルゴリズム ⅳ) DHグループ ⅴ) 有効期間 ｱ)Life Type (Time) ｲ) Life Duration (Time) ｳ) Life Type (KB) ｴ) Life Duration (KB) ｵ）IPComp Compression Algorithms ｶ）NAT-Traversal ⅵ) IDペイロード ③PFSについて ⅰ) PFSのサポート ⅱ) PFSのON/OFFの可否 IKE Main/Aggressive RSA,DSS,Pre-Shared Entrust、Baltimore、RSA Security、Microsoft、VeriSign、SSH DES、３DES MD5、SHA-1 DH１、DH2 ある。 1min∼無制限 ある。 1∼約4TB、無制限 IPV4_ADDR、IPV4_ADDR_SUBNET、IPV4_ADDR_RANGE ESP、AH DES、３DES MD5、SHA-1 DH１、DH2 ある。 1min∼無制限 ある。 1∼約4TB、無制限 無し 無し IPV4_ADDR、IPV4_ADDR_SUBNET、IPV4_ADDR_RANGE ある。 可能 3．運用管理について ①設定方法について ⅰ) 設定方法 ⅱ) リモートからの設定変更の可否 - 可能な場合は、どの様に行うか？ ②運用管理について ⅰ) SAの状況確認の可否 - 可能な場合は、どの様に行うか？ ⅱ) SAの削除の可否 - 可能な場合は、どの様に行うか？ ⅲ) 相手毎のSA削除の可否 - 可能な場合は、どの様に行うか？ ⅳ) SA削除のリモート操作の可否 - 可能な場合は、どの様に行うか？ ③LOGについて ⅰ) IKEのネゴシエーションがLOGに残るか？ - 可能な場合は、LOGの確認方法 ⅱ) LOGの保存期間 ⅲ) LOGのExport機能の可否 - 可能な場合は、どの形式で可能か？ ④その他 ⅰ) Decrypt Keyを確認する事は可能か？ RapidStream Manager、コマンドラインインターフェイス、Centralized Policy Management System（CPM）(集中管理ソフト）、Telnet、SSH（Secure Shell）にて可能 可能 上記の各手法にて 可能 RapidStream ManagerのLog Managerにて確認可能 可能 RapidStream ManagerのSystem InformationのTunnelsにて削除可能 可能 RapidStream ManagerのSystem InformationのTunnelsにて削除可能 可能 RapidStream ManagerのSystem InformationのTunnelsにて削除可能 残らない ログ容量がある限り。またRSSA-500とRSSA-1000は再起動するとLOGが削除される。 可能 rsl形式で保存。ワードパットでも閲覧可能。Syslogに書き出し可能 否 4．IKE その他パラメータについて 1) IKE Config Mode 2) Xauth 3) Crack 解りません Extended User Authentication（ユーザ認証）ならあります。 解りません パラメータ確認シート 製品名： NetScreen-10 製造メーカ：NetScreen Version： 3.0.0r3 1．製品について 1) 製品形態 - ﾊｰﾄﾞｳｪｱ製品の場合は各ｼﾘｰｽﾞの型番とｻﾎﾟｰﾄIF - ｿﾌﾄｳｪｱ製品の場合は、ｻﾎﾟｰﾄするﾌﾟﾗｯﾄﾌｫｰﾑ 2) 製品定価 ハードウェア NetScreen-10 10BASE-T×３ 798,000- （但し、このハードウェア型番は、最近販売終息） 2．鍵管理について 1) サポートしている鍵交換手法 2) IKEパラメータについて ①Phase１パラメータ ⅰ) サポートしているモード ⅱ) 相互認証方式 - 電子署名の場合の対応CA局 ⅲ) 暗号アルゴリズム ⅳ) 認証アルゴリズム ⅴ) DHグループ ⅵ) 有効期間 ｱ)Life Type (Time) ｲ) Life Duration (Time) ｳ) Life Type (KB) ｴ) Life Duration (KB) ⅶ) IDペイロード ②Phase2 パラメータについて ⅰ) サポートしているTransform ⅱ) 暗号アルゴリズム ⅲ) 認証アルゴリズム ⅳ) DHグループ ⅴ) 有効期間 ｱ)Life Type (Time) ｲ) Life Duration (Time) ｳ) Life Type (KB) ｴ) Life Duration (KB) ｵ）IPComp Compression Algorithms ｶ）NAT-Traversal ⅵ) IDペイロード ③PFSについて ⅰ) PFSのサポート ⅱ) PFSのON/OFFの可否 IKE , Manual IPSEC Main Mode, Aggressive Mode Pre-Shared , CA VeriSign , Entrust , Microsoft , RSA Keon , iPlanet , Baltimore , DOD PKI DES , 3DES , AES MD5 , SHA-1 1,2,5 ○ 180秒∼ ○ 0kbyte∼ IPv4、Domain Name、User Name AH、ESP,AH+ESP DES , 3DES , AES MD5 , SHA-1 1,2,5 ○ 180秒∼ ○ 0kbyte∼ × ○ IPv4、IPv4_Subnet ○ ○ 3．運用管理について ①設定方法について ⅰ) 設定方法 ⅱ) リモートからの設定変更の可否 - 可能な場合は、どの様に行うか？ ②運用管理について ⅰ) SAの状況確認の可否 - 可能な場合は、どの様に行うか？ ⅱ) SAの削除の可否 - 可能な場合は、どの様に行うか？ ⅲ) 相手毎のSA削除の可否 - 可能な場合は、どの様に行うか？ ⅳ) SA削除のリモート操作の可否 - 可能な場合は、どの様に行うか？ ③LOGについて ⅰ) IKEのネゴシエーションがLOGに残るか？ - 可能な場合は、LOGの確認方法 ⅱ) LOGの保存期間 ⅲ) LOGのExport機能の可否 - 可能な場合は、どの形式で可能か？ ④その他 ⅰ) Decrypt Keyを確認する事は可能か？ WWWブラウザ(http/https) , ssh , telnet , console 可能 WWWブラウザ(http/https) , ssh , telnet 可能 WWWブラウザ(http/https) , ssh , telnet , console 可能 ssh , telnet , consoleによるコマンド操作 可能 ssh , telnet , consoleによるコマンド操作 可能 ssh , telnet によるコマンド操作 残る WWWブラウザ又はコマンド入力 決まっていない(ログ領域の内、古いものから上書きする） 可能 テキストファイル形式 不可 4．IKE その他パラメータについて 1) IKE Config Mode 2) Xauth 3) Crack × ○ × パラメータ確認シート 製品名： ContivityVPNSwitch 製造メーカ：NortelNetworks Version： v03_60.45 1．製品について 1) 製品形態 - ﾊｰﾄﾞｳｪｱ製品の場合は各ｼﾘｰｽﾞの型番とｻﾎﾟｰﾄIF - ｿﾌﾄｳｪｱ製品の場合は、ｻﾎﾟｰﾄするﾌﾟﾗｯﾄﾌｫｰﾑ 2) 製品定価 ハードウェア 型番：Contivity600、Contivity1６０0、Contivity2600、Contivity4600 ＩＦ：Ethernet (10M/100M 自動認識) × 2 ￥５５２，０００−∼ 2．鍵管理について 1) サポートしている鍵交換手法 2) IKEパラメータについて ①Phase１パラメータ ⅰ) サポートしているモード ⅱ) 相互認証方式 - 電子署名の場合の対応CA局 ⅲ) 暗号アルゴリズム ⅳ) 認証アルゴリズム ⅴ) DHグループ ⅵ) 有効期間 ｱ)Life Type (Time) ｲ) Life Duration (Time) ｳ) Life Type (KB) ｴ) Life Duration (KB) ⅶ) IDペイロード ②Phase2 パラメータについて ⅰ) サポートしているTransform ⅱ) 暗号アルゴリズム ⅲ) 認証アルゴリズム ⅳ) DHグループ ⅴ) 有効期間 ｱ)Life Type (Time) ｲ) Life Duration (Time) ｳ) Life Type (KB) ｴ) Life Duration (KB) ｵ）IPComp Compression Algorithms ｶ）NAT-Traversal ⅵ) IDペイロード ③PFSについて ⅰ) PFSのサポート ⅱ) PFSのON/OFFの可否 IKE Main mode、Aggressive mode (受けのみ） Pre-Shared Key、電子署名 Entrust（Ready)、Verisign DES、３DES(128bit) MD5、SHA-1 Group-1、Group-2 (サポート) 0(無し)∼86399s --送信：ID_IPV4_ADDR，受信：ID_IPV4_ADDR， ESP，AH DES，3DES(128bit) HMAC-MD5，HMAC-SHA1 Group-1、Group-2 (サポート) 0(無し)∼86399s (サポート) 1kb∼4,294,967,295kb LZS なし ID_IPV4_ADDR，ID_IPV4_SUBNET (サポート) 可 3．運用管理について ①設定方法について ⅰ) 設定方法 ⅱ) リモートからの設定変更の可否 - 可能な場合は、どの様に行うか？ ②運用管理について ⅰ) SAの状況確認の可否 - 可能な場合は、どの様に行うか？ ⅱ) SAの削除の可否 - 可能な場合は、どの様に行うか？ ⅲ) 相手毎のSA削除の可否 - 可能な場合は、どの様に行うか？ ⅳ) SA削除のリモート操作の可否 - 可能な場合は、どの様に行うか？ ③LOGについて ⅰ) IKEのネゴシエーションがLOGに残るか？ - 可能な場合は、LOGの確認方法 ⅱ) LOGの保存期間 ⅲ) LOGのExport機能の可否 - 可能な場合は、どの形式で可能か？ ④その他 ⅰ) Decrypt Keyを確認する事は可能か？ Webベース管理ツールより 可 Webベース管理ツールより 可 Webベース管理ツールより 可 Webベース管理ツールより 可 Webベース管理ツールより 可 Webベース管理ツールより 残る Webベース管理ツールより 特に無し（コマンドによるLOGの切替えまで保存されている。) 可 SYSLOG 不可 4．IKE その他パラメータについて 1) IKE Config Mode 2) Xauth 3) Crack RemoteClientVPNで使用 − ？ パラメータ確認シート 製品名： Cryptopia-100 製造メーカ：三菱電機（株） Version： 2.2.2 1．製品について 1) 製品形態 - ﾊｰﾄﾞｳｪｱ製品の場合は各ｼﾘｰｽﾞの型番とｻﾎﾟｰﾄIF - ｿﾌﾄｳｪｱ製品の場合は、ｻﾎﾟｰﾄするﾌﾟﾗｯﾄﾌｫｰﾑ 2) 製品定価 ハードウェア 10Base-T／100Base‐TX×2 未定 2．鍵管理について 1) サポートしている鍵交換手法 2) IKEパラメータについて ①Phase１パラメータ ⅰ) サポートしているモード ⅱ) 相互認証方式 - 電子署名の場合の対応CA局 ⅲ) 暗号アルゴリズム ⅳ) 認証アルゴリズム ⅴ) DHグループ ⅵ) 有効期間 ｱ)Life Type (Time) ｲ) Life Duration (Time) ｳ) Life Type (KB) ｴ) Life Duration (KB) ⅶ) IDペイロード ②Phase2 パラメータについて ⅰ) サポートしているTransform ⅱ) 暗号アルゴリズム ⅲ) 認証アルゴリズム ⅳ) DHグループ ⅴ) 有効期間 ｱ)Life Type (Time) ｲ) Life Duration (Time) ｳ) Life Type (KB) ｴ) Life Duration (KB) ｵ）IPComp Compression Algorithms ｶ）NAT-Traversal ⅵ) IDペイロード ③PFSについて ⅰ) PFSのサポート ⅱ) PFSのON/OFFの可否 IKE ，Manual IPSEC Main Mode, Aggressive Mode Pre-Shared, 電子署名 PKCS#10とPKCS#7／X.509認証書、またはPKCS#12に対応可能なCA DES, 3DES, MISTY MD5, SHA1 Group-1,Group-2 サポート 90∼4294967295(sec) サポート 0, 512∼4294967295(KB) ID_IPV4_ADDR（送受信）、ID_DER_ASN1_DN（送受信）、ID_FQDN（受信） ESP, AH DES, 3DES, MISTY HMAC-MD5, HMAC-SHA1 Group-1,Group-2 サポート 75∼4294967295(sec)：推奨値 サポート 0, 20480∼4294967295(KB)：推奨値 未サポート 未サポート ID_IPV4_ADDR, ID_IPV4_SUBNET サポート 可 3．運用管理について ①設定方法について ⅰ) 設定方法 ⅱ) リモートからの設定変更の可否 - 可能な場合は、どの様に行うか？ ②運用管理について ⅰ) SAの状況確認の可否 - 可能な場合は、どの様に行うか？ ⅱ) SAの削除の可否 - 可能な場合は、どの様に行うか？ ⅲ) 相手毎のSA削除の可否 - 可能な場合は、どの様に行うか？ ⅳ) SA削除のリモート操作の可否 - 可能な場合は、どの様に行うか？ ③LOGについて ⅰ) IKEのネゴシエーションがLOGに残るか？ - 可能な場合は、LOGの確認方法 ⅱ) LOGの保存期間 ⅲ) LOGのExport機能の可否 - 可能な場合は、どの形式で可能か？ ④その他 ⅰ) Decrypt Keyを確認する事は可能か？ シリアルコンソール 否 （開発中：管理マネージャによるリモート操作機能） 可 シリアルコンソールで表示 可 シリアルコンソールでコマンド入力 可 シリアルコンソールでコマンド入力 否 残る シリアルコンソールで表示（syslog とコマンド入力によるSA状況確認） 時間制限なし（syslog領域を使い切った場合、古いものから上書きする） 可能 バイナリファイルとしてPCにFTP可能 バージョンによっては可能 4．IKE その他パラメータについて 1) IKE Config Mode 2) Xauth 3) Crack なし なし なし パラメータ確認シート 製品名： VPN3000 製造メーカ：Cisco Version： 1．製品について 1) 製品形態 - ﾊｰﾄﾞｳｪｱ製品の場合は各ｼﾘｰｽﾞの型番とｻﾎﾟｰﾄIF - ｿﾌﾄｳｪｱ製品の場合は、ｻﾎﾟｰﾄするﾌﾟﾗｯﾄﾌｫｰﾑ 2) 製品定価 VPN3005 VPN3015 VPN3030-NR VPN3030-RED VPN3060-NR VPN3060-RED VPN3080 VPN3005：10/100BaseTXファーストイーサネット×2 VPN3015：10/100BaseTXファーストイーサネット×3 VPN3030：10/100BaseTXファーストイーサネット×3 VPN3060：10/100BaseTXファーストイーサネット×3 VPN3080：10/100BaseTXファーストイーサネット×3 ¥516,000（本体価格）＋¥172,000（ソフトウェア価格） ¥1,805,000（本体価格）＋¥344,000（ソフトウェア価格） ¥2,923,000（本体価格）＋¥860,000（ソフトウェア価格） ¥4,642,000（本体価格）＋¥860,000（ソフトウェア価格） ¥4,642,000（本体価格）＋¥2,235,000（ソフトウェア価格） ¥6,362,000（本体価格）＋¥2,235,000（ソフトウェア価格） ¥8,597,000（本体価格）＋¥4,298,000（ソフトウェア価格） 2．鍵管理について 1) サポートしている鍵交換手法 2) IKEパラメータについて ①Phase１パラメータ ⅰ) サポートしているモード ⅱ) 相互認証方式 - 電子署名の場合の対応CA局 ⅲ) 暗号アルゴリズム ⅳ) 認証アルゴリズム ⅴ) DHグループ ⅵ) 有効期間 ｱ)Life Type (Time) ｲ) Life Duration (Time) ｳ) Life Type (KB) ｴ) Life Duration (KB) ⅶ) IDペイロード ②Phase2 パラメータについて ⅰ) サポートしているTransform ⅱ) 暗号アルゴリズム ⅲ) 認証アルゴリズム ⅳ) DHグループ ⅴ) 有効期間 ｱ)Life Type (Time) ｲ) Life Duration (Time) ｳ) Life Type (KB) ｴ) Life Duration (KB) ｵ）IPComp Compression Algorithms ｶ）NAT-Traversal ⅵ) IDペイロード ③PFSについて ⅰ) PFSのサポート ⅱ) PFSのON/OFFの可否 Main Mode ,Aggressive Mode Preshared Keys ,RSA Digital Certificate,DSA Digital Certificate Baltimore,CyberTrust,Entrust,Microsoft Windows2000,RSA Keon,VeriSign DES-56,3DES-168 MD5/HMAC128 ,SHA/HMAC-160 Group1(768bit),Group2(1024bit) ,Group7(163bit) ○ 60∼2,147,483,647Sec(86,400Sec) ○ 100∼2,147,483,647KByte(10,000KByte) Null,DES-56,3DES-168 None,MD5/HMAC-128 ,SHA/HMAC-160 ○ （28,800Sec） ○ （10,000KByte） Cisco独自機能、リモートクライアントはVPN3000Clientであること ○ 可 3．運用管理について ①設定方法について ⅰ) 設定方法 ⅱ) リモートからの設定変更の可否 - 可能な場合は、どの様に行うか？ ②運用管理について ⅰ) SAの状況確認の可否 - 可能な場合は、どの様に行うか？ ⅱ) SAの削除の可否 - 可能な場合は、どの様に行うか？ ⅲ) 相手毎のSA削除の可否 - 可能な場合は、どの様に行うか？ ⅳ) SA削除のリモート操作の可否 - 可能な場合は、どの様に行うか？ ③LOGについて ⅰ) IKEのネゴシエーションがLOGに残るか？ - 可能な場合は、LOGの確認方法 ⅱ) LOGの保存期間 ⅲ) LOGのExport機能の可否 - 可能な場合は、どの形式で可能か？ ④その他 ⅰ) Decrypt Keyを確認する事は可能か？ 初期設定はコンソールからCLIを使用して設定を行う 初期設定後は以下の2通りの方法で設定を行うことが可能 次の接続を経由して,標準のWebブラウザを使用してHTMLベースで設定可能 HTTP,HTTPS ローカル・システム・コンソールまたは次の接続を経由して、CLIベースで設定可能 Telnet,Telnet over SSL,SSH 可 上に同じ 可 VPN Concentrator ManagerにてAdministration｜Sessionsを選択すると、 VPN Concentrator上のアクティブ・セッションが表示される 可 Administration｜Sessionsの画面のLogoutセクションにて、 削除するトンネルタイプを選択する 選択したトンネルタイプのすべてのセッションが削除される 否 ※相手毎ではなく、トンネルタイプ毎になる 可 HTTPもしくはHTTPSでVPN Concentrator Managerに接続する 可 ※要設定 VPN Concentrator ManagerにてMonitoring | Filterable Event Logを選択 VPN3005は256個、VPN3015-VPN3080は2048個のイベントを不揮発性メモリに保持可 能 ※Syslogサーバーへの転送も可 可 TXT形式ファイルをFTPで転送 否 4．IKE その他パラメータについて 1) IKE Config Mode 2) Xauth 3) Crack ○ ○ 内部サーバ、RADIUSサーバ、NT Domainサーバ、SDIサーバを指定可能 ？ パラメータ確認シート 製品名： AR720 製造メーカ：アライドテレシス株式会社 Version： 2.3.2 1．製品について 1) 製品形態 - ﾊｰﾄﾞｳｪｱ製品の場合は各ｼﾘｰｽﾞの型番とｻﾎﾟｰﾄIF - ｿﾌﾄｳｪｱ製品の場合は、ｻﾎﾟｰﾄするﾌﾟﾗｯﾄﾌｫｰﾑ 2) 製品定価 AR720（Eth（10/100M固定１Port、拡張スロットで10MEth、BRI、PRI、SYNC） ¥198,000 2．鍵管理について 1) サポートしている鍵交換手法 2) IKEパラメータについて ①Phase１パラメータ ⅰ) サポートしているモード ⅱ) 相互認証方式 - 電子署名の場合の対応CA局 ⅲ) 暗号アルゴリズム ⅳ) 認証アルゴリズム ⅴ) DHグループ ⅵ) 有効期間 ｱ)Life Type (Time) ｲ) Life Duration (Time) ｳ) Life Type (KB) ｴ) Life Duration (KB) ⅶ) IDペイロード ②Phase2 パラメータについて ⅰ) サポートしているTransform ⅱ) 暗号アルゴリズム ⅲ) 認証アルゴリズム ⅳ) DHグループ ⅴ) 有効期間 ｱ)Life Type (Time) ｲ) Life Duration (Time) ｳ) Life Type (KB) ｴ) Life Duration (KB) ｵ）IPComp Compression Algorithms ｶ）NAT-Traversal ⅵ) IDペイロード ③PFSについて ⅰ) PFSのサポート ⅱ) PFSのON/OFFの可否 手動鍵とIKEプロトコルによる自動鍵交換をサポート Main mode、Aggressive mode Pre-sheared Key、X.509デジタル署名（RSA Signature）、ISAKMP-XAUTH Entrust PKI 5.1.1（PKCS#10、CMPv1）、SSH（PKCS#10） DES MD5、SHA1 Group0、1、2 seconds 600-31449600 Kilo Bytes 1-1000 ID_IPV4_ADDR、ID_FQDN、ID_USER_FQDN、ID_DER_ASN_DN AH/ESP/IPCOMP(Transport/Tunnel いずれもサポート) DES MD5、SHA1 Group0、1、2 seconds 300-31449600 Kilo Bytes 1-2000000000 サポート ESP over UDPでサポート ID_IPV4_ADDR、ID_IPV4_ADDR_SUBNET、ID_IPV4_ADDR_RANGE、ID_FQDN サポート サポート 3．運用管理について ①設定方法について ⅰ) 設定方法 ⅱ) リモートからの設定変更の可否 - 可能な場合は、どの様に行うか？ ②運用管理について ⅰ) SAの状況確認の可否 - 可能な場合は、どの様に行うか？ ⅱ) SAの削除の可否 - 可能な場合は、どの様に行うか？ ⅲ) 相手毎のSA削除の可否 - 可能な場合は、どの様に行うか？ ⅳ) SA削除のリモート操作の可否 - 可能な場合は、どの様に行うか？ ③LOGについて ⅰ) IKEのネゴシエーションがLOGに残るか？ - 可能な場合は、LOGの確認方法 ⅱ) LOGの保存期間 ⅲ) LOGのExport機能の可否 - 可能な場合は、どの形式で可能か？ ④その他 ⅰ) Decrypt Keyを確認する事は可能か？ コマンド 可能 TELNET 可能 コマンド「sh isakmp sa」「sh ipsec sa」にて確認 可能 コマンド「disable isakmp」「dis ipsec」後「enable isakmp」「ena ipsec」にて削除可能 不可 可能 TELNETにてLoginし、ii)と同様の操作にて可能 可能 コマンド「sh log」にて確認可能 メモリの許容範囲内（RebootするとLogは消去される） 可能 SYSLOGサーバにLoｇを出力可能 可能 4．IKE その他パラメータについて 1) IKE Config Mode 2) Xauth 3) Crack XAUTH サポート Generic／RADIUS 未サポート パラメータ確認シート 製品名： NetStructure VPN 製造メーカ： Intel Version： 7.0 1．製品について 1) 製品形態 - ﾊｰﾄﾞｳｪｱ製品の場合は各ｼﾘｰｽﾞの型番とｻﾎﾟｰﾄIF - ｿﾌﾄｳｪｱ製品の場合は、ｻﾎﾟｰﾄするﾌﾟﾗｯﾄﾌｫｰﾑ 2) 製品定価 3110、3400、3450、3150 598,000円∼ 2．鍵管理について 1) サポートしている鍵交換手法 2) IKEパラメータについて ①Phase１パラメータ ⅰ) サポートしているモード ⅱ) 相互認証方式 - 電子署名の場合の対応CA局 ⅲ) 暗号アルゴリズム ⅳ) 認証アルゴリズム ⅴ) DHグループ ⅵ) 有効期間 ｱ)Life Type (Time) ｲ) Life Duration (Time) ｳ) Life Type (KB) ｴ) Life Duration (KB) ⅶ) IDペイロード ②Phase2 パラメータについて ⅰ) サポートしているTransform ⅱ) 暗号アルゴリズム ⅲ) 認証アルゴリズム ⅳ) DHグループ ⅴ) 有効期間 ｱ)Life Type (Time) ｲ) Life Duration (Time) ｳ) Life Type (KB) ｴ) Life Duration (KB) ｵ）IPComp Compression Algorithms ｶ）NAT-Traversal ⅵ) IDペイロード ③PFSについて ⅰ) PFSのサポート ⅱ) PFSのON/OFFの可否 IKE ，Manual IPSEC、L2TP Over IPSec、SST Main、Aggressive Pre-Shared、CA、RADIUS、SecureID Entrust、NetStructure CA DES、3DES MD5、SHA-1 1∼5、7 対応 0、3分∼22日 対応 0、100,00kbyte∼2,147,483,647kbyte IPv4、Distiguished Name、Domain Name、E-Mail Address AH、ESP,AH+ESP DES、3DES、AES（128bit、192bit、256bit） MD5、SHA-1 1∼5、7 対応 0、3分∼22日 対応 0、100,00kbyte∼2,147,483,647kbyte 未対応 独自仕様で対応 IPv4、IPv4_Subnet 対応 可能 3．運用管理について ①設定方法について ⅰ) 設定方法 ⅱ) リモートからの設定変更の可否 - 可能な場合は、どの様に行うか？ ②運用管理について ⅰ) SAの状況確認の可否 - 可能な場合は、どの様に行うか？ ⅱ) SAの削除の可否 - 可能な場合は、どの様に行うか？ ⅲ) 相手毎のSA削除の可否 - 可能な場合は、どの様に行うか？ ⅳ) SA削除のリモート操作の可否 - 可能な場合は、どの様に行うか？ ③LOGについて ⅰ) IKEのネゴシエーションがLOGに残るか？ - 可能な場合は、LOGの確認方法 ⅱ) LOGの保存期間 ⅲ) LOGのExport機能の可否 - 可能な場合は、どの形式で可能か？ ④その他 ⅰ) Decrypt Keyを確認する事は可能か？ 管理ソフト、TELNET、Console 可能 管理ソフトかTELNETにて設定 可能 管理ソフト、TELNET、Console 可能 管理ソフト、TELNET、Console 可能 管理ソフト、TELNET、Console 可能 管理ソフト、TELNET 残る Syslog、Console 特になし 可能 Syslog 不可 4．IKE その他パラメータについて 1) IKE Config Mode 2) Xauth 3) Crack 対応 対応 未対応 パラメータ確認シート 製品名： 713X SecureVPN Gateway Series（Offline) 製造メーカ：Alcatel Version： v3.11.021(Offline) 1．製品について 1) 製品形態 - ﾊｰﾄﾞｳｪｱ製品の場合は各ｼﾘｰｽﾞの型番とｻﾎﾟｰﾄIF - ｿﾌﾄｳｪｱ製品の場合は、ｻﾎﾟｰﾄするﾌﾟﾗｯﾄﾌｫｰﾑ 2) 製品定価 ハードウェア 1520,2520,4620(10BaseT) 7520(100Base/TX) 2．鍵管理について 1) サポートしている鍵交換手法 2) IKEパラメータについて ①Phase１パラメータ ⅰ) サポートしているモード ⅱ) 相互認証方式 - 電子署名の場合の対応CA局 ⅲ) 暗号アルゴリズム ⅳ) 認証アルゴリズム ⅴ) DHグループ ⅵ) 有効期間 ｱ)Life Type (Time) ｲ) Life Duration (Time) ｳ) Life Type (KB) ｴ) Life Duration (KB) ⅶ) IDペイロード ②Phase2 パラメータについて ⅰ) サポートしているTransform ⅱ) 暗号アルゴリズム ⅲ) 認証アルゴリズム ⅳ) DHグループ ⅴ) 有効期間 ｱ)Life Type (Time) ｲ) Life Duration (Time) ｳ) Life Type (KB) ｴ) Life Duration (KB) ⅵ) IDペイロード ③PFSについて ⅰ) PFSのサポート ⅱ) PFSのON/OFFの可否 IKE Main Mode，Aggressive Mode Pre-Shared，電子署名 SSH，Baltimore等のPKCS#10発行要求，PKCS#7署名済みファイル発行可能なCA DES,3DES,CAST,RC5,Blowfish,IDEA(optional) MD5,SHA-1 1,2,5 サポート 5minから252,600min(365days) サポート 300kbyteから1,073,741,824kbytes(1Tbytes) ID_IPV4_ADD, ID_IPV4_SUBNET, ID_IPV4_RANGE ESP,AH DES,3DES,CAST,Blowfish,IDEA(optional) MD5,SHA-1 1,2,5 サポート 5minから252,600min(365days) サポート 300kbyteから1,073,741,824kbytes(1Tbytes) ID_IPV4_ADD, ID_IPV4_SUBNET, ID_IPV4_RANGE サポート 可 3．運用管理について ①設定方法について ⅰ) 設定方法 ⅱ) リモートからの設定変更の可否 - 可能な場合は、どの様に行うか？ ②運用管理について ⅰ) SAの状況確認の可否 - 可能な場合は、どの様に行うか？ ⅱ) SAの削除の可否 - 可能な場合は、どの様に行うか？ ⅲ) 相手毎のSA削除の可否 - 可能な場合は、どの様に行うか？ ⅳ) SA削除のリモート操作の可否 - 可能な場合は、どの様に行うか？ ③LOGについて ⅰ) IKEのネゴシエーションがLOGに残るか？ - 可能な場合は、LOGの確認方法 ⅱ) LOGの保存期間 ⅲ) LOGのExport機能の可否 - 可能な場合は、どの形式で可能か？ ④その他 ⅰ) Decrypt Keyを確認する事は可能か？ 専用ツール(管理用ソフトウェア) 可 専用ツールで行う。 可 専用ツールおよびシリアルコンソール 可 専用ツールおよびシリアルコンソール 不可 可 専用ツールおよびシリアルコンソール 残る 専用ツールおよびシリアルコンソールからの閲覧 特に無し（消去コマンドを実行しなければ300行) 可 syslogまたはテキストファイル 不可 パラメータ確認シート 製品名： 713X SecureVPN Gateway Series（Offline) 製造メーカ：Alcatel Version： v3.11.021(Offline) 1．製品について 1) 製品形態 - ﾊｰﾄﾞｳｪｱ製品の場合は各ｼﾘｰｽﾞの型番とｻﾎﾟｰﾄIF - ｿﾌﾄｳｪｱ製品の場合は、ｻﾎﾟｰﾄするﾌﾟﾗｯﾄﾌｫｰﾑ 2) 製品定価 ハードウェア 1520,2520,4620(10BaseT) 7520(100Base/TX) 2．鍵管理について 1) サポートしている鍵交換手法 2) IKEパラメータについて ①Phase１パラメータ ⅰ) サポートしているモード ⅱ) 相互認証方式 - 電子署名の場合の対応CA局 ⅲ) 暗号アルゴリズム ⅳ) 認証アルゴリズム ⅴ) DHグループ ⅵ) 有効期間 ｱ)Life Type (Time) ｲ) Life Duration (Time) ｳ) Life Type (KB) ｴ) Life Duration (KB) ⅶ) IDペイロード ②Phase2 パラメータについて ⅰ) サポートしているTransform ⅱ) 暗号アルゴリズム ⅲ) 認証アルゴリズム ⅳ) DHグループ ⅴ) 有効期間 ｱ)Life Type (Time) ｲ) Life Duration (Time) ｳ) Life Type (KB) ｴ) Life Duration (KB) ⅵ) IDペイロード ③PFSについて ⅰ) PFSのサポート ⅱ) PFSのON/OFFの可否 IKE Main Mode，Aggressive Mode Pre-Shared，電子署名 Entrust Ready DES,3DES,CAST,RC5,Blowfish,IDEA(optional) MD5,SHA-1 1,2,5 サポート 5minから252,600min(365days) サポート 300kbyteから1,073,741,824kbytes(1Tbytes) ID_IPV4_ADD, ID_IPV4_SUBNET, ID_IPV4_RANGE ESP,AH DES,3DES,CAST,Blowfish,IDEA(optional) MD5,SHA-1 1,2,5 サポート 5minから252,600min(365days) サポート 300kbyteから1,073,741,824kbytes(1Tbytes) ID_IPV4_ADD, ID_IPV4_SUBNET, ID_IPV4_RANGE サポート 可 3．運用管理について ①設定方法について ⅰ) 設定方法 ⅱ) リモートからの設定変更の可否 - 可能な場合は、どの様に行うか？ ②運用管理について ⅰ) SAの状況確認の可否 - 可能な場合は、どの様に行うか？ ⅱ) SAの削除の可否 - 可能な場合は、どの様に行うか？ ⅲ) 相手毎のSA削除の可否 - 可能な場合は、どの様に行うか？ ⅳ) SA削除のリモート操作の可否 - 可能な場合は、どの様に行うか？ ③LOGについて ⅰ) IKEのネゴシエーションがLOGに残るか？ - 可能な場合は、LOGの確認方法 ⅱ) LOGの保存期間 ⅲ) LOGのExport機能の可否 - 可能な場合は、どの形式で可能か？ ④その他 ⅰ) Decrypt Keyを確認する事は可能か？ 専用ツール(管理用ソフトウェア) 可 専用ツールで行う。 可 専用ツールおよびシリアルコンソール 可 専用ツールおよびシリアルコンソール 不可 可 専用ツールおよびシリアルコンソール 残る 専用ツールおよびシリアルコンソールからの閲覧 特に無し（消去コマンドを実行しなければ300行) 可 syslogまたはテキストファイル 不可 パラメータ確認シート 製品名： VSU100R 製造メーカ：Avaya社 Version： 3.1.58 1．製品について 1) 製品形態 - ﾊｰﾄﾞｳｪｱ製品の場合は各ｼﾘｰｽﾞの型番とｻﾎﾟｰﾄIF - ｿﾌﾄｳｪｱ製品の場合は、ｻﾎﾟｰﾄするﾌﾟﾗｯﾄﾌｫｰﾑ 2) 製品定価 VSU100、VSU１００R、VSU2000、VSU5000、VSU７５００：10/100Mbps ×２ Windows 95、98、NT、Me、2000 2．鍵管理について 1) サポートしている鍵交換手法 2) IKEパラメータについて ①Phase１パラメータ ⅰ) サポートしているモード ⅱ) 相互認証方式 - 電子署名の場合の対応CA局 ⅲ) 暗号アルゴリズム ⅳ) 認証アルゴリズム ⅴ) DHグループ ⅵ) 有効期間 ｱ)Life Type (Time) ｲ) Life Duration (Time) ｳ) Life Type (KB) ｴ) Life Duration (KB) ⅶ) IDペイロード ②Phase2 パラメータについて ⅰ) サポートしているTransform ⅱ) 暗号アルゴリズム ⅲ) 認証アルゴリズム ⅳ) DHグループ ⅴ) 有効期間 ｱ)Life Type (Time) ｲ) Life Duration (Time) ｳ) Life Type (KB) ｴ) Life Duration (KB) ｵ）IPComp Compression Algorithms ｶ）NAT-Traversal ⅵ) IDペイロード ③PFSについて ⅰ) PFSのサポート ⅱ) PFSのON/OFFの可否 トンネルモード、トランスモード Entrust、ボルチモア、 DES、３DES MD5、SHA-1 DH G1、G２ 最小値1分 未サポート サポート 未サポート IP V4、DN ESP、AH DES、３DES MD5、SHA-1 DH G1、G２ 最小値1分 未サポート サポート 未サポート LZS 未サポート IP V4、DN サポート 可 3．運用管理について ①設定方法について ⅰ) 設定方法 ⅱ) リモートからの設定変更の可否 - 可能な場合は、どの様に行うか？ ②運用管理について ⅰ) SAの状況確認の可否 - 可能な場合は、どの様に行うか？ ⅱ) SAの削除の可否 - 可能な場合は、どの様に行うか？ ⅲ) 相手毎のSA削除の可否 - 可能な場合は、どの様に行うか？ ⅳ) SA削除のリモート操作の可否 - 可能な場合は、どの様に行うか？ ③LOGについて ⅰ) IKEのネゴシエーションがLOGに残るか？ - 可能な場合は、LOGの確認方法 ⅱ) LOGの保存期間 ⅲ) LOGのExport機能の可否 - 可能な場合は、どの形式で可能か？ ④その他 ⅰ) Decrypt Keyを確認する事は可能か？ 4．IKE その他パラメータについて 1) IKE Config Mode 2) Xauth 3) Crack シリアル（CUI）、専用GUI 未対応 可 CUI 可 CUI 可 CUI 否 可 CUI 無し 可 テキスト 無し パラメータ確認シート 製品名： IPSec Express Toolkit 製造メーカ：ＳＳＨコミュニケーションズセキュリティ Version： 4.1.1 1．製品について 1) 製品形態 - ﾊｰﾄﾞｳｪｱ製品の場合は各ｼﾘｰｽﾞの型番とｻﾎﾟｰﾄIF - ｿﾌﾄｳｪｱ製品の場合は、ｻﾎﾟｰﾄするﾌﾟﾗｯﾄﾌｫｰﾑ 2) 製品定価 NetBSD, FreeBSD, Solaris, VxWorks, Windows (95/98/Me/NT/2000), Linux 2．鍵管理について 1) サポートしている鍵交換手法 2) IKEパラメータについて ①Phase１パラメータ ⅰ) サポートしているモード ⅱ) 相互認証方式 - 電子署名の場合の対応CA局 ⅲ) 暗号アルゴリズム ⅳ) 認証アルゴリズム ⅴ) DHグループ ⅵ) 有効期間 ｱ)Life Type (Time) ｲ) Life Duration (Time) ｳ) Life Type (KB) ｴ) Life Duration (KB) ⅶ) IDペイロード ②Phase2 パラメータについて ⅰ) サポートしているTransform ⅱ) 暗号アルゴリズム ⅲ) 認証アルゴリズム ⅳ) DHグループ ⅴ) 有効期間 ｱ)Life Type (Time) ｲ) Life Duration (Time) ｳ) Life Type (KB) ｴ) Life Duration (KB) ｵ）IPComp Compression Algorithms ｶ）NAT-Traversal ⅵ) IDペイロード ③PFSについて ⅰ) PFSのサポート ⅱ) PFSのON/OFFの可否 Main, Aggressive, Quick, Config, New Group 既知共有鍵、RSA 署名、ＤＳＡ署名、ＲＳＡ暗号 SSH Certifier, Baltimore, Entrust, Verisign AES (Rijndael), 3DES, 3DES, Blowfish, Twofish, CAST128 MD5, SHA-1, RIPEMD, TIGER 1 (MODP 768), 2 (MODP 1024), 5 (MODP 1536) ○ 1秒∼2^32秒 ○ 1ＫＢ∼2＾32KB IPV4_ADDR[_SUBNET,_RANGE],FQDN,USER_FQDN,IPV6[_SUBNET,_RANGE],ASN1_{GN,DN} ESPﾄﾝﾈﾙ､ﾄﾗﾝｽﾎﾟｰﾄ､AHﾄﾝﾈﾙ､ﾄﾗﾝｽﾎﾟｰﾄ､IPIP AES (Rijndael, 128/192/256bit), 3DES, 3DES, Blowfish (40-446bit), Twofish (128/192/256bit), CAST128, Null HMAC-MD5-96, HMAC-SHA1-96 1 (MODP 768), 2 (MODP 1024), 5 (MODP 1536) ○ 1秒∼2^32秒 ○ 1KB∼2^32KB Ｄｅｆｌａｔｅ，LZS (オプション） 現在：draft-stenberg-ipsec-nat-traversal-02.txt 試験で：draft-ietf-ipsec-nat-t-ike-00,draftietf-ipsec-udp-encaps-01 IPV4_ADDR[_SUBNET,_RANGE],IPV6[_SUBNET,_RANGE] ○ ○ 3．運用管理について ①設定方法について ⅰ) 設定方法 ⅱ) リモートからの設定変更の可否 - 可能な場合は、どの様に行うか？ ②運用管理について ⅰ) SAの状況確認の可否 - 可能な場合は、どの様に行うか？ ⅱ) SAの削除の可否 - 可能な場合は、どの様に行うか？ ⅲ) 相手毎のSA削除の可否 - 可能な場合は、どの様に行うか？ ⅳ) SA削除のリモート操作の可否 - 可能な場合は、どの様に行うか？ ③LOGについて ⅰ) IKEのネゴシエーションがLOGに残るか？ - 可能な場合は、LOGの確認方法 ⅱ) LOGの保存期間 ⅲ) LOGのExport機能の可否 - 可能な場合は、どの形式で可能か？ ④その他 ⅰ) Decrypt Keyを確認する事は可能か？ ASCIIファイル、それともCのAPI リロード以外不可能 可能 HTTP管理インターフェイス 可能 全てのSAをHTTP管理インターフェイスで削除 可能 全てのSAをHTTP管理インターフェイスで削除、IKEデレートを送信 可能 全てのSAをHTTP管理インターフェイスで削除、IKEデレートを送信 可能 PMアプリケーションをデバグフラグと実行して、標準出力 不限定 可能 普段のFTP等 可能(デバグフラグを使用） 4．IKE その他パラメータについて 1) IKE Config Mode 2) Xauth 3) Crack 他のファイルで設定可能パラメータ： compatibility options: /* /* /* /* /* /* /* ignore certificate request payloads no certificate hash in public key encryption authentication no certificate request payloads no crl payloads send full cert chains Doi = draft-ietf-ipsec-ipsec-doi-03,04,05,06,07,08,09,10.txt */ Isakmp = draft-ietf-ipsec-isakmp-08,09,10.txt */ Oakley = draft-ietf-ipsec-oakley-02.txt */ ike = draft-ietf-ipsec-isakmp-oakley-04,05,06,07,08.txt */ revised-enc = draft-ietf-ipsec-revised-enc-mode-00,01.txt */ isakmp-cfg = draft-ietf-ipsec-isakmp-mode-cfg-00,01,02,03,04.txt */ isakmp-xauth = draft-ietf-ipsec-isakmp-xauth-02.txt */ ○ ○ ？ use-32bit-cpi Compatibility flag for implementations that use 32-bit CPI values in IPCOMP. no-well-known-cpis Allocate CPIs that have no well known values. no-initial-contact IKE再送信タイマーの設定可能 PKIパラメータ確認シート 製品名： VPN-1 製造メーカ： Checkpoint Software Technologies Ltd Version： v5.0（NG） 1．証明書取得等について 分類 証明書をCAに申請する方法 Check ○ ○ 証明書を申請するときに機器側で入力する情報 ○ ○ ○ 証明書に必要な情報または制限 ○ ☆ 複数証明書のサポート 証明書（鍵）はポリシーごと（相手先ごと）に登録可能か ☆ ネゴシエーション時の証明書ユーザの確認 ○ ○ ○ ○ ○ 項目 備考 Entrust Ready SCEP CMP v1 CMP v2 PKCS#10を作成してオフラインでCAに送信 その他 不明 Country (例: JP） StateOrProvince (Tokyo) Locarity (Shinjuku) Organization (JNSA) OrganizationalUnit (Tech) CommonName (router1.jnsa.org) SubjectAltName Extension その他 不明 CommonNameは正しいIPアドレスでなければならない。 CRL Distributibution Points Extension は必須 その他 なし 不明 複数のCA局から発行される証明書をインストールする事は可能か 通信相手によって、証明書を使い分ける事は可能か 可能 不可能 その他 不明 DN IPアドレス IDペイロード その他 2.RSA, DSA鍵について 分類 Check 使用可能なRSA鍵の長さは ○ DSA鍵 鍵のバックアップ・リカバリ方法 ○ サポートしているハードウェアトークン ○ 項目 備考 512-bit 758-bit 1024-bit 2048-bit 4096-bit その他 不明 DSA鍵をサポートするか PKCS#12形式で入出力可能 スマートカード等にバックアップ可能 その他 なし 不明 あればその機種名または一般名（USBトークン）を記入 なし 不明 3.CA登録について 分類 Check 複数のルートCA（自己署名CA）を登録可能か ○ 中間CA（自己署名以外のCA)を登録可能か ○ CAはポリシーごと（相手先ごと）に登録可能か ○ 項目 備考 できる できない 不明 できる できない 不明 できる できない 不明 4.証明書有効性確認について 分類 Check 有効期限が切れた（間近になった）時の機器の動作 ○ ○ CRLのサポート ○ ○ CRLをサポートするときのCRL取得プロトコル ○ ○ CRL以外の有効性検証方法 ○ ☆ CRLチェックのタイミング CRLチェックのスキップ ARLのサポート ○ ○ ○ ○ 項目 証明書の再取得を自動的に行う。 証明書の再取得を促す。 何もしない。 不明 必ずCRLを必要とする。 証明書にCRL Distribution Points Extension があれば使用する。 ポリシーごとに設定可能。 CRLは使用しない。 その他 不明 HTTP 1.0 HTTP 1.1 LDAP 2.0 LDAP 3.0 その他 CRLはサポートしない。 不明 OCSP その他 なし 不明 ネゴシエーション時 その他 自分の証明書 Peerの証明書 ARLをサポートするか。 備考 Entrust使用時のみ LOGに証明書の再取得を促すメッセージを表示 PKIパラメータ確認シート 製品名： NOKIA IP Security Series 製造メーカ： NOKIA Version： v5.0（NG） 1．証明書取得等について 分類 証明書をCAに申請する方法 Check ○ ○ 証明書を申請するときに機器側で入力する情報 ○ ○ ○ 証明書に必要な情報または制限 ○ ☆ 複数証明書のサポート 証明書（鍵）はポリシーごと（相手先ごと）に登録可能か ☆ ネゴシエーション時の証明書ユーザの確認 ○ ○ ○ ○ ○ 項目 備考 Entrust Ready SCEP CMP v1 CMP v2 PKCS#10を作成してオフラインでCAに送信 その他 不明 Country (例: JP） StateOrProvince (Tokyo) Locarity (Shinjuku) Organization (JNSA) OrganizationalUnit (Tech) CommonName (router1.jnsa.org) SubjectAltName Extension その他 不明 CommonNameは正しいIPアドレスでなければならない。 CRL Distributibution Points Extension は必須 その他 なし 不明 複数のCA局から発行される証明書をインストールする事は可能か 通信相手によって、証明書を使い分ける事は可能か 可能 不可能 その他 不明 DN IPアドレス IDペイロード その他 2.RSA, DSA鍵について 分類 Check 使用可能なRSA鍵の長さは ○ DSA鍵 鍵のバックアップ・リカバリ方法 ○ サポートしているハードウェアトークン ○ 項目 備考 512-bit 758-bit 1024-bit 2048-bit 4096-bit その他 不明 DSA鍵をサポートするか PKCS#12形式で入出力可能 スマートカード等にバックアップ可能 その他 なし 不明 あればその機種名または一般名（USBトークン）を記入 なし 不明 3.CA登録について 分類 Check 複数のルートCA（自己署名CA）を登録可能か ○ 中間CA（自己署名以外のCA)を登録可能か ○ CAはポリシーごと（相手先ごと）に登録可能か ○ 項目 備考 できる できない 不明 できる できない 不明 できる できない 不明 4.証明書有効性確認について 分類 Check 有効期限が切れた（間近になった）時の機器の動作 ○ ○ CRLのサポート ○ ○ CRLをサポートするときのCRL取得プロトコル ○ ○ CRL以外の有効性検証方法 ○ ☆ CRLチェックのタイミング CRLチェックのスキップ ARLのサポート ○ ○ ○ ○ 項目 証明書の再取得を自動的に行う。 証明書の再取得を促す。 何もしない。 不明 必ずCRLを必要とする。 証明書にCRL Distribution Points Extension があれば使用する。 ポリシーごとに設定可能。 CRLは使用しない。 その他 不明 HTTP 1.0 HTTP 1.1 LDAP 2.0 LDAP 3.0 その他 CRLはサポートしない。 不明 OCSP その他 なし 不明 ネゴシエーション時 その他 自分の証明書 Peerの証明書 ARLをサポートするか。 備考 Entrust使用時のみ LOGに証明書の再取得を促すメッセージを表示 PKIパラメータ確認シート 製品名： RapidStream/Checkpoint Series 製造メーカ： RapidStream Inc Version： v5.0（NG） 1．証明書取得等について 分類 証明書をCAに申請する方法 Check ○ ○ 証明書を申請するときに機器側で入力する情報 ○ ○ ○ 証明書に必要な情報または制限 ○ ☆ 複数証明書のサポート 証明書（鍵）はポリシーごと（相手先ごと）に登録可能か ☆ ネゴシエーション時の証明書ユーザの確認 ○ ○ ○ ○ ○ 項目 備考 Entrust Ready SCEP CMP v1 CMP v2 PKCS#10を作成してオフラインでCAに送信 その他 不明 Country (例: JP） StateOrProvince (Tokyo) Locarity (Shinjuku) Organization (JNSA) OrganizationalUnit (Tech) CommonName (router1.jnsa.org) SubjectAltName Extension その他 不明 CommonNameは正しいIPアドレスでなければならない。 CRL Distributibution Points Extension は必須 その他 なし 不明 複数のCA局から発行される証明書をインストールする事は可能か 通信相手によって、証明書を使い分ける事は可能か 可能 不可能 その他 不明 DN IPアドレス IDペイロード その他 2.RSA, DSA鍵について 分類 Check 使用可能なRSA鍵の長さは ○ DSA鍵 鍵のバックアップ・リカバリ方法 ○ サポートしているハードウェアトークン ○ 項目 備考 512-bit 758-bit 1024-bit 2048-bit 4096-bit その他 不明 DSA鍵をサポートするか PKCS#12形式で入出力可能 スマートカード等にバックアップ可能 その他 なし 不明 あればその機種名または一般名（USBトークン）を記入 なし 不明 3.CA登録について 分類 Check 複数のルートCA（自己署名CA）を登録可能か ○ 中間CA（自己署名以外のCA)を登録可能か ○ CAはポリシーごと（相手先ごと）に登録可能か ○ 項目 備考 できる できない 不明 できる できない 不明 できる できない 不明 4.証明書有効性確認について 分類 Check 有効期限が切れた（間近になった）時の機器の動作 ○ ○ CRLのサポート ○ ○ CRLをサポートするときのCRL取得プロトコル ○ ○ CRL以外の有効性検証方法 ○ ☆ CRLチェックのタイミング CRLチェックのスキップ ARLのサポート ○ ○ ○ ○ 項目 証明書の再取得を自動的に行う。 証明書の再取得を促す。 何もしない。 不明 必ずCRLを必要とする。 証明書にCRL Distribution Points Extension があれば使用する。 ポリシーごとに設定可能。 CRLは使用しない。 その他 不明 HTTP 1.0 HTTP 1.1 LDAP 2.0 LDAP 3.0 その他 CRLはサポートしない。 不明 OCSP その他 なし 不明 ネゴシエーション時 その他 自分の証明書 Peerの証明書 ARLをサポートするか。 備考 Entrust使用時のみ LOGに証明書の再取得を促すメッセージを表示 PKIパラメータ確認シート 製品名： RapidStream Security Appliance 製造メーカ： RapidStream Inc Version： v3.02 1．証明書取得等について 分類 Check 証明書をCAに申請する方法 ○ 証明書を申請するときに機器側で入力する情報 ○ ○ ○ ○ 証明書に必要な情報または制限 ☆ 複数証明書のサポート 証明書（鍵）はポリシーごと（相手先ごと）に登録可能か ○ ○ ○ ○ ☆ ネゴシエーション時の証明書ユーザの確認 ○ 項目 備考 Entrust Ready SCEP CMP v1 CMP v2 PKCS#10を作成してオフラインでCAに送信 その他 不明 Country (例: JP） StateOrProvince (Tokyo) Locarity (Shinjuku) Organization (JNSA) OrganizationalUnit (Tech) CommonName (router1.jnsa.org) SubjectAltName Extension その他 不明 CommonNameは正しいIPアドレスでなければならない。 CRL Distributibution Points Extension は必須 その他 なし 不明 複数のCA局から発行される証明書をインストールする事は可能か 通信相手によって、証明書を使い分ける事は可能か 可能 不可能 その他 不明 DN IPアドレス IDペイロード その他 2.RSA, DSA鍵について 分類 Check 使用可能なRSA鍵の長さは ○ ○ DSA鍵 鍵のバックアップ・リカバリ方法 ○ ○ サポートしているハードウェアトークン ○ 項目 備考 512-bit 758-bit 1024-bit 2048-bit 4096-bit その他 不明 DSA鍵をサポートするか PKCS#12形式で入出力可能 スマートカード等にバックアップ可能 その他 なし 不明 あればその機種名または一般名（USBトークン）を記入 なし 不明 3.CA登録について 分類 複数のルートCA（自己署名CA）を登録可能か Check ○ 中間CA（自己署名以外のCA)を登録可能か ○ CAはポリシーごと（相手先ごと）に登録可能か ○ 項目 備考 項目 備考 できる できない 不明 できる できない 不明 できる できない 不明 4.証明書有効性確認について 分類 Check 有効期限が切れた（間近になった）時の機器の動作 ○ CRLのサポート ○ CRLをサポートするときのCRL取得プロトコル ○ ○ ○ CRL以外の有効性検証方法 ○ ☆ CRLチェックのタイミング CRLチェックのスキップ ARLのサポート ○ 証明書の再取得を自動的に行う。 証明書の再取得を促す。 何もしない。 不明 必ずCRLを必要とする。 証明書にCRL Distribution Points Extension があれば使用する。 ポリシーごとに設定可能。 CRLは使用しない。 その他 不明 HTTP 1.0 HTTP 1.1 LDAP 2.0 LDAP 3.0 その他 CRLはサポートしない。 不明 OCSP その他 なし 不明 ネゴシエーション時 その他 自分の証明書 Peerの証明書 ARLをサポートするか。 PKIパラメータ確認シート 製品名： NetScreen-10 製造メーカ：NetScreen Version： 3.0.0r3 1．証明書取得等について 分類 Check 証明書をCAに申請する方法 ○ ○ 証明書を申請するときに機器側で入力する情報 ○ ○ ○ ○ ○ ○ 証明書に必要な情報または制限 ○ ☆ 複数証明書のサポート 証明書（鍵）はポリシーごと（相手先ごと）に登録可能か ☆ ネゴシエーション時の証明書ユーザの確認 ○ ○ ○ ○ 項目 Entrust Ready SCEP CMP v1 CMP v2 PKCS#10を作成してオフラインでCAに送信 その他 不明 Country (例: JP） StateOrProvince (Tokyo) Locarity (Shinjuku) Organization (JNSA) OrganizationalUnit (Tech) CommonName (router1.jnsa.org) SubjectAltName Extension その他 不明 CommonNameは正しいIPアドレスでなければならない。 CRL Distributibution Points Extension は必須 その他 なし 不明 複数のCA局から発行される証明書をインストールする事は可能か 通信相手によって、証明書を使い分ける事は可能か 可能 不可能 その他 不明 DN IPアドレス IDペイロード その他 備考 スペック上では使用可能とあるが、今回の試験では未動作 2.RSA, DSA鍵について 分類 Check 使用可能なRSA鍵の長さは ○ ○ ○ ○ DSA鍵 鍵のバックアップ・リカバリ方法 ○ ○ サポートしているハードウェアトークン ○ 項目 備考 512-bit 758-bit 1024-bit 2048-bit 4096-bit その他 不明 DSA鍵をサポートするか PKCS#12形式で入出力可能 スマートカード等にバックアップ可能 その他 なし 不明 あればその機種名または一般名（USBトークン）を記入 なし 不明 3.CA登録について 分類 Check 複数のルートCA（自己署名CA）を登録可能か ○ 中間CA（自己署名以外のCA)を登録可能か ○ CAはポリシーごと（相手先ごと）に登録可能か ○ 項目 備考 項目 備考 できる できない 不明 できる できない 不明 できる できない 不明 4.証明書有効性確認について 分類 Check 有効期限が切れた（間近になった）時の機器の動作 ○ CRLのサポート ○ ○ CRLをサポートするときのCRL取得プロトコル ○ ○ ○ ○ CRL以外の有効性検証方法 ○ ☆ CRLチェックのタイミング CRLチェックのスキップ ARLのサポート ○ 証明書の再取得を自動的に行う。 証明書の再取得を促す。 何もしない。 不明 必ずCRLを必要とする。 証明書にCRL Distribution Points Extension があれば使用する。 ポリシーごとに設定可能。 CRLは使用しない。 その他 不明 HTTP 1.0 HTTP 1.1 LDAP 2.0 LDAP 3.0 その他 CRLはサポートしない。 不明 OCSP その他 なし 不明 ネゴシエーション時 その他 自分の証明書 Peerの証明書 ARLをサポートするか。 CDPフィールドが存在しない場合、HTTPやLDAPによるCRL 取得が出来ない スペック上では使用可能とあるが、今回の試験では未動作 PKIパラメータ確認シート 製品名： ContivityVPNSwitch 製造メーカ：Nortelnetworks Version： v03_60.45 1．証明書取得等について 分類 Check 証明書をCAに申請する方法 ○ 証明書を申請するときに機器側で入力する情報 ○ ○ ○ ○ ○ ○ 証明書に必要な情報または制限 ○ ☆ 複数証明書のサポート 証明書（鍵）はポリシーごと（相手先ごと）に登録可能か ☆ ネゴシエーション時の証明書ユーザの確認 ○ ○ ○ ○ 項目 備考 Entrust Ready SCEP CMP v1 CMP v2 PKCS#10を作成してオフラインでCAに送信 その他 不明 Country (例: JP） StateOrProvince (Tokyo) Locarity (Shinjuku) Organization (JNSA) OrganizationalUnit (Tech) CommonName (router1.jnsa.org) SubjectAltName Extension その他 不明 CommonNameは正しいIPアドレスでなければならない。 CRL Distributibution Points Extension は必須 その他 なし 不明 複数のCA局から発行される証明書をインストールする事は可能か 通信相手によって、証明書を使い分ける事は可能か 可能 不可能 その他 不明 DN IPアドレス IDペイロード その他 2.RSA, DSA鍵について 分類 使用可能なRSA鍵の長さは Check ○ ○ ○ ○ DSA鍵 鍵のバックアップ・リカバリ方法 ○ サポートしているハードウェアトークン ○ 項目 備考 512-bit 758-bit 1024-bit 2048-bit 4096-bit その他 不明 DSA鍵をサポートするか PKCS#12形式で入出力可能 スマートカード等にバックアップ可能 その他（システム全体のバックアップ) なし 不明 あればその機種名または一般名（USBトークン）を記入 SmartCard（EntrustCA必須）：RemoteClientVPNのみ なし 不明 3.CA登録について 分類 Check 複数のルートCA（自己署名CA）を登録可能か ○ 中間CA（自己署名以外のCA)を登録可能か ○ CAはポリシーごと（相手先ごと）に登録可能か ○ 項目 備考 項目 備考 できる できない 不明 できる できない 不明 できる できない 不明 4.証明書有効性確認について 分類 Check 有効期限が切れた（間近になった）時の機器の動作 ○ CRLのサポート ○ CRLをサポートするときのCRL取得プロトコル ○ CRL以外の有効性検証方法 ○ ☆ CRLチェックのタイミング CRLチェックのスキップ ARLのサポート ○ ○ 証明書の再取得を自動的に行う。 証明書の再取得を促す。 何もしない。 不明 必ずCRLを必要とする。 証明書にCRL Distribution Points Extension があれば使用する。 ポリシーごとに設定可能。 CRLは使用しない。 その他 不明 HTTP 1.0 HTTP 1.1 LDAP 2.0 LDAP 3.0 その他 CRLはサポートしない。 不明 OCSP その他 なし 不明 ネゴシエーション時 その他 自分の証明書 Peerの証明書 ARLをサポートするか。 PKIパラメータ確認シート 製品名： Cryptopia-100 製造メーカ： 三菱電機(株) Version： v2.2.2 1．証明書取得等について 分類 Check 証明書をCAに申請する方法 ○ ○ 証明書を申請するときに機器側で入力する情報 ○ ○ ○ ○ ○ 証明書に必要な情報または制限 ○ ☆ 複数証明書のサポート 証明書（鍵）はポリシーごと（相手先ごと）に登録可能か ○ ☆ ネゴシエーション時の証明書ユーザの確認 ○ ○ ○ 項目 Entrust Ready SCEP CMP v1 CMP v2 PKCS#10を作成してオフラインでCAに送信 その他 不明 Country (例: JP） StateOrProvince (Tokyo) Locarity (Shinjuku) Organization (JNSA) OrganizationalUnit (Tech) CommonName (router1.jnsa.org) SubjectAltName Extension その他 不明 CommonNameは正しいIPアドレスでなければならない。 CRL Distributibution Points Extension は必須 その他 なし 不明 複数のCA局から発行される証明書をインストールする事は可能か 通信相手によって、証明書を使い分ける事は可能か 可能 不可能 その他 不明 DN IPアドレス IDペイロード その他 備考 PKCS#12形式の認証書も設定可能 2.RSA, DSA鍵について 分類 Check 使用可能なRSA鍵の長さは ○ DSA鍵 鍵のバックアップ・リカバリ方法 ○ サポートしているハードウェアトークン ○ 項目 512-bit 758-bit 1024-bit 2048-bit 4096-bit その他 不明 DSA鍵をサポートするか PKCS#12形式で入出力可能 スマートカード等にバックアップ可能 その他（システム全体のバックアップ) なし 不明 あればその機種名または一般名（USBトークン）を記入 SmartCard（EntrustCA必須）：RemoteClientVPNのみ なし 不明 備考 PKCS#12形式の入力のみ可能。 3.CA登録について 分類 Check 複数のルートCA（自己署名CA）を登録可能か 項目 備考 項目 備考 できる できない 不明 できる できない 不明 できる できない 不明 中間CA（自己署名以外のCA)を登録可能か CAはポリシーごと（相手先ごと）に登録可能か 4.証明書有効性確認について 分類 有効期限が切れた（間近になった）時の機器の動作 CRLのサポート CRLをサポートするときのCRL取得プロトコル CRL以外の有効性検証方法 ☆ CRLチェックのタイミング CRLチェックのスキップ ARLのサポート Check 証明書の再取得を自動的に行う。 証明書の再取得を促す。 何もしない。 不明 必ずCRLを必要とする。 証明書にCRL Distribution Points Extension があれば使用する。 ポリシーごとに設定可能。 CRLは使用しない。 その他 不明 HTTP 1.0 HTTP 1.1 LDAP 2.0 LDAP 3.0 その他 CRLはサポートしない。 不明 OCSP その他 なし 不明 ネゴシエーション時 その他 自分の証明書 Peerの証明書 ARLをサポートするか。 PKIパラメータ確認シート 製品名： VPN3000 製造メーカ： シスコシステムズ Version：3.5.2 1．証明書取得等について 分類 Check 証明書をCAに申請する方法 ○ ○ 証明書を申請するときに機器側で入力する情報 ○ ○ ○ ○ ○ ○ ○ 証明書に必要な情報または制限 ☆ 複数証明書のサポート 証明書（鍵）はポリシーごと（相手先ごと）に登録可能か ○ ○ ○ ○ ☆ ネゴシエーション時の証明書ユーザの確認 項目 備考 Entrust Ready SCEP CMP v1 CMP v2 PKCS#10を作成してオフラインでCAに送信 その他 不明 Country (例: JP） StateOrProvince (Tokyo) Locarity (Shinjuku) Organization (JNSA) OrganizationalUnit (Tech) CommonName (router1.jnsa.org) SubjectAltName Extension その他 不明 CommonNameは正しいIPアドレスでなければならない。 CRL Distributibution Points Extension は必須 その他 なし 不明 複数のCA局から発行される証明書をインストールする事は可能か 通信相手によって、証明書を使い分ける事は可能か 可能 不可能 その他 不明 DN IPアドレス IDペイロード その他 2.RSA, DSA鍵について 分類 Check 使用可能なRSA鍵の長さは ○ ○ ○ DSA鍵 鍵のバックアップ・リカバリ方法 ○ サポートしているハードウェアトークン 項目 備考 512-bit 758-bit 1024-bit 2048-bit 4096-bit その他 不明 DSA鍵をサポートするか PKCS#12形式で入出力可能 スマートカード等にバックアップ可能 その他 なし 不明 あればその機種名または一般名（USBトークン）を記入 なし 不明 3.CA登録について 分類 Check 複数のルートCA（自己署名CA）を登録可能か ○ 中間CA（自己署名以外のCA)を登録可能か ○ CAはポリシーごと（相手先ごと）に登録可能か ○ 項目 備考 項目 備考 できる できない 不明 できる できない 不明 できる できない 不明 4.証明書有効性確認について 分類 Check 有効期限が切れた（間近になった）時の機器の動作 ○ CRLのサポート CRLをサポートするときのCRL取得プロトコル ○ ○ CRL以外の有効性検証方法 ○ ☆ CRLチェックのタイミング CRLチェックのスキップ ARLのサポート 証明書の再取得を自動的に行う。 証明書の再取得を促す。 何もしない。 不明 必ずCRLを必要とする。 証明書にCRL Distribution Points Extension があれば使用する。 ポリシーごとに設定可能。 CRLは使用しない。 その他 不明 HTTP 1.0 HTTP 1.1 LDAP 2.0 LDAP 3.0 その他 CRLはサポートしない。 不明 OCSP その他 なし 不明 ネゴシエーション時 その他 自分の証明書 Peerの証明書 ARLをサポートするか。 ポリシーとは無関係に登録可 ローカルファイルからのロード ネゴシエーション時に予め登録されている CRL の内容を チェック PKIパラメータ確認シート 製品名： AR720 製造メーカ：アライドテレシス Version： 2.3.2 1．証明書取得等について 分類 Check 証明書をCAに申請する方法 ○ ○ 証明書を申請するときに機器側で入力する情報 ○ ○ ○ ○ ○ ○ ○ 証明書に必要な情報または制限 ○ ☆ 複数証明書のサポート 証明書（鍵）はポリシーごと（相手先ごと）に登録可能か ☆ ネゴシエーション時の証明書ユーザの確認 ○ 不可 ○ ○ ○ ○ 項目 Entrust Ready SCEP CMP v1 CMP v2 PKCS#10を作成してオフラインでCAに送信 その他 不明 Country (例: JP） StateOrProvince (Tokyo) Locarity (Shinjuku) Organization (JNSA) OrganizationalUnit (Tech) CommonName (router1.jnsa.org) SubjectAltName Extension その他 不明 CommonNameは正しいIPアドレスでなければならない。 CRL Distributibution Points Extension は必須 その他 なし 不明 複数のCA局から発行される証明書をインストールする事は可能か 通信相手によって、証明書を使い分ける事は可能か 可能 不可能 その他 不明 DN IPアドレス IDペイロード その他 備考 鍵を使い分けることのみ可能 鍵を使い分けることのみ可能 2.RSA, DSA鍵について 分類 使用可能なRSA鍵の長さは Check ○ ○ ○ ○ DSA鍵 鍵のバックアップ・リカバリ方法 ○ サポートしているハードウェアトークン ○ 項目 備考 512-bit 758-bit 1024-bit 2048-bit 4096-bit その他 不明 DSA鍵をサポートするか PKCS#12形式で入出力可能 スマートカード等にバックアップ可能 その他 なし 不明 あればその機種名または一般名（USBトークン）を記入 なし 不明 3.CA登録について 分類 Check 複数のルートCA（自己署名CA）を登録可能か ○ 中間CA（自己署名以外のCA)を登録可能か ○ CAはポリシーごと（相手先ごと）に登録可能か ○ 項目 できる できない 不明 できる できない 不明 できる できない 不明 備考 複数登録できるが、ポリシー毎の制限は不可 4.証明書有効性確認について 分類 Check 有効期限が切れた（間近になった）時の機器の動作 ○ CRLのサポート ○ CRLをサポートするときのCRL取得プロトコル ○ ○ ○ CRL以外の有効性検証方法 ○ ☆ CRLチェックのタイミング CRLチェックのスキップ ARLのサポート ○ 不可 不可 しない 項目 証明書の再取得を自動的に行う。 証明書の再取得を促す。 何もしない。 不明 必ずCRLを必要とする。 証明書にCRL Distribution Points Extension があれば使用する。 ポリシーごとに設定可能。 CRLは使用しない。 その他 不明 HTTP 1.0 HTTP 1.1 LDAP 2.0 LDAP 3.0 その他 CRLはサポートしない。 不明 OCSP その他 なし 不明 ネゴシエーション時 その他 自分の証明書 Peerの証明書 ARLをサポートするか。 備考 ポリシーとは無関係に登録可 ローカルファイルからのロード ネゴシエーション時に予め登録されている CRL の内容を チェック PKIパラメータ確認シート 製品名： NetStructure VPN 製造メーカ： Intel Version： v7.0 1．証明書取得等について 分類 証明書をCAに申請する方法 Check ○ ○ 証明書を申請するときに機器側で入力する情報 ○ 証明書に必要な情報または制限 ○ ☆ 複数証明書のサポート 証明書（鍵）はポリシーごと（相手先ごと）に登録可能か ☆ ネゴシエーション時の証明書ユーザの確認 ○ ○ ○ ○ ○ ○ 項目 Entrust Ready SCEP CMP v1 CMP v2 PKCS#10を作成してオフラインでCAに送信 その他 不明 Country (例: JP） StateOrProvince (Tokyo) Locarity (Shinjuku) Organization (JNSA) OrganizationalUnit (Tech) CommonName (router1.jnsa.org) SubjectAltName Extension その他 不明 CommonNameは正しいIPアドレスでなければならない。 CRL Distributibution Points Extension は必須 その他 なし 不明 複数のCA局から発行される証明書をインストールする事は可能か 通信相手によって、証明書を使い分ける事は可能か 可能 不可能 その他 不明 DN IPアドレス IDペイロード その他 備考 Mailアドレス 2.RSA, DSA鍵について 分類 使用可能なRSA鍵の長さは Check ○ ○ ○ ○ DSA鍵 鍵のバックアップ・リカバリ方法 ○ サポートしているハードウェアトークン ○ 項目 備考 512-bit 758-bit 1024-bit 2048-bit 4096-bit その他 不明 DSA鍵をサポートするか PKCS#12形式で入出力可能 スマートカード等にバックアップ可能 その他 なし 不明 あればその機種名または一般名（USBトークン）を記入 なし 不明 3.CA登録について 分類 Check 複数のルートCA（自己署名CA）を登録可能か ○ 中間CA（自己署名以外のCA)を登録可能か ○ CAはポリシーごと（相手先ごと）に登録可能か ○ 項目 備考 項目 備考 できる できない 不明 できる できない 不明 できる できない 不明 4.証明書有効性確認について 分類 Check 有効期限が切れた（間近になった）時の機器の動作 ○ CRLのサポート ○ CRLをサポートするときのCRL取得プロトコル ○ ○ CRL以外の有効性検証方法 ○ ☆ CRLチェックのタイミング ○ CRLチェックのスキップ ○ ARLのサポート 証明書の再取得を自動的に行う。 証明書の再取得を促す。 何もしない。 不明 必ずCRLを必要とする。 証明書にCRL Distribution Points Extension があれば使用する。 ポリシーごとに設定可能。 CRLは使用しない。 その他 不明 HTTP 1.0 HTTP 1.1 LDAP 2.0 LDAP 3.0 その他 CRLはサポートしない。 不明 OCSP その他 なし 不明 ネゴシエーション時 その他 自分の証明書 Peerの証明書 ARLをサポートするか。 PKIパラメータ確認シート 製品名： KAME IPSecスタック 製造メーカ：KAMEプロジェクト Version： FreeBSD 4.4-RELEASE 1．証明書取得等について 分類 Check 証明書をCAに申請する方法 ○ 証明書を申請するときに機器側で入力する情報 ○ ○ ○ ○ ○ ○ ○ 証明書に必要な情報または制限 ☆ 複数証明書のサポート 証明書（鍵）はポリシーごと（相手先ごと）に登録可能か ☆ ネゴシエーション時の証明書ユーザの確認 ○ ○ ○ ○ ○ ○ 項目 備考 Entrust Ready SCEP CMP v1 CMP v2 PKCS#10を作成してオフラインでCAに送信 その他 不明 Country (例: JP） StateOrProvince (Tokyo) Locarity (Shinjuku) Organization (JNSA) OrganizationalUnit (Tech) CommonName (router1.jnsa.org) SubjectAltName Extension その他 不明 CommonNameは正しいIPアドレスでなければならない。 CRL Distributibution Points Extension は必須 その他 なし 不明 複数のCA局から発行される証明書をインストールする事は可能か 通信相手によって、証明書を使い分ける事は可能か 可能 不可能 その他 不明 DN IPアドレス IDペイロード address,user_fqdn,keyid,asn1dn:詳細はman racoon.confにあ ります その他 2.RSA, DSA鍵について 分類 Check 使用可能なRSA鍵の長さは ○ ○ ○ ○ ○ DSA鍵 鍵のバックアップ・リカバリ方法 × ○ サポートしているハードウェアトークン 項目 512-bit 758-bit 1024-bit 2048-bit 4096-bit その他 不明 DSA鍵をサポートするか PKCS#12形式で入出力可能 スマートカード等にバックアップ可能 その他 なし 不明 あればその機種名または一般名（USBトークン）を記入 なし 不明 備考 秘密鍵と証明書を別々のファイルにて保存できます。 3.CA登録について 分類 Check 複数のルートCA（自己署名CA）を登録可能か ○ 中間CA（自己署名以外のCA)を登録可能か ○ CAはポリシーごと（相手先ごと）に登録可能か ○ 項目 備考 項目 備考 できる できない 不明 できる できない 不明 できる できない 不明 4.証明書有効性確認について 分類 Check 有効期限が切れた（間近になった）時の機器の動作 ○ ○ CRLのサポート ○ CRLをサポートするときのCRL取得プロトコル CRL以外の有効性検証方法 ○ ☆ CRLチェックのタイミング CRLチェックのスキップ ARLのサポート 証明書の再取得を自動的に行う。 証明書の再取得を促す。 何もしない。 不明 必ずCRLを必要とする。 証明書にCRL Distribution Points Extension があれば使用する。 ポリシーごとに設定可能。 CRLは使用しない。 その他 不明 HTTP 1.0 HTTP 1.1 LDAP 2.0 LDAP 3.0 その他 CRLはサポートしない。 不明 OCSP その他 なし 不明 ネゴシエーション時 その他 自分の証明書 Peerの証明書 ARLをサポートするか。 PKIパラメータ確認シート 製品名： 713X Secure VPN Gateway Series 製造メーカ： Alcatel Version： V3.11.021(Offline) 1．証明書取得等について 分類 Check 証明書をCAに申請する方法 ○ 証明書を申請するときに機器側で入力する情報 ○ ○ ○ 証明書に必要な情報または制限 ○ ☆ 複数証明書のサポート 証明書（鍵）はポリシーごと（相手先ごと）に登録可能か ○ ☆ ネゴシエーション時の証明書ユーザの確認 項目 Entrust Ready SCEP CMP v1 CMP v2 PKCS#10を作成してオフラインでCAに送信 その他 不明 Country (例: JP） StateOrProvince (Tokyo) Locarity (Shinjuku) Organization (JNSA) OrganizationalUnit (Tech) CommonName (router1.jnsa.org) SubjectAltName Extension その他 不明 CommonNameは正しいIPアドレスでなければならない。 CRL Distributibution Points Extension は必須 その他 なし 不明 複数のCA局から発行される証明書をインストールする事は可能か 通信相手によって、証明書を使い分ける事は可能か 可能 不可能 その他 不明 DN IPアドレス IDペイロード その他 備考 Comonname，Organaization，Country 2.RSA, DSA鍵について 分類 Check 使用可能なRSA鍵の長さは ○ DSA鍵 鍵のバックアップ・リカバリ方法 ○ サポートしているハードウェアトークン ○ 項目 512-bit 758-bit 1024-bit 2048-bit 4096-bit その他 不明 DSA鍵をサポートするか PKCS#12形式で入出力可能 スマートカード等にバックアップ可能 その他 なし 不明 あればその機種名または一般名（USBトークン）を記入 なし 不明 備考 Hot Standbyは可 3.CA登録について 分類 Check 複数のルートCA（自己署名CA）を登録可能か ○ 中間CA（自己署名以外のCA)を登録可能か ○ CAはポリシーごと（相手先ごと）に登録可能か ○ 項目 備考 項目 備考 できる できない 不明 できる できない 不明 できる できない 不明 4.証明書有効性確認について 分類 Check 有効期限が切れた（間近になった）時の機器の動作 ○ CRLのサポート ○ CRLをサポートするときのCRL取得プロトコル ○ CRL以外の有効性検証方法 ○ ☆ CRLチェックのタイミング CRLチェックのスキップ ARLのサポート ○ 証明書の再取得を自動的に行う。 証明書の再取得を促す。 何もしない。 不明 必ずCRLを必要とする。 証明書にCRL Distribution Points Extension があれば使用する。 ポリシーごとに設定可能。 CRLは使用しない。 その他 不明 HTTP 1.0 HTTP 1.1 LDAP 2.0 LDAP 3.0 その他 CRLはサポートしない。 不明 OCSP その他 なし 不明 ネゴシエーション時 その他 自分の証明書 Peerの証明書 ARLをサポートするか。 PKIパラメータ確認シート 製品名： 713X Secure VPN Gateway Series 製造メーカ： Alcatel Version： V3.11.021(Entrust) 1．証明書取得等について 分類 証明書をCAに申請する方法 Check ○ 証明書を申請するときに機器側で入力する情報 ○ 証明書に必要な情報または制限 ○ ☆ 複数証明書のサポート 証明書（鍵）はポリシーごと（相手先ごと）に登録可能か ○ ☆ ネゴシエーション時の証明書ユーザの確認 項目 Entrust Ready SCEP CMP v1 CMP v2 PKCS#10を作成してオフラインでCAに送信 その他 不明 Country (例: JP） StateOrProvince (Tokyo) Locarity (Shinjuku) Organization (JNSA) OrganizationalUnit (Tech) CommonName (router1.jnsa.org) SubjectAltName Extension その他 不明 CommonNameは正しいIPアドレスでなければならない。 CRL Distributibution Points Extension は必須 その他 なし 不明 複数のCA局から発行される証明書をインストールする事は可能か 通信相手によって、証明書を使い分ける事は可能か 可能 不可能 その他 不明 DN IPアドレス IDペイロード その他 備考 Entrust Method 2.RSA, DSA鍵について 分類 Check 使用可能なRSA鍵の長さは ○ DSA鍵 鍵のバックアップ・リカバリ方法 ○ サポートしているハードウェアトークン ○ 項目 512-bit 758-bit 1024-bit 2048-bit 4096-bit その他 不明 DSA鍵をサポートするか PKCS#12形式で入出力可能 スマートカード等にバックアップ可能 その他 なし 不明 あればその機種名または一般名（USBトークン）を記入 なし 不明 備考 Hot Standbyは可 3.CA登録について 分類 Check 複数のルートCA（自己署名CA）を登録可能か ○ 中間CA（自己署名以外のCA)を登録可能か ○ CAはポリシーごと（相手先ごと）に登録可能か ○ 項目 備考 項目 備考 できる できない 不明 できる できない 不明 できる できない 不明 4.証明書有効性確認について 分類 Check 有効期限が切れた（間近になった）時の機器の動作 ○ CRLのサポート ○ CRLをサポートするときのCRL取得プロトコル ○ CRL以外の有効性検証方法 ○ ☆ CRLチェックのタイミング ○ CRLチェックのスキップ ARLのサポート 証明書の再取得を自動的に行う。 証明書の再取得を促す。 何もしない。 不明 必ずCRLを必要とする。 証明書にCRL Distribution Points Extension があれば使用する。 ポリシーごとに設定可能。 CRLは使用しない。 その他 不明 HTTP 1.0 HTTP 1.1 LDAP 2.0 LDAP 3.0 その他 CRLはサポートしない。 不明 OCSP その他 なし 不明 ネゴシエーション時 その他 自分の証明書 Peerの証明書 ARLをサポートするか。 PKIパラメータ確認シート 製品名： VSU100R 製造メーカ：Avaya社 Version： 3.1.58 1．証明書取得等について 分類 Check 証明書をCAに申請する方法 ○ 証明書を申請するときに機器側で入力する情報 ○ ○ ○ 証明書に必要な情報または制限 ○ ☆ 複数証明書のサポート 証明書（鍵）はポリシーごと（相手先ごと）に登録可能か ☆ ネゴシエーション時の証明書ユーザの確認 ○ ○ ○ ○ ○ 項目 Entrust Ready SCEP CMP v1 CMP v2 PKCS#10を作成してオフラインでCAに送信 その他 不明 Country (例: JP） StateOrProvince (Tokyo) Locarity (Shinjuku) Organization (JNSA) OrganizationalUnit (Tech) CommonName (router1.jnsa.org) SubjectAltName Extension その他 不明 CommonNameは正しいIPアドレスでなければならない。 CRL Distributibution Points Extension は必須 その他 なし 不明 複数のCA局から発行される証明書をインストールする事は可能か 通信相手によって、証明書を使い分ける事は可能か 可能 不可能 その他 不明 DN IPアドレス IDペイロード その他 備考 大文字であることが必須である。空欄はNG。 2.RSA, DSA鍵について 分類 Check 使用可能なRSA鍵の長さは ○ DSA鍵 鍵のバックアップ・リカバリ方法 ○ ○ サポートしているハードウェアトークン 項目 備考 512-bit 758-bit 1024-bit 2048-bit 4096-bit その他 不明 DSA鍵をサポートするか PKCS#12形式で入出力可能 スマートカード等にバックアップ可能 その他 なし 不明 あればその機種名または一般名（USBトークン）を記入 なし 不明 3.CA登録について 分類 Check 複数のルートCA（自己署名CA）を登録可能か ○ 中間CA（自己署名以外のCA)を登録可能か ○ CAはポリシーごと（相手先ごと）に登録可能か ○ 項目 備考 項目 備考 できる できない 不明 できる できない 不明 できる できない 不明 4.証明書有効性確認について 分類 Check 有効期限が切れた（間近になった）時の機器の動作 ○ CRLのサポート ○ CRLをサポートするときのCRL取得プロトコル ○ CRL以外の有効性検証方法 ○ ☆ CRLチェックのタイミング ○ CRLチェックのスキップ ARLのサポート 証明書の再取得を自動的に行う。 証明書の再取得を促す。 何もしない。 不明 必ずCRLを必要とする。 証明書にCRL Distribution Points Extension があれば使用する。 ポリシーごとに設定可能。 CRLは使用しない。 その他 不明 HTTP 1.0 HTTP 1.1 LDAP 2.0 LDAP 3.0 その他 CRLはサポートしない。 不明 OCSP その他 なし 不明 ネゴシエーション時 その他 自分の証明書 Peerの証明書 ARLをサポートするか。 CRL情報をLDIF形式で出力し、それをManagerで使用してい るLDAPに格納する。 PKIパラメータ確認シート 製品名： IPsec Express ToolKit 製造メーカ： SSH Communications Secutiry Version： v4．1．1 1．証明書取得等について 分類 Check 証明書をCAに申請する方法 ○ ○ ○ 証明書を申請するときに機器側で入力する情報 ○ ○ ○ ○ 証明書に必要な情報または制限 ☆ 複数証明書のサポート 証明書（鍵）はポリシーごと（相手先ごと）に登録可能か ☆ ネゴシエーション時の証明書ユーザの確認 ○ ○ ○ ○ ○ 項目 備考 Entrust Ready SCEP CMP v1 CMP v2 PKCS#10を作成してオフラインでCAに送信 その他 不明 Country (例: JP） StateOrProvince (Tokyo) Locarity (Shinjuku) Organization (JNSA) OrganizationalUnit (Tech) CommonName (router1.jnsa.org) SubjectAltName Extension その他 不明 CommonNameは正しいIPアドレスでなければならない。 CRL Distributibution Points Extension は必須 その他 なし 不明 複数のCA局から発行される証明書をインストールする事は可能か 通信相手によって、証明書を使い分ける事は可能か 可能 不可能 その他 不明 DN IPアドレス IDペイロード その他 2.RSA, DSA鍵について 分類 Check 使用可能なRSA鍵の長さは ○ ○ ○ ○ ○ DSA鍵 鍵のバックアップ・リカバリ方法 ○ ○ ○ サポートしているハードウェアトークン ○ 項目 512-bit 758-bit 1024-bit 2048-bit 4096-bit その他 不明 DSA鍵をサポートするか PKCS#12形式で入出力可能 スマートカード等にバックアップ可能 その他 なし 不明 あればその機種名または一般名（USBトークン）を記入 なし 不明 備考 オプション オプション（PKCS#11，Schlumberger，Setec，etc） 3.CA登録について 分類 Check 複数のルートCA（自己署名CA）を登録可能か ○ 中間CA（自己署名以外のCA)を登録可能か ○ CAはポリシーごと（相手先ごと）に登録可能か ○ 項目 備考 項目 備考 できる できない 不明 できる できない 不明 できる できない 不明 4.証明書有効性確認について 分類 Check 有効期限が切れた（間近になった）時の機器の動作 ○ CRLのサポート ○ ○ CRLをサポートするときのCRL取得プロトコル ○ ○ ○ CRL以外の有効性検証方法 ○ ☆ CRLチェックのタイミング ○ CRLチェックのスキップ ARLのサポート ○ 証明書の再取得を自動的に行う。 証明書の再取得を促す。 何もしない。 不明 必ずCRLを必要とする。 証明書にCRL Distribution Points Extension があれば使用する。 ポリシーごとに設定可能。 CRLは使用しない。 その他 不明 HTTP 1.0 HTTP 1.1 LDAP 2.0 LDAP 3.0 その他 CRLはサポートしない。 不明 OCSP その他 なし 不明 ネゴシエーション時 その他 自分の証明書 Peerの証明書 ARLをサポートするか。 CAごとに設定可能 FAX 送付先 IPA セキュリティセンター FAX 番号 03-5978-7518 要件 PKI 関連相互運用性に関する調査（IPsec 編） （支障のない範囲でご回答下さい） 1. ご勤務先についてお伺いします。 (1-1) 業種 □ソフトウェア企業 □情報サービス業 □コンピュータ及び周辺機器製造又は販売業 □農業，林業，漁業，鉱業 □建設業 □運輸・通信業 □卸売・小売業，飲食店 □金融・保険業，不動産業 □サービス業 □調査業，広告業 □医療業 □教育（学校，研究機関） □官公庁，公益団体 □学生 □無職 □その他（ □製造業 □電気・ガス・熱供給・水道業 ） (1-2) 従事している業務 □システム企画・計画 □プロジェクト管理 □システム設計 □プログラム開発 □ネットワーク技術支援 □データベース技術支援 □システム管理・運用 □エンベデットシステム開発 □システム監査 □情報技術教育 □その他情報処理関係業務 □研究・開発 □調査・企画 □総務・人事 □営業・販売 □教育・研修 □その他（ □製造 (1-3) 情報処理業務の経験年数 □経験なし □1 年未満 □5 年以上 10 年未満 □1 年以上 3 年未満 □10 年以上 15 年未満 □3 年以上 5 年未満 □15 年以上 2. 本資料の感想についてお伺いします。 (2-1) 本資料は役に立ちましたか。 □役に立った □普通 □役に立たなかった (2-2) 本資料は分かりやすかったですか。 □わかりやすい □普通 □わかりにくい (2-3) 本資料の内容を定期的に更新し掲載することを希望されますか。 □望む □望まない □どちらともいえない ） (2-4) 本資料のどの部分が特に役に立ちましたか。(複数記述可) □全て □第( ， ， ， ， )章 □特に無し (2-5) 本資料をどうやって知りましたか。 □サーチエンジン □他ページからのリンク □新聞・雑誌 □書籍 □その他報道 □知人からの紹介 □IPA ホームページ □偶然 □その他 ( ) (2-6) 本資料に対するご意見・ご感想等がございましたらご記入ください。 (2-7) IPA（資料の発行団体）に対するご意見・ご要望等がございましたらご記入ください。 ご協力ありがとうございました。