NIAP: View Technical Decision Details
NIAP/CCEVS
  NIAP  »»  Protection Profiles  »»  Technical Decisions  »»  View Details  
Archived TD0431:  Modification to Cipher Suites for TLS

Publication Date
2019.07.30

Protection Profiles
PP_BASE_VIRTUALIZATION_V1.0

Other References
FAU_GEN.1, FCS_IPSEC_EXT.1.15, FCS_TLSC_EXT.1, FCS_TLSC_EXT.2, FCS_TLSS_EXT.1, FCS_TLSS_EXT.2

Issue Description

Support for TLS_RSA_WITH_AES_128_CBC_SHA is no longer mandated and additional cipher suites are allowed.

Resolution

Updated 09/05/2019: This TD also supersedes TD 156.

This TD supersedes TDs 166, 213, 252, 265, and 403. In addition, TDs 244 and 267 will be updated since the changes related to this PP are also incorporated in this TD.

For FAU_GEN.1:  The Application Note for FAU_GEN.1: Audit Data Generation is modified as follows:

Application Note: The ST author can include other auditable events directly in Table 1; they are not limited to the list presented. The ST author should update the table in FAU_GEN.1.2 with any additional information generated. “Subject identity” in FAU_GEN.1.2 could be a user id or an identifier specifying a VM, for example.

If ‘additional information defined in Table 3’ is selected, it is acceptable to include individual entries from Table 3 without including the entirety of Table 3.  Appropriate entries from Tables 2, 4, and 5 should be included in the ST if the associated SFRs and selections are included.

The Table 1 entry for FDP_VNC_EXT.1 refers to configuration settings that attach VMs to virtualized network components. Changes to these configurations can be made during VM execution or when VMs are not running. Audit records must be generated for either case.

The intent of the audit requirement for FDP_PPR_EXT.1 is to log that the VM is connected to a physical device (when the device becomes part of the VM’s hardware view), not to log every time that the device is accessed. Generally, this is only once at VM startup. However, some devices can be connected and disconnected during operation (e.g., virtual USB devices such as CD-ROMs). All such connection/disconnection events must be logged.

Table 1: Auditable Events is modified as follows:

FMT_SMR.2 row is removed.

The text in Annex B immediately preceding Table 3 is replaced with:

The following additional auditable events may be claimed by the ST author if “additional information defined in Table 3” is selected in FAU_GEN.1.  Any subset of Table 3, including individual entries, may be included in the ST; it is not necessary to include the entirety of Table 3.

Table 3 in Annex B is replaced with:

 

Requirement

Auditable Events

Additional Audit Record Contents

FCS_HTTPS_EXT.1

Failure to establish a HTTPS Session. Establishment/Termination of a HTTPS session.

 

Reason for failure. Non-TOE endpoint of connection (IP address) for both successes and failures.

 

FCS_TLSC_EXT.1

Failure to establish a TLS Session. Establishment/Termination of a TLS session.

 

Reason for failure. Non-TOE endpoint of connection (IP address).

 

FCS_TLSC_EXT.2

Failure to establish a TLS Session.
Establishment/Termination of a TLS session.

Reason for failure.
Non-TOE endpoint of connection (IP address).

FCS_TLSS_EXT.1

Failure to establish a TLS Session.
Establishment/Termination of a TLS session.

Reason for failure.
Non-TOE endpoint of connection (IP address).

FCS_TLSS_EXT.2

Failure to establish a TLS Session. Establishment/Termination of a TLS session.

 

Reason for failure. Non-TOE endpoint of connection (IP address).

 

FIA_UIA_EXT.1

Administrator session start time and end time

None.

For FCS_IPSEC_EXT.1.15 - the 3rd paragraph in app note is changed to the following:

The configuration of the peer reference identifier is addressed by FMT_MOF_EXT.1.2 in the selected EP.

FCS_TLSC_EXT.1 is modified as follows:

FCS_TLSC_EXT.1 TLS Client Protocol

FCS_TLSC_EXT.1.1 The TSF shall implement [selection: TLS 1.2 (RFC 5246), TLS 1.1 (RFC 4346)] supporting the following cipher suites: [selection:

·         TLS_RSA_WITH_AES_128_CBC_SHA as defined in RFC 3268

·         TLS_RSA_WITH_AES_256_CBC_SHA as defined in RFC 3268

·         TLS_DHE_RSA_WITH_AES_128_CBC_SHA as defined in RFC 3268

·         TLS_DHE_RSA_WITH_AES_256_CBC_SHA as defined in RFC 3268

·         TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA as defined in RFC 4492

·         TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA as defined in RFC 4492

·         TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA as defined in RFC 4492

·         TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA as defined in RFC 4492

·         TLS_RSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5246

·         TLS_RSA_WITH_AES_256_CBC_ SHA256 as defined in RFC 5246

·         TLS_DHE_RSA_WITH_AES_128_CBC_ SHA256 as defined in RFC 5246

·         TLS_DHE_RSA_WITH_AES_256_CBC_ SHA256 as defined in RFC 5246

·         TLS_RSA_WITH_AES_128_GCM_SHA256 as defined in RFC 5288

·         TLS_RSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5288

·         TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 as defined in RFC 5288

·         TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5288

·         TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5289

·         TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 as defined in RFC 5289

·         TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 as defined in RFC 5289

·         TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5289

·         TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 as defined in RFC 5289

·         TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5289

·         TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5289

·         TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 as defined in RFC 5289 ].

Application Note: The ST author should select the cipher suites that are supported and must select at least one cipher suite. The cipher suites to be tested in the evaluated configuration are limited by this requirement. However, this requirement does not restrict the TOE's ability to propose additional cipher suites beyond the ones listed in this requirement in its Client Hello message. That is, the TOE may propose any cipher suite but the evaluation will only test cipher suites from the above list. It is necessary to limit the cipher suites that can be used in an evaluated configuration administratively on the server in the test environment. GCM cipher suites are preferred over CBC cipher suites, ECDHE preferred over RSA and DHE, and SHA256 or SHA384 over SHA. TLS_RSA_WITH_AES_128_CBC_SHA is not required despite being mandated by RFC 5246.

If any cipher suites are selected using ECDHE, then FCS_TLSC_EXT.1.4 is required.

In a future version of this PP TLS v1.2 will be required for all TOEs.

Assurance Activity

The evaluator shall check the description of the implementation of this protocol in the TSS to ensure that the cipher suites supported are specified. The evaluator shall check the TSS to ensure that the cipher suites specified include those listed for this component.

Tests

Test 1: The evaluator shall establish a TLS connection using each of the cipher suites specified by the requirement. This connection may be established as part of the establishment of a higher-level protocol, e.g., as part of an EAP session. It is sufficient to observe the successful negotiation of a cipher suite to satisfy the intent of the test; it is not necessary to examine the characteristics of the encrypted traffic in an attempt to discern the cipher suite being used (for example, that the cryptographic algorithm is 128-bit AES and not 256-bit AES).

Test 2: The evaluator shall attempt to establish the connection using a server with a server certificate that contains the Server Authentication purpose in the extendedKeyUsage field and verify that a connection is established. The evaluator will then verify that the client rejects an otherwise valid server certificate that lacks the Server Authentication purpose in the extendedKeyUsage field and a connection is not established. Ideally, the two certificates should be identical except for the extendedKeyUsage field.

Test 3: The evaluator shall send a server certificate in the TLS connection that the does not match the server-selected cipher suite (for example, send a ECDSA certificate while using the TLS_RSA_WITH_AES_128_CBC_SHA cipher suite or send a RSA certificate while using one of the ECDSA cipher suites.) The evaluator shall verify that the TOE disconnects after receiving the server’s Certificate handshake message.

Test 4: The evaluator shall configure the server to select the TLS_NULL_WITH_NULL_NULL cipher suite and verify that the client denies the connection.

Test 5: The evaluator shall perform the following modifications to the traffic:

·         Change the TLS version selected by the server in the Server Hello to a non-supported TLS version (for example 1.3 represented by the two bytes 03 04) and verify that the client rejects the connection.

·         Modify at least one byte in the server’s nonce in the Server Hello handshake message, and verify that the client rejects the Server Key Exchange handshake message (if using a DHE or ECDHE cipher suite) or that the server denies the client’s Finished handshake message.

·         Modify the server’s selected cipher suite in the Server Hello handshake message to be a cipher suite not presented in the Client Hello handshake message. The evaluator shall verify that the client rejects the connection after receiving the Server Hello.

  • (conditional): If an ECDHE or DHE cipher suite is selected, modify the signature block in the Server’s Key Exchange handshake message, and verify that the client rejects the connection after receiving the Server Key Exchange message.

·         Modify a byte in the Server Finished handshake message, and verify that the client sends a fatal alert upon receipt and does not send any application data.

·         Send a garbled message from the Server after the Server has issued the ChangeCipherSpec message and verify that the client denies the connection.

 

FCS_TLSC_EXT.1.2           The TSF shall verify that the presented identifier matches the reference identifier according to RFC 6125.

Application Note: The rules for verification of identity are described in Section 6 of RFC 6125. The reference identifier is established by the user (e.g., entering a URL into a web browser or clicking a link), by configuration (e.g., configuring the name of a mail server or authentication server), or by an application (e.g., a parameter of an API) depending on the application service. Based on a singular reference identifier’s source domain and application service type (e.g., HTTP, SIP, LDAP), the client establishes all reference identifiers which are acceptable, such as a Common Name for the Subject Name field of the certificate and a (case-insensitive) DNS name, URI name, and Service Name for the Subject Alternative Name field. The client then compares this list of all acceptable reference identifiers to the presented identifiers in the TLS server’s certificate.

The preferred method for verification is the Subject Alternative Name using DNS names, URI names, or Service Names. Verification using the Common Name is required for the purposes of backwards compatibility. Additionally, support for use of IP addresses in the Subject Name or Subject Alternative name is discouraged as against best practices but may be implemented. Finally, the client should avoid constructing reference identifiers using wildcards. However, if the presented identifiers include wildcards, the client must follow the best practices regarding matching; these best practices are captured in the assurance activity. 

Assurance Activity

The evaluator shall ensure that the TSS describes the client’s method of establishing all reference identifiers from the administrator/application-configured reference identifier, including which types of reference identifiers are supported (e.g., Common Name, DNS Name, URI Name, Service Name, or other application-specific Subject Alternative Names) and whether IP addresses and wildcards are supported. The evaluator shall ensure that this description identifies whether and the manner in which certificate pinning is supported or used by the TOE.

Tests

The evaluator shall configure the reference identifier according to the AGD guidance and perform the following tests during a TLS connection:

Test 1: The evaluator shall present a server certificate that does not contain an identifier in either the Subject Alternative Name (SAN) or Common Name (CN) that matches the reference identifier. The evaluator shall verify that the connection fails.

Test 2: The evaluator shall present a server certificate that contains a CN that matches the reference identifier, contains the SAN extension, but does not contain an identifier in the SAN that matches the reference identifier. The evaluator shall verify that the connection fails. The evaluator shall repeat this test for each supported SAN type.

Test 3: The evaluator shall present a server certificate that contains a CN that matches the reference identifier and does not contain the SAN extension. The evaluator shall verify that the connection succeeds.

Test 4: The evaluator shall present a server certificate that contains a CN that does not match the reference identifier but does contain an identifier in the SAN that matches. The evaluator shall verify that the connection succeeds.

Test 5: The evaluator shall perform the following wildcard tests with each supported type of reference identifier:

1.       The evaluator shall present a server certificate containing a wildcard that is not in the left-most label of the presented identifier (e.g., foo.*.example.com) and verify that the connection fails.

2.       The evaluator shall present a server certificate containing a wildcard in the left-most label (e.g., *.example.com). The evaluator shall configure the reference identifier with a single left-most label (e.g., foo.example.com) and verify that the connection succeeds. The evaluator shall configure the reference identifier without a left-most label as in the certificate (e.g., example.com) and verify that the connection fails. The evaluator shall configure the reference identifier with two left-most labels (e.g., bar.foo.example.come) and verify that the connection fails.

Test 6: [conditional] If URI or Service name reference identifiers are supported, the evaluator shall configure the DNS name and the service identifier. The evaluator shall present a server certificate containing the correct DNS name and service identifier in the URIName or SRVName fields of the SAN and verify that the connection succeeds. The evaluator shall repeat this test with the wrong service identifier (but correct DNS name) and verify that the connection fails.

Test 7: [conditional] If pinned certificates are supported the evaluator shall present a certificate that does not match the pinned certificate and verify that the connection fails.

 

FCS_TLSC_EXT.1.3The TSF shall establish a trusted channel only if the peer certificate is valid.

Application Note: Validity is determined by the identifier verification, certificate path, the expiration date, and the revocation status in accordance with RFC 5280. Certificate validity shall be tested in accordance with testing performed for FIA_X509_EXT.1.

Assurance Activity

Tests

Test 1: The evaluator shall demonstrate that using a certificate without a valid certification path results in the function failing. Using the administrative guidance, the evaluator shall then load a certificate or certificates needed to validate the certificate to be used in the function, and demonstrate that the function succeeds. The evaluator then shall delete one of the certificates, and show that the function fails.

 

FCS_TLSC_EXT.1.4:     The TSF shall present the Supported Elliptic Curves Extension in the Client Hello handshake message with the following NIST curves: [selection: secp256r1, secp384r1, secp521r1] and no other curves.

Application Note: If cipher suites with elliptic curves were selected in FCS_TLSC_EXT.1.1, then this component is required. This requirement does not limit the elliptic curves the client may propose for authentication and key agreement.  Rather, it asks the ST author to define which of the NIST curves from FCS_COP.1(2) and FCS_CKM.1 and FCS_CKM.2 the TOE supports. This extension is required for clients supporting Elliptic Curve cipher suites.

Assurance Activity:

Assurance Activity

The evaluator shall verify that TSS describes the Supported Elliptic Curves Extension and whether the required behavior is performed by default or may be configured.

Tests

Test 1:  The evaluator shall configure a server to perform ECDHE key exchange using each of the TOE’s supported curves and shall verify that the TOE successfully connects to the server. 

 

 

 

FCS_TLSC_EXT.2 will be modified as follows:

FCS_TLSC_EXT.2 TLS Client Protocol with Mutual Authentication

FCS_TLSC_EXT.2.1 The TSF shall implement [selection: TLS 1.2 (RFC 5246), TLS 1.1 (RFC 4346)] supporting the following cipher suites: [selection:

·         TLS_RSA_WITH_AES_128_CBC_SHA as defined in RFC 3268

·         TLS_RSA_WITH_AES_256_CBC_SHA as defined in RFC 3268

·         TLS_DHE_RSA_WITH_AES_128_CBC_SHA as defined in RFC 3268

·         TLS_DHE_RSA_WITH_AES_256_CBC_SHA as defined in RFC 3268

·         TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA as defined in RFC 4492

·         TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA as defined in RFC 4492

·         TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA as defined in RFC 4492

·         TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA as defined in RFC 4492

·         TLS_RSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5246

·         TLS_RSA_WITH_AES_256_CBC_ SHA256 as defined in RFC 5246

·         TLS_DHE_RSA_WITH_AES_128_CBC_ SHA256 as defined in RFC 5246

·         TLS_DHE_RSA_WITH_AES_256_CBC_ SHA256 as defined in RFC 5246

·         TLS_RSA_WITH_AES_128_GCM_SHA256 as defined in RFC 5288

·         TLS_RSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5288

·         TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 as defined in RFC 5288

·         TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5288

·         TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5289

·         TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 as defined in RFC 5289

·         TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 as defined in RFC 5289

·         TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5289

·         TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 as defined in RFC 5289

·         TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5289

·         TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5289

·         TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 as defined in RFC 5289].

 Application Note:

The ST author should select the cipher suites that are supported and must select at least one cipher suite. The cipher suites to be tested in the evaluated configuration are limited by this requirement. However, this requirement does not restrict the TOE's ability to propose additional cipher suites beyond the ones listed in this requirement in its Client Hello message. That is, the TOE may propose any cipher suite but the evaluation will only test cipher suites from the above list. It is necessary to limit the cipher suites that can be used in an evaluated configuration administratively on the server in the test environment. GCM cipher suites are preferred over CBC cipher suites, ECDHE preferred over RSA and DHE, and SHA256 or SHA384 over SHA. TLS_RSA_WITH_AES_128_CBC_SHA is not required despite being mandated by RFC 5246.

 These requirements will be revisited as new TLS versions are standardized by the IETF.

 If any cipher suites are selected using ECDHE, then FCS_TLSC_EXT.2.5 is required.

 In a future version of this PP TLS v1.2 will be required for all TOEs.

 

Assurance Activity

The evaluator shall check the description of the implementation of this protocol in the TSS to ensure that the cipher suites supported are specified. The evaluator shall check the TSS to ensure that the cipher suites specified include those listed for this component.

Tests

Test 1: The evaluator shall establish a TLS connection using each of the cipher suites specified by the requirement. This connection may be established as part of the establishment of a higher-level protocol, e.g., as part of an EAP session. It is sufficient to observe the successful negotiation of a cipher suite to satisfy the intent of the test; it is not necessary to examine the characteristics of the encrypted traffic in an attempt to discern the cipher suite being used (for example, that the cryptographic algorithm is 128-bit AES and not 256-bit AES).

Test 2: The evaluator shall attempt to establish the connection using a server with a server certificate that contains the Server Authentication purpose in the extendedKeyUsage field and verify that a connection is established. The evaluator will then verify that the client rejects an otherwise valid server certificate that lacks the Server Authentication purpose in the extendedKeyUsage field and a connection is not established. Ideally, the two certificates should be identical except for the extendedKeyUsage field.

Test 3: The evaluator shall send a server certificate in the TLS connection that the does not match the server-selected cipher suite (for example, send a ECDSA certificate while using the TLS_RSA_WITH_AES_128_CBC_SHA cipher suite or send a RSA certificate while using one of the ECDSA cipher suites.) The evaluator shall verify that the TOE disconnects after receiving the server’s Certificate handshake message.

Test 4: The evaluator shall configure the server to select the TLS_NULL_WITH_NULL_NULL cipher suite and verify that the client denies the connection.

Test 5: The evaluator shall perform the following modifications to the traffic:

  • Change the TLS version selected by the server in the Server Hello to a non-supported TLS version (for example 1.3 represented by the two bytes 03 04) and verify that the client rejects the connection.
  •  Modify at least one byte in the server’s nonce in the Server Hello handshake message, and verify that the client rejects the Server Key Exchange handshake message (if using a DHE or ECDHE cipher suite) or that the server denies the client’s Finished handshake message.
  •  Modify the server’s selected cipher suite in the Server Hello handshake message to be a cipher suite not presented in the Client Hello handshake message. The evaluator shall verify that the client rejects the connection after receiving the Server Hello.
  • (conditional): If an ECDHE or DHE cipher suite is selected, modify the signature block in the Server’s Key Exchange handshake message, and verify that the client rejects the connection after receiving the Server Key Exchange message.
  • Modify a byte in the Server Finished handshake message, and verify that the client sends a fatal alert upon receipt and does not send any application data.
  •  Send a garbled message from the Server after the Server has issued the ChangeCipherSpec message and verify that the client denies the connection.

 

FCS_TLSC_EXT.2.2           The TSF shall verify that the presented identifier matches the reference identifier according to RFC 6125.

Application Note: The rules for verification of identity are described in Section 6 of RFC 6125. The reference identifier is established by the user (e.g., entering a URL into a web browser or clicking a link), by configuration (e.g., configuring the name of a mail server or authentication server), or by an application (e.g., a parameter of an API) depending on the application service. Based on a singular reference identifier’s source domain and application service type (e.g., HTTP, SIP, LDAP), the client establishes all reference identifiers which are acceptable, such as a Common Name for the Subject Name field of the certificate and a (case-insensitive) DNS name, URI name, and Service Name for the Subject Alternative Name field. The client then compares this list of all acceptable reference identifiers to the presented identifiers in the TLS server’s certificate.

 

The preferred method for verification is the Subject Alternative Name using DNS names, URI names, or Service Names. Verification using the Common Name is required for the purposes of backwards compatibility. Additionally, support for use of IP addresses in the Subject Name or Subject Alternative name is discouraged as against best practices but may be implemented. Finally, the client should avoid constructing reference identifiers using wildcards. However, if the presented identifiers include wildcards, the client must follow the best practices regarding matching; these best practices are captured in the assurance activity. 

Assurance Activity

The evaluator shall ensure that the TSS describes the client’s method of establishing all reference identifiers from the administrator/application-configured reference identifier, including which types of reference identifiers are supported (e.g., Common Name, DNS Name, URI Name, Service Name, or other application-specific Subject Alternative Names) and whether IP addresses and wildcards are supported. The evaluator shall ensure that this description identifies whether and the manner in which certificate pinning is supported or used by the TOE.

Tests

The evaluator shall configure the reference identifier according to the AGD guidance and perform the following tests during a TLS connection:

Test 1: The evaluator shall present a server certificate that does not contain an identifier in either the Subject Alternative Name (SAN) or Common Name (CN) that matches the reference identifier. The evaluator shall verify that the connection fails.

Test 2: The evaluator shall present a server certificate that contains a CN that matches the reference identifier, contains the SAN extension, but does not contain an identifier in the SAN that matches the reference identifier. The evaluator shall verify that the connection fails. The evaluator shall repeat this test for each supported SAN type.

Test 3: The evaluator shall present a server certificate that contains a CN that matches the reference identifier and does not contain the SAN extension. The evaluator shall verify that the connection succeeds.

Test 4: The evaluator shall present a server certificate that contains a CN that does not match the reference identifier but does contain an identifier in the SAN that matches. The evaluator shall verify that the connection succeeds.

Test 5: The evaluator shall perform the following wildcard tests with each supported type of reference identifier:

1.       The evaluator shall present a server certificate containing a wildcard that is not in the left-most label of the presented identifier (e.g., foo.*.example.com) and verify that the connection fails.

2.       The evaluator shall present a server certificate containing a wildcard in the left-most label (e.g., *.example.com). The evaluator shall configure the reference identifier with a single left-most label (e.g., foo.example.com) and verify that the connection succeeds. The evaluator shall configure the reference identifier without a left-most label as in the certificate (e.g., example.com) and verify that the connection fails. The evaluator shall configure the reference identifier with two left-most labels (e.g., bar.foo.example.come) and verify that the connection fails.

Test 6: [conditional] If URI or Service name reference identifiers are supported, the evaluator shall configure the DNS name and the service identifier. The evaluator shall present a server certificate containing the correct DNS name and service identifier in the URIName or SRVName fields of the SAN and verify that the connection succeeds. The evaluator shall repeat this test with the wrong service identifier (but correct DNS name) and verify that the connection fails.

Test 7: [conditional] If pinned certificates are supported the evaluator shall present a certificate that does not match the pinned certificate and verify that the connection fails.

 

 FCS_TLSC_EXT.2.3 The TSF shall establish a trusted channel only if the peer certificate is valid.

Application Note: Validity is determined by the identifier verification, certificate path, the expiration date, and the revocation status in accordance with RFC 5280. Certificate validity shall be tested in accordance with testing performed for FIA_X509_EXT.1.

 

Assurance Activity

Tests

Test 1: The evaluator shall demonstrate that using a certificate without a valid certification path results in the function failing. Using the administrative guidance, the evaluator shall then load a certificate or certificates needed to validate the certificate to be used in the function, and demonstrate that the function succeeds. The evaluator then shall delete one of the certificates, and show that the function fails.

 

FCS_TLSC_EXT.2.4           The TSF shall support mutual authentication using X.509v3 certificates.

 

Application Note:  The  use  of  X.509v3  certificates  for  TLS  is  addressed  in  FIA_X509_EXT.2.1.  This requirement  adds  that  this  use  must  include  the  client  must  be  capable  of presenting a certificate to a TLS server for TLS mutual authentication.

Assurance Activity

The evaluator shall ensure that the TSS description required per FIA_X509_EXT.2.1 includes the use of client-side certificates for TLS mutual authentication.

Tests

Test 1: The evaluator shall perform the following modification to the traffic:

  • Configure the server to require mutual authentication and then modify a byte in a CA field in the Server’s Certificate Request handshake message. The modified CA field shall not be the CA used to sign the client’s certificate. The evaluator shall verify the connection is unsuccessful.

 

FCS_TLSC_EXT.2.5           The TSF shall present the Supported Elliptic Curves Extension in the Client Hello with the following NIST curves: [selection: secp256r1, secp384r1, secp521r1] and no other curves.

Application Note: If cipher suites with elliptic curves were selected in FCS_TLSC_EXT.2.1, this component is required.

This requirement limits the elliptic curves allowed for authentication and key agreement to the NIST curves from FCS_COP.1(2) and FCS_CKM.1 and FCS_CKM.2. This extension is required for clients supporting Elliptic Curve cipher suites. 

Assurance Activity

The evaluator shall verify that TSS describes the Supported Elliptic Curves Extension and whether the required behavior is performed by default or may be configured.

Tests

Test 1: The evaluator shall configure the server to perform an ECDHE key exchange in the TLS connection using a non-supported curve (for example P-192) and shall verify that the TOE disconnects after receiving the server’s Key Exchange handshake message.

 

FCS_TLSS_EXT.1 is modified as follows:

FCS_TLSS_EXT.1 TLS Server Protocol

FCS_TLSS_EXT.1.1 The TSF shall implement [selection: TLS 1.2 (RFC 5246), TLS 1.1 (RFC 4346)] supporting the following cipher suites: [selection:

·         TLS_RSA_WITH_AES_128_CBC_SHA as defined in RFC 3268

·         TLS_RSA_WITH_AES_256_CBC_SHA as defined in RFC 3268

·         TLS_DHE_RSA_WITH_AES_128_CBC_SHA as defined in RFC 3268

·         TLS_DHE_RSA_WITH_AES_256_CBC_SHA as defined in RFC 3268

·         TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA as defined in RFC 4492

·         TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA as defined in RFC 4492

·         TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA as defined in RFC 4492

·         TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA as defined in RFC 4492

·         TLS_RSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5246

·         TLS_RSA_WITH_AES_256_CBC_ SHA256 as defined in RFC 5246

·         TLS_DHE_RSA_WITH_AES_128_CBC_ SHA256 as defined in RFC 5246

·         TLS_DHE_RSA_WITH_AES_256_CBC_ SHA256 as defined in RFC 5246

·         TLS_RSA_WITH_AES_128_GCM_SHA256 as defined in RFC 5288

·         TLS_RSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5288

·         TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 as defined in RFC 5288

·         TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5288

·         TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5289

·         TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 as defined in RFC 5289

·         TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 as defined in RFC 5289

·         TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5289

·         TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 as defined in RFC 5289

·         TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5289

·         TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5289

·         TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 as defined in RFC 5289].

Application Note:

The ST author should select the cipher suites that are supported and must select at least one cipher suite. It is necessary to limit the cipher suites that can be used in an evaluated configuration administratively on the server in the test environment. If administrative steps need to be taken so that the cipher suites negotiated by the implementation are limited to those in this requirement, then the appropriate instructions need to be contained in the guidance. GCM cipher suites are preferred over CBC cipher suites, ECDHE preferred over RSA and DHE, and SHA256 or SHA384 over SHA. TLS_RSA_WITH_AES_128_CBC_SHA is not required despite being mandated by RFC 5246.

These requirements will be revisited as new TLS versions are standardized by the IETF.

If any cipher suites are selected using ECDHE, then FCS_TLSS_EXT.1.3 is required.

In a future version of this PP TLS v1.2 will be required for all TOEs.

FCS_TLSS_EXT.1.1, Test 4, bullet 2 is updated as follows:

 

"(conditional): If an ECDHE or DHE cipher suite is selected, modify the signature block in the Client’s Key Exchange handshake message, and verify that the server rejects the client’s Certificate Verify handshake message (if using mutual authentication) or that the server denies the client’s Finished handshake message."

FCS_TLSS_EXT.1.1, Test 4 bullet 4 is modified as follows:

[conditional] After generating a fatal alert by sending a Finished message from the client before the client sends a ChangeCipherSpec message, send a Client Hello with the session identifier from the previous test, and verify that the server denies the connection. This test is not required for applications with a TLS implementation that does not support session IDs.

 

FCS_TLSS_EXT.1.2 is replaced with the following:

FCS_TLSS_EXT.1.2: The TSF shall deny connections from clients requesting SSL 2.0, SSL 3.0, TLS 1.0, and [selection: TLS 1.1, TLS 1.2, none].

Application Note: All SSL versions and TLS v1.0 shall be denied. Any TLS versions not selected in FCS_TLSS_EXT.1.1 should be selected here.

Assurance Activity

TSS

The evaluator shall verify that the TSS contains a description of the denial of old SSL and TLS versions.

Operational Guidance

The evaluator shall verify that any configuration necessary to meet the requirement are contained in the AGD guidance.

Tests

The evaluator shall send a Client Hello requesting a connection for all mandatory and selected protocol versions in the SFR (e.g. by enumeration of protocol versions in a test client) and verify that the server denies the connection for each attempt.

 

FCS_TLSS_EXT.1.3 is replaced with the following:

FCS_TLSS_EXT.1.3 The TSF shall [selection: perform RSA key establishment with key size [selection: 2048 bits, 3072 bits, 4096 bits]; generate EC Diffie-Hellman parameters over NIST curves [selection: secp256r1, secp384r1, secp521r1] and no other curves; generate DiffieHellman parameters of size [selection: 2048 bits, 3072 bits]].

Application Note:  If the ST lists a DHE or ECDHE cipher suite in FCS_TLSS_EXT.1.1, the ST must include the Diffie-Hellman or NIST curves selection in the requirement.  FMT_MOF_EXT.1.2 in the selected EP addresses the "Ability to configure the cryptographic functionality" which allows for the configuration of the key agreement parameters in order to establish the security strength of the TLS connection. 

FCS_TLSS_EXT.2 is modified as follows:

FCS_TLSS_EXT.2 TLS Server Protocol with Mutual Authentication

FCS_TLSS_EXT.2.1 The TSF shall implement [selection: TLS 1.2 (RFC 5246), TLS 1.1 (RFC 4346)] supporting the following cipher suites: : [selection:

·         TLS_RSA_WITH_AES_128_CBC_SHA as defined in RFC 3268

·         TLS_RSA_WITH_AES_256_CBC_SHA as defined in RFC 3268

·         TLS_DHE_RSA_WITH_AES_128_CBC_SHA as defined in RFC 3268

·         TLS_DHE_RSA_WITH_AES_256_CBC_SHA as defined in RFC 3268

·         TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA as defined in RFC 4492

·         TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA as defined in RFC 4492

·         TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA as defined in RFC 4492

·         TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA as defined in RFC 4492

·         TLS_RSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5246

·         TLS_RSA_WITH_AES_256_CBC_ SHA256 as defined in RFC 5246

·         TLS_DHE_RSA_WITH_AES_128_CBC_ SHA256 as defined in RFC 5246

·         TLS_DHE_RSA_WITH_AES_256_CBC_ SHA256 as defined in RFC 5246

·         TLS_RSA_WITH_AES_128_GCM_SHA256 as defined in RFC 5288

·         TLS_RSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5288

·         TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 as defined in RFC 5288

·         TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5288

·         TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5289

·         TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 as defined in RFC 5289

·         TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 as defined in RFC 5289

·         TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5289

·         TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 as defined in RFC 5289

·         TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5289

·         TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5289

·         TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 as defined in RFC 5289].

Application Note:

The ST author should select the cipher suites that are supported and must select at least one cipher suite. It is necessary to limit the cipher suites that can be used in an evaluated configuration administratively on the server in the test environment. If administrative steps need to be taken so that the cipher suites negotiated by the implementation are limited to those in this requirement, then the appropriate instructions need to be contained in the guidance. GCM cipher suites are preferred over CBC cipher suites, ECDHE preferred over RSA and DHE, and SHA256 or SHA384 over SHA. TLS_RSA_WITH_AES_128_CBC_SHA is not required despite being mandated by RFC 5246.

These requirements will be revisited as new TLS versions are standardized by the IETF.

If any cipher suites are selected using ECDHE, then FCS_TLSS_EXT.2.3 is required.

In a future version of this PP TLS v1.2 will be required for all TOEs.

 

FCS_TLSS_EXT.2.1, Test 4, bullet 2 is updated as follows:

 

"(conditional): If an ECDHE or DHE cipher suite is selected, modify the signature block in the Client’s Key Exchange handshake message, and verify that the server rejects the client’s Certificate Verify handshake message (if using mutual authentication) or that the server denies the client’s Finished handshake message."

 

FCS_TLSS_EXT.2.1, Test 4, bullet 4 is updated as follows:

 [conditional] After generating a fatal alert by sending a Finished message from the client before the client sends a ChangeCipherSpec message, send a Client Hello with the session identifier from the previous test, and verify that the server denies the connection. This test is not required for applications with a TLS implementation that does not support session IDs.

 

FCS_TLSS_EXT.2.2 is replaced with the following:

FCS_TLSS_EXT.2.2: The TSF shall deny connections from clients requesting SSL 2.0, SSL 3.0, TLS 1.0, and [selection: TLS 1.1, TLS 1.2, none].

Application Note: All SSL versions and TLS v1.0 shall be denied. Any TLS versions not selected in FCS_TLSS_EXT.1.1 should be selected here.

Assurance Activity

TSS

The evaluator shall verify that the TSS contains a description of the denial of old SSL and TLS versions.

Operational Guidance

The evaluator shall verify that any configuration necessary to meet the requirement are contained in the AGD guidance.

Tests

The evaluator shall send a Client Hello requesting a connection for all mandatory and selected protocol versions in the SFR (e.g. by enumeration of protocol versions in a test client) and verify that the server denies the connection for each attempt.

 

FCS_TLSS_EXT.2.3 is replaced with the following:

FCS_TLSS_EXT.2.3 The TSF shall [selection: perform RSA key establishment with key size [selection: 2048 bits, 3072 bits, 4096 bits]; generate EC Diffie-Hellman parameters over NIST curves [selection: secp256r1, secp384r1, secp521r1] and no other curves; generate DiffieHellman parameters of size [selection: 2048 bits, 3072 bits]].

Application Note: If the ST lists a DHE or ECDHE cipher suite in FCS_TLSS_EXT.2.1, the ST must include the Diffie-Hellman or NIST curves selection in the requirement. FMT_MOF_EXT.1.2 in the selected EP addresses  the "Ability to configure the cryptographic functionality" which allows for the configuration of the key agreement parameters in order to establish the security strength of the TLS connection.

 

FCS_TLSS_EXT.2.4 Test 4 is changed as follows:

 

"Test 4: If the TOE supports sending a non-empty Certificate Authorities list in its Certificate Request message, the evaluator shall configure the client to send a certificate that does not chain to one of the Certificate Authorities (either a Root or Intermediate CA) in the server’s Certificate Request message. The evaluator shall verify that the attempted connection is denied. If the TOE doesn't support sending a non-empty Certificate Authorities list in its Certificate Request message, this test shall be omitted."

 

Table 4 in Annex B is replaced with:

 

Requirement

Auditable Events

Additional Audit Record Contents

FCS_IPSEC_EXT.1

Failure to establish an IPsec SA. Establishment/Termination of an IPsec SA.

Reason for failure.

Non-TOE endpoint of connection (IP address) for both successes and failures.

FIA_X509_EXT.1

Failure to validate a certificate.

Reason for failure.

FIA_X509_EXT.2

None.

None.

FIA_PMG_EXT.1

None.

None.

FPT_TUD_EXT.2

None.

None.

FTP_TRP.1

Initiation of the trusted channel. Termination of the trusted channel. Failure of the trusted channel functions.

User ID and remote source (IP address) if feasible.
Justification

See issue description.

 
 
Site Map              Contact Us              Home