The SFRs for TLS in the NIAP ESM PPs are outdated and do not describe current expectations with respect to these protocols. TD0575 was issued to address these deficiencies.

Some test cases in TD0575 do not apply if the TOE is operating as a server.

TD0575 is archived and replaced with the following:

Section 5.3.6.1 and Appendix C.8.11 are replaced in ESM ICM and PM PPs, and Appendix C.5.1 is replaced in AC PP as follows.

 FCS_TLS_EXT.1

The product shall implement TLS 1.2 (RFC 5246) and [selection: TLS 1.1 (RFC 4346), no earlier TLS versions] that supports the cipher suites [selection:

TLS_RSA_WITH_AES_128_CBC_SHA as defined in RFC 5246,

TLS_RSA_WITH_AES_256_CBC_SHA as defined in RFC 5246,

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_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_CBC_SHA256 as defined in RFC 5246, TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 as defined in RFC 5246,

TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 as defined in RFC5288,

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_128_GCM_SHA256 as defined in RFC 5289, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 as defined in RFC 5289, TLS_ECDHE_ECDSA_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_128_GCM_SHA256 as defined in RFC 5289, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 as defined in RFC 5289, TLS_ECDHE_RSA_WITH_AES_256_GCM_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. While the TOE may support other cipher suites the evaluation will only test cipher suites from the above list. The ciphersuites to be tested in the evaluated configuration are limited by this requirement; however, this requirement does not restrict the suites proposed (in a Client Hello). 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.

Assurance Activity

TSS

The evaluator shall check the TSS to ensure that it describes whether the TOE acts as a TLS server, TLS client, or both and map this to specific trusted path/channel cases. If a specific TLS application is not part of the evaluated configuration, the TSS shall identify it, specifically declare it as out of scope, and declare whether it is disabled by default.

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.

Guidance

The evaluator shall also check the operational guidance to ensure that it contains instructions on configuring the product so that TLS conforms to the description in the TSS.  If administrative steps need to be taken to disable a specific TLS application or 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.

Tests

The evaluator shall also perform the following tests for each use of TLS in the TOE (as defined in the TSS):

Test 1: The evaluator shall establish a TLS connection using each claimed cipher suite specified by the requirement. It is sufficient to observe the successful handshake following the 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 perform the following modifications to the Client/Server Hellos:

Test 2a: [conditional on TOE implementing TLS client] The evaluator shall send a Server Hello containing only the TLS_NULL_WITH_NULL_NULL cipher suite and verify that the TOE denies the connection.

Test 2b: [conditional on TOE implementing TLS Server] The evaluator shall send a Client Hello containing only the TLS_NULL_WITH_NULL_NULL cipher suite and verify that the TOE denies the connection.

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

Test 3a: [conditional on TOE implementing TLS client]

Test 3a.1: Change the TLS version sent in the Server Hello to an undefined TLS version (for example 1.5 represented by the two bytes 03 06) and verify that the TOE rejects the connection.

Test 3a.2: Change the TLS version sent in the Server Hello to the most recent unsupported TLS version (for example 1.1 represented by the two bytes 03 02) and verify that the TOE rejects the connection.

Test 3a.3: If DHE or ECDHE cipher suites are supported, modify at least one byte in the server’s nonce in the Server Hello handshake message, and verify that the handshake is not completed and no application data flows. If a TOE only supports RSA key exchange in conjunction with TLS, then this test shall be omitted.

Test 3a.4: [conditional] If DHE or ECDHE cipher suites are supported, modify the signature block in the server’s Key Exchange handshake message, and verify that the handshake does not complete and no application data flows. If a TOE only supports RSA key exchange in conjunction with TLS, then this test shall be omitted.

Test 3a.5:

Test 3a.5a: 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 does not complete the handshake and no application data flows.

Test 3a.5b: Modify a byte in the Server Finished handshake message and verify the client does not complete the handshake and no application data flows.

Test 3a.5c: Send a garbled message from the server after the server has issued the Change Cipher Spec message and verify that the client does not complete the handshake and no application data flows. The garbled message must still have a valid 5-byte (1 byte record type, followed by 2 byte version, and 2 byte length) record layer header with matching version in order to ensure the message will be parsed appropriately. For example, for TLS v1.2 Change Cipher Spec (14 03 03 00 01 01) followed by a garbled message (16 03 03 00 40 14 00 00 …).

Test 3b: [conditional on TOE implementing TLS server]

Test 3b.1: Change the TLS version sent in the Client Hello to the most recent unsupported TLS version (for example 1.1 represented by the two bytes 03 02) and verify that the TOE rejects the connection.

Test 3b.2:

Test 3b.2a: Modify a byte in the data of the client’s Finished handshake message and verify the server rejects the connection and does not send any application data.

Test 3b.2b: Demonstrate that the TOE will not resume a session for which the client failed to complete the handshake (independent of TOE support for session resumption). Generate a Fatal Alert by sending a Finished message from the client before the client sends a ChangeCipherSpec message, and then send a ClientHello with the session identifier from the previous incomplete session and verify the server does not resume the session.

Test 3b.2c: Send a garbled message from the client after the client has issued the Change Cipher Spec message and verify that the server does not complete the handshake and no application data flows. The garbled message must still have a valid 5-byte (1 byte record type, followed by 2 byte version, and 2 byte length) record layer header with matching version in order to ensure the message will be parsed appropriately. For example, for TLS v1.2 Change Cipher Spec (14 03 03 00 01 01) followed by a garbled message (16 03 03 00 40 14 00 00 …).

Updating these SFRs, and the associated Assurance Activity, brings them in line with current standards and adds stronger, more commonly used algorithms.