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

無線クライアントが接続に成功することを検証すること。次に評価者は、証明書が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)。

FCS_TLSC_EXT.2.1 TSFは、TLS 1.2 (RFC 5246) を実装し、下記の暗号スイートをサポ ートしなければならない (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_SHA 256

○ 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.2.5 がST に含まれなければな らない (shall)。

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

TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384は、2015年の第3四半期以降に評

価に入る製品について必須となるだろう。

保証アクティビティ：

評価者はて、サポートされた暗号スイートが指定されていることを保証するため、TSS に おける本プロトコル実装の記述をチェックししなければならない (shall)。評価者は指定さ

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

評価者は、TLSのテストを目的とするアプリケーションを書くか、またはST作成者が提供 するかしなければならない (shall)。評価者は、以下のテストについても実行しなければな らない (shall)：

テスト1：評価者は、要件で特定された暗号スイートのそれぞれを用いて、TLS接続を確立 しなければならない (shall)。本接続は、上位プロトコルの確立の一部として、例えばEAP セションの一部として、確立されてもよい。テストの意図を満たすために暗号スイートの ネゴシエーション成功を確認すれば十分であり；利用されている暗号スイート (例えば、暗 号アルゴリズムが128ビットAESであり、256ビットAESではないこと) を判別するため に暗号化されたトラフィックの特徴を検査する必要はない。

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

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

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

 ServerHello においてサーバにより選択された TLS バージョンを、非サポートの

TLSバージョン (例えば03 04の2バイトによって表現される1.3) に改変し、ク ライアントが接続を拒否することを検証する。

 ServerHelloハンドシェイクメッセージにおけるサーバのノンスの少なくとも1バ

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

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

 ServerHelloハンドシェイクメッセージにおけるのサーバの選択された暗号スイー

トを、ClientHello ハンドシェイクメッセージに存在しない暗号スイートに改変す る。評価者は、ServerHello受信後に、クライアントが接続を拒否することを検証 しなければならない (shall) 。

 (条件付き) ECDHEまたはDHE暗号スイートがサポートされた場合、サーバのKey

Exchange ハ ン ド シ ェ イ ク メ ッ セ ー ジ に お け る 署 名 ブ ロ ッ ク を 改 変 し て 、

ServerKeyExchange受信後に、クライアントが接続を拒否することを検証する。

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

イアントがfatal alertを送信しアプリケーションデータを全く送信しないことを検

証する。

 サーバが ChangeCipherSpec メッセージを発行した後、サーバから文字化けした

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

FCS_TLSC_EXT.2.2 TSFは、提示された識別子がRFC 6125に従って参照識別子と一致す ることを検証しなければならない (shall)。

適用上の注釈：識別子の検証のルールは、RFC 6125のセクション6に記述されている。参 照識別子はアプリケーションサービスに応じて、利用者(例えば、ウェブブラウザへのURL 入力またはリンクのクリック) により、設定(例えば、メールサーバまたは認証サーバの名 前の設定) により、またはアプリケーション(例えば、API のパラメタ) により確立される。

単一の参照識別子の生成元ドメイン及びアプリケーションサービス種別 (例えば、HTTP、

SIP、LDAP) に基づき、クライアントは受け入れ可能なすべての参照識別子、例えば証明

書のサブジェクト名 (Subject Name) フィールドのコモン名 (Common Name) 及びサブ ジェクトの別名 (Subject Alternative Name) フィールドの (大文字と小文字を区別しない) DNS名、URI名、及びサービス名 (Service Name) 等を確立する。クライアントは、次に すべての受け入れ可能な参照識別子の本リストを、TLS サーバの証明書における提示され た識別子と比較する。

推奨される検証方法は、DNS 名、URI名、またはサービス名を用いたサブジェクトの別名

(Subject Alternative Name) である。コモン名を用いた検証は、バックワード互換性の目的

で要求される。さらに、サブジェクト名またはサブジェクトの別名(Subject Alternative

Name) 中のIPアドレス使用のサポートは、ベストプラクティスに反するため推奨されない

が、実装されてもよい。最後に、クライアントは、ワイルドカードを用いた参照識別子の 構築を避けるべきである (should)。しかし、提示された識別子がワイルドカードを含む場 合、クライアントは、マッチングに関するベストプラクティスに従わなければならない (must)。これらのベストプラクティスは、保証アクティビティに取り込まれている。

保証アクティビティ：

評価者は、どの種類の参照識別子がサポートされているか (例えばコモン名、DNS名、URI 名、サービス名、またはその他のアプリケーション特有のサブジェクトの別名(Subject

Alternative Name) ) ならびにIPアドレス及びワイルドカードがサポートされているかどう

かを含め、アプリケーションに設定された参照識別子からすべての参照識別子を確立する クライアントの方法がTSSに記述されていることを保証しなければならない (shall)。評価 者はこの記述に、TOEによってCertificate Pinningがサポートされるか、または利用される かどうか、及びその方法が特定されていることを保証しなければならない (shall)。

評価者は、TLS における証明書有効性確認の目的に使用される参照識別子を設定するため の指示が AGD ガイダンスに含まれていることを検証しなければならない (shall)。特に、

AGDガイダンスには参照識別子を設定するためアプリケーションによって利用されるAPI が記述されるべきである (should)。

評価者は、AGDガイダンスに従って参照識別子を設定し、TLS接続中に以下のテストを実 行しなければならない (shall)：

テスト1：評価者は、参照識別子と一致する識別子をサブジェクトの別名(Subject Alternative

Name) (SAN) にもコモン名 (CN) にも含まないサーバ証明書を提示しなければならない

(shall)。評価者は、接続が失敗することを検証しなければならない (shall)。

テスト2：評価者は、参照識別子と一致する CNを含み、SAN 拡張を含むが、参照識別子 と一致する識別子をSANに含まないサーバ証明書を提示しなければならない (shall)。評価