EAP-TLS クライアントプロトコル

FCS_TLSC_EXT.1 拡張：EAP TLSプロトコル

FCS_TLSC_EXT.1.1 TSFは、TLS 1.0及び [選択：TLS 1.1 (RFC 4346)、TLS 1.2 (RFC 5246)、 その他の TLS バージョンなし] を、以下の暗号スイートをサポートしするよう、実装しな ければならない (shall)： [

 必須の暗号スイート：

○ RFC 5246に定義されるTLS_RSA_WITH_AES_128_CBC_SHA

 [選択：オプションの暗号スイート：

○ RFC 5246に定義されるTLS_RSA_WITH_AES_256_CBC_SHA

○ RFC 5246に定義されるTLS_DHE_RSA_WITH_AES_128_CBC_SHA

○ RFC 5246に定義されるTLS_DHE_RSA_WITH_AES_256_CBC_SHA

○ RFC 4492に定義されるTLS_ECDHE_RSA_WITH_AES_128_CBC_SHA

○ RFC 4492に定義されるTLS_ECDHE_RSA_WITH_AES_256_CBC_SHA

○ RFC 4492に定義されるTLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA

○ RFC 4492に定義されるTLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA

○ RFC 5246に定義されるTLS_RSA_WITH_AES_128_CBC_SHA256

○ RFC 5246に定義されるTLS_RSA_WITH_AES_256_CBC_SHA256

○ RFC 5246に定義されるTLS_DHE_RSA_WITH_AES_128_CBC_SHA256

○ RFC 5246に定義されるTLS_DHE_RSA_WITH_AES_256_CBC_SHA256

○ RFC 5289に定義されるTLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256

○ RFC 5289に定義されるTLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384

○ RFC 5289に定義されるTLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256

○ RFC 5289に定義されるTLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384

○ その他の暗号スイートなし]]。

適用上の注釈：評価される構成においてテストされるべき暗号スイートは、本要件により 制限される。ST作成者は、サポートされるオプションの暗号スイートを選択すべきである

(should)。もし必須スイート以外にサポートされる暗号スイートが存在しない場合には、「な

し」が選択されるべきである (should)。テスト環境中のサーバ上で評価される構成におい て管理的に使用可能な暗号スイートを制限することは必要である。上記のSuite Bアルゴリ

ズ ム (RFC 6460) は 、 実 装 上 望 ま し い ア ル ゴ リ ズ ム で あ る 。

TLS_RSA_WITH_AES_128_CBC_SHAは、RFC 5246への準拠を保証するため要求されて

いる。

もし楕円曲線暗号スイートが選択される場合、FCS_TLSC_EXT.1.5 がST に含まれなけれ ばならない (shall)。

TLS 1.2は望ましいプロトコルである。しかし、TLS 1.0は現在RFC 5216への適合を保証

するため必要とされている。TLS 1.0及びTLS 1.1は、TLS 1.2のサポートの欠如のため現 在のところ許容されている。TLS 1.0及びTLS 1.1は、112ビット以上のセキュリティ強度 を持つ接続を保証するために必要な拡張を有していない。

TLS 1.2は、2015年の第3四半期以降に評価に入る製品についてEAP-TLSが必須となる。

これらの要件は、IETFにより新しいTLSのバージョンが規格化された際に再検討されるこ とになる。

保証アクティビティ：

評価者は、サポートされる暗号スイートが特定されていることを保証するため、TSS 中の 本プロトコル実装の記述をチェックしなければならない (shall)。評価者は、特定された暗 号スイートが本コンポーネントに列挙されたものを含むことを保証するため、TSS をチェ ックしなければならない (shall)。評価者は、TLSがTSSの記述と適合するようにTOEの 設定に関する指示が操作ガイダンスに含まれることを保証するため、操作ガイダンスにつ いてもチェックしなければならない (shall)。

評価者は、以下のテストについても実施しなければならない (shall)：

テスト1：評価者は、要件に規定された暗号スイートのそれぞれを用いて、TLS接続を確立 しなければならない (shall)。この接続は、より高位のプロトコルの確立の一部、例えば、

EAP セションの一部として確立されてもよい。テストの意図を満たすには、暗号スイート のネゴシエーション成功を確認すれば十分であり、使用されている暗号スイート (例えば、

暗号アルゴリズムが128ビットAESであって256ビットAESではないこと) を見極めよ うとして暗号化されたトラフィックの特徴を検査する必要はない。

テスト2：評価者は、extendedKeyUsageフィールド中にサーバ認証目的を含むサーバ証明 書を持ったサーバを用いて接続を確立する試行を行い、接続が確立されることを検証しな ければならない (shall)。次に評価者は、extendedKeyUsage フィールド中にサーバ認証目 的を含まないこと以外は有効なサーバ証明書をクライアントが拒否し、接続が確立されな いことを検証する。理想的には、2 つの証明書は extendedKeyUsage フィールドを除いて

同一であるべきである (should)。

テスト3：評価者は、サーバによって選択された暗号スイートと一致しないサーバ証明書

(例えば、TLS_RSA_WITH_AES_128_CBC_SHA暗号スイートを利用しているのにECDSA

証明書を送信、またはECDSA暗号スイートのひとつを使用しているのにRSA証明書を送 信) をTLS接続中に送信しなければならない (shall)。評価者は、サーバの証明書ハンドシ ェイクメッセージを受信した後にTOE が切断することを検証しなければならない (shall) 。 テスト4：評価者は、TLS_NULL_WITH_NULL_NULL 暗号スイートを選択するようサーバ を設定し、クライアントが接続を拒否することを検証しなければならない (shall)。

テスト5：評価者は、トラフィックに以下の改変を行わなければならない (shall)：

 Server Hello中のサーバにより選択されたTLSバージョンを非サポートのTLSバ

ージョン (例えば03 04の2バイトによって表現される1.3) に改変し、クライア

ントが接続を拒否することを検証する。

 Server Helloハンドシェイクメッセージ中のサーバのノンスの少なくとも1バイト

を改変して、クライアントがServer Key Exchangeハンドシェイクメッセージを 拒否すること (DHE または ECDHE 暗号スイートの場合) またはクライアントの

Finishedハンドシェイクメッセージをサーバが拒否することを検証する。

 Server Helloハンドシェイクメッセージ中のサーバの選択された暗号スイートを、

Client Helloハンドシェイクメッセージ中に存在しない暗号スイートに改変する。

評価者は、Server Helloを受信した後にクライアントが接続を拒否することを検証 しなければならない (shall) 。

 サーバの Key Exchangeハンドシェイクメッセージ中の署名ブロックを改変して、

Server Key Exchange メッセージの受信後にクライアントが接続を拒否すること

を検証する。

 Server Finishedハンドシェイクメッセージの1バイトを改変して、受信するとク

ライアントがfatal alertを送信し、アプリケーションデータを一切送信しないこと を検証する。

 サーバが ChangeCipherSpec メッセージを発行した後にサーバから歪曲されたメ

ッセージを送信し、クライアントが接続を拒否することを検証する。

FCS_TLS_EXT.1.2 TSFは、EAP-TLSに提示されたサーバ証明書が [選択：特定のCAのひ とつへチェーンする、受容可能な認証サーバ証明書の特定の FQDN を含む] ことを検証し なければならない (shall)。

適用上の注釈：CAまたはFQDNは、FMT_SMF_EXT.1の機能7.aに従って特定される。

保証アクティビティ：

評価者は、証明書への署名が許可される認証局のリストを設定するため、またはEAP-TLS 交換においてTOEが受け入れる認証サーバ証明書のFQDNを設定するための、管理者への 指示がAGDガイダンスに含まれていることをチェックしなければならない (shall)。

RFC 5246への適合性をテストするため、将来さらにテストが追加されるかもしれない。評

価者は、以下のテストについても実行しなければならない (shall)。

テスト1：AGDガイダンスにより提供されるガイダンスにしたがい、CAまたはFQDNが 認証サーバ証明書として「受け入れ可能」と設定され、次に評価者は無線接続を開始し、

無線クライアントが接続に成功することを検証すること。次に評価者は、証明書がTOEに より許可されていないCAにより署名されるか、またはTOEにより許可されてないFQDN を証明書が提示する、それ以外は有効であるようにシステムを設定する。このような証明 書を提示する認証サーバへの認証の試行は、接続において拒否される結果となるべきであ る (should)。TOEが受け入れ可能な認証サーバを制限する両方の方法をサポートする場合、

評価者はこのテストを2回、各方法について1回ずつ、繰り返さなければならない (shall)。

FCS_TLSC_EXT.1.3 TSFは、ピア証明書が無効である場合、高信頼チャネルを確立しては ならない (shall not)。

適用上の注釈：有効性は識別子の検証、証明書パス、有効期限、及びRFC 5280 にしたが う失効状態により決定される。証明書の有効性は FIA_X509_EXT.1 のために行われるテス トに従ってテストされなければならない (shall)。

TLS 接続に関しては、ピア証明書が無効である場合、本チャネルは確立されてはならない (shall not)。TLS上にHTTPSが実装されるが、HTTPSプロトコル (FCS_HTTPS_EXT.1) は、異なるふるまいを要求する。本エレメントは、非HTTPSのTLS接続に対処する。

保証アクティビティ：

評価者は、以下のテストを実行しなければならない (shall)：

テスト1：評価者は、有効な認証パスを持たない証明書の使用が、機能しない結果をもたら うことを実証しなければならない (shall)。管理ガイダンスを用いて、評価者は、次にその 機能で使われる証明書の有効性確認に必要とされるトラストアンカーデータベースへ 1 つ または複数の証明書をロードし、その機能がうまく動作することを実証しなければならな い (shall)。次に評価者は、これらの証明書の 1つを削除して、うまく機能しないことを示 さなければならない (shall)。

FCS_TLSC_EXT.1.4 TSFは、X.509v3証明書を用いる相互認証をサポートしなければなら ない (shall)。

適用上の注釈：TLSでのX.509v3証明書の使用は、FIA_X509_EXT.2.1で対処されている。

本要件は、クライアントがTLS相互認証用にTLSサーバへ証明書を提示可能でなければな らない (must) ことをこの使用に含まれなければならない (must) ことを追加する。

保証アクティビティ：

評価者は、FIA_X509_EXT.2.1で要求されるTSS記述に、TLS相互認証用のクライアント 証明書の使用が含まれていることを保証しなければならない (shall)。

評価者は、FIA_X509_EXT.2.1で要求されるAGDガイダンスに、TLS相互認証用のクライ アント証明書を設定するための指示が含まれていることを検証しなければならない (shall)。 評価者は、以下のテストについても実行しなければならない (shall)：

テスト1：評価者は、トラフィックに対して以下の改変を行わなければならない (shall)：

 相互認証を要求するようにサーバを設定し、次にサーバのCertificateRequestハン ドシェイクメッセージの CA フィールドにある 1 バイトを改変する。改変された CAフィールドは、クライアント証明書に署名するために使用されたCAであって はならない (must not)。評価者は、接続が成功しないことを検証しなければなら ない (shall)。