NIAP: View Technical Decision Details
NIAP/CCEVS
  NIAP  »»  Protection Profiles  »»  Technical Decisions  »»  View Details  
TD0294:  Correction of TLS SFRs in CA PP ver 2.1

Publication Date
2018.04.18

Protection Profiles
PP_CA_V2.1

Other References
FCS_TLSC_EXT.2, FCS_TLSS_EXT.1, FCS_TLSS_EXT.2

Issue Description

Incorrect SFRs for TLS in CA PP ver 2.1

Resolution

This TD is further refined in TD0796.

Updated 4/19/2016: AES192 cipher suites have been removed as they are not specified in the RFCs.

The following changes are made to the CA PP ver 2.1:

    1. In Section 4.1 -  Security Objectives for the TOE:
        Add FCS_TLSS_EXT.2 (selection-based) to the "Addressed by:" list of SFRs in O.PROTECTED_COMMUNICATIONS.
    2. In Table 3 - Security Objective Mapping:
        Add FCS_TLSS_EXT.2 (selection-based) in the "Requirements" column for T.UNAUTHORIZED_ACCESS and T.WEAK_CRYPTO, .
    3. In FIA_ESTS_EXT.1.2, FIA_ESTS_EXT.1.3, and the second sentence in the application note, change the reference to FCS_TLSS_EXT.1 to FCS_TLSS_EXT.2.
    4. In FCS_HTTPS_EXT.1.2, add the following application note:

       Application Note: If the TOE acts as a server then FCS_TLSS_EXT.1 (or FCS_TLSS_EXT.2 for mutual authentication) should be claimed.  If the TOE acts as a client then FCS_TLSC_EXT.2 for mutual authentication should be claimed.

    5. Delete FCS_TLSC_EXT.1 TLS Client Protocol from Section B. Selection-Based Requirements

    6. In Table 6 - Auditable Events for Selection-based Requirements

        Add the following entry:

       

FCS_TLSS_EXT.2

Failure to establish a TLS session.

 

Establishment/Termination of a TLS session.

Reason for failure.

 

 

 None.

Normal

 

Use the SFRs below for the following changes in Section B. Selection-Based Requirements:

    1. Add FCS_TLSC_EXT.2 TLS Client Protocol with Mutual Authentication

    2. Replace existing FCS_TLSS_EXT.1 with FCS_TLSS_EXT.1 listed below.

    3. Add FCS_TLSS_EXT.2  TLS Server Protocol with Mutual Authentication

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 ciphersuites: [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 ciphersuites to be tested in the evaluated configuration are limited by this requirement. The ST author should select the ciphersuites that are supported. It is necessary to limit the ciphersuites that can be used in an evaluated configuration administratively on the server in the test environment. The Suite B algorithms listed above (RFC 6460) are the preferred algorithms for implementation.

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

It is recognized that RFC 5246 mandates the cipher suite TLS_RSA_WITH_AES_128_CBC_SHA, but use of SHA-1 for digital signature generation is no longer recommended (see NIST SP 800-131A rev-1 and SP 800-78-4). Subsequent revisions of the PP will not include SHA-1.

Assurance Activity

TSS

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

Test

Test 1: The evaluator shall establish a TLS connection using each of the ciphersuites 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 ciphersuite 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 ciphersuite 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 ciphersuite (for example, send a ECDSA certificate while using the TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite or send a RSA certificate while using one of the ECDSA ciphersuites.) 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 ciphersuite and verify that the client denies the connection.

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

a)       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.

b)       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 ciphersuite) or that the server denies the client’s Finished handshake message.

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

d)       [conditional] If an ECDHE or DHE ciphersuite 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.

e)       Modify a byte in the Server Finished handshake message, and verify that the client sends an Encrypted Message followed by a FIN and ACK message. This is sufficient to deduce that the TOE responded with a Fatal Alert and no further data would be sent.

f)        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  identify  are  described  in  Section  6  of  RFC  6125.  The  reference identifier  is  established  by  the Administrator (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 evaluation activity.

Assurance Activity

TSS

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.

Test

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 contains a CN that does not match the reference identifier and does not contain the SAN extension. The evaluator shall verify that the connection fails.

 

Remark: Some systems might require the presence of the SAN extension. In this case the connection would still fail but for the reason of the missing SAN extension instead of the mismatch of CN and reference identifier. Both reasons are acceptable to pass Test 1.

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: [conditional]: If the TOE does not mandate the presence of the SAN extension, 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. If the TOE does mandate the presence of the SAN extension, this Test shall be omitted.

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:

·         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.

·        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

Test

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 certificate is not validated and the trusted channel is not established.

 

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

Application Note:            If ciphersuites with elliptic curves are selected in FCS_TLSC_EXT.2.1, the Supported Elliptic Curves extension populated with a selection of one or more curves is required.  If no ciphersuites with elliptic curves are selected in FCS_TLSC_EXT.2.1, the ‘not present the Supported Elliptic Curves’ option should be selected.

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 ciphersuites.

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.

Test

Test 1 (conditional – if ciphersuites with elliptic curves are claimed in the ST): 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_TLSC_EXT.2.5           The TSF shall support mutual authentication using X.509v3 certificates.

Application Note:            If FTP_ITC.1 is selected and TLS is used for FTP_ITC.1, then this component is required.

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.

Test

The purpose of these tests is to confirm that the TOE appropriately handles connection to peer servers that support and do not support mutual authentication.

Test 1: The evaluator shall establish a connection to a peer server that is not configured for mutual authentication (i.e. does not send Server's Certificate Request (type 13) message).  The evaluator observes negotiation of a TLS channel and confirms that the TOE did not send Client's Certificate message (type 11) during handshake.

Test 2:The evaluator shall establish a connection to a peer server with a shared trusted root that is configured for mutual authentication (i.e. it sends Server's Certificate Request (type 13) message).  The evaluator observes negotiation of a TLS channel and confirms that the TOE responds with a non-empty Client's Certificate message (type 11) and Certificate Verify (type 15) messages.

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 ciphersuites: [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]

and no other ciphersuite.

Application Note:            The ciphersuites to be tested in the evaluated configuration are limited by this requirement. The ST author should select the ciphersuites that are supported. It is necessary to limit the ciphersuites that can be used in an evaluated configuration administratively on the server in the test environment. The Suite B algorithms listed above (RFC 6460) are the preferred algorithms for implementation.

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

It is recognized that RFC 5246 mandates the cipher suite TLS_RSA_WITH_AES_128_CBC_SHA, but use of SHA-1 for digital signature generation is no longer recommended (see NIST SP 800-131A rev-1 and SP 800-78-4). Subsequent revisions of the PP will not include SHA-1.

Assurance Activity

TSS

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

Guidance

The evaluator shall also check the operational guidance to ensure that it contains instructions on configuring the TOE so that TLS conforms to the description in the TSS (for instance, the set of ciphersuites advertised by the TOE may have to be restricted to meet the requirements).

Test

Test 1: The evaluator shall establish a TLS connection using each of the ciphersuites 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 ciphersuite 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 ciphersuite being used (for example, that the cryptographic algorithm is 128-bit AES and not 256-bit AES).

Test 2: The evaluator shall send a Client Hello to the server with a list of ciphersuites that does not contain any of the ciphersuites in the server’s ST and verify that the server denies the connection. Additionally, the evaluator shall send a Client Hello to the server containing only the TLS_NULL_WITH_NULL_NULL ciphersuite and verify that the server denies the connection.

Test 3: The evaluator shall use a client to send a key exchange message in the TLS connection that the does not match the server-selected ciphersuite (for example, send an ECDHE key exchange while using the TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite or send a RSA key exchange while using one of the ECDSA ciphersuites.) The evaluator shall verify that the TOE disconnects after the receiving the key exchange message.

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

a)       Modify at a byte in the client’s nonce in the Client Hello 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.

b)       [conditional] If an ECDHE or DHE ciphersuite 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.

c)       Modify a byte in the Client Finished handshake message, and verify that the server rejects the connection and does not send any application data.

d)       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.

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

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, no other TLS versions].

Application Note:            All SSL versions and TLS v1.0 are 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.

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.

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 Diffie-Hellman parameters of size 2048 bits and [selection: 3072 bits, no other size]].

Application Note:            If the ST lists a DHE or ECDHE ciphersuite in FCS_TLSS_EXT.2.1, the ST must include the Diffie-Hellman or NIST curves selection in the requirement. FMT_SMF.1 requires the configuration of the key agreement parameters in order to establish the security strength of the TLS connection.

Assurance Activity

The evaluator shall verify that the TSS describes the key agreement parameters of the server key exchange message.

Guidance

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

Test

If the second selection includes any choice other than “no other”, the evaluator shall attempt a connection using an ECDHE ciphersuite and a configured curve and, using a packet analyzer, verify that the key agreement parameters in the Key Exchange message are the ones configured. (Determining that the size matches the expected size for the configured curve is sufficient.) The evaluator shall repeat this test for each supported NIST Elliptic Curve and each supported Diffie-Hellman key size.

 

 

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 ciphersuites: [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]

and no other ciphersuite.

Application Note:            The ciphersuites to be tested in the evaluated configuration are limited by this requirement. The ST author should select the ciphersuites that are supported. It is necessary to limit the ciphersuites that can be used in an evaluated configuration administratively on the server in the test environment. The Suite B algorithms listed above (RFC 6460) are the preferred algorithms for implementation.

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

It is recognized that RFC 5246 mandates the cipher suite TLS_RSA_WITH_AES_128_CBC_SHA, but use of SHA-1 for digital signature generation is no longer recommended (see NIST SP 800-131A rev-1 and SP 800-78-4). Subsequent revisions of the PP will not include SHA-1.

Assurance Activity

TSS

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

Guidance

The evaluator shall also check the operational guidance to ensure that it contains instructions on configuring the TOE so that TLS conforms to the description in the TSS (for instance, the set of ciphersuites advertised by the TOE may have to be restricted to meet the requirements).

Test

Test 1: The evaluator shall establish a TLS connection using each of the ciphersuites 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 ciphersuite 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 ciphersuite being used (for example, that the cryptographic algorithm is 128-bit AES and not 256-bit AES).

Test 2: The evaluator shall send a Client Hello to the server with a list of ciphersuites that does not contain any of the ciphersuites in the server’s ST and verify that the server denies the connection. Additionally, the evaluator shall send a Client Hello to the server containing only the TLS_NULL_WITH_NULL_NULL ciphersuite and verify that the server denies the connection.

Test 3: The evaluator shall use a client to send a key exchange message in the TLS connection that the does not match the server-selected ciphersuite (for example, send an ECDHE key exchange while using the TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite or send a RSA key exchange while using one of the ECDSA ciphersuites.) The evaluator shall verify that the TOE disconnects after the receiving the key exchange message.

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

a)       Modify at a byte in the client’s nonce in the Client Hello 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.

b)       [conditional] If an ECDHE or DHE ciphersuite 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.

c)       Modify a byte in the Client Finished handshake message, and verify that the server rejects the connection and does not send any application data.

d)       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.

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

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, no other TLS versions].

Application Note:            All SSL versions and TLS v1.0 are 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.

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.

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 Diffie-Hellman parameters of size 2048 bits and [selection: 3072 bits, no other size]].

Application Note:            If the ST lists a DHE or ECDHE ciphersuite in FCS_TLSS_EXT.2.1, the ST must include the Diffie-Hellman or NIST curves selection in the requirement. FMT_SMF.1 requires the configuration of the key agreement parameters in order to establish the security strength of the TLS connection.

Assurance Activity

The evaluator shall verify that the TSS describes the key agreement parameters of the server key exchange message.

Guidance

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

Test

If the second selection includes any choice other than “no other”, the evaluator shall attempt a connection using an ECDHE ciphersuite and a configured curve and, using a packet analyzer, verify that the key agreement parameters in the Key Exchange message are the ones configured. (Determining that the size matches the expected size for the configured curve is sufficient.) The evaluator shall repeat this test for each supported NIST Elliptic Curve and each supported Diffie-Hellman key size.

FCS_TLSS_EXT.2.4            The TSF shall support mutual authentication of TLS clients using X.509 certificates.

Application Note:            TLS with mutual authentication is the preferred mechanism for verifying proof of origin for external IT entities, for clients that are expected to have certificates issued by a Certification Authority trusted by the TSF.

Assurance Activity

TSS

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.

Guidance

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

Tests

Test 1:

The evaluator shall configure the server to send a certificate request to the client and shall attempt a connection without sending a certificate from the client. The evaluator shall verify that the connection is denied.

 

Test 2:

The evaluator shall configure the server to send a certificate request to the client without the supported signature algorithm used by the client’s certificate. The evaluator shall attempt a connection using the client certificate and verify that the connection is denied.

 

Test 3:

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.

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.

Test 5:

The evaluator shall configure the client to send a certificate with the Client Authentication purpose in the extendedKeyUsage field and verify that the server accepts the attempted connection. The evaluator shall repeat this test without  the  Client  Authentication  purpose  and  shall  verify  that  the  server denies the connection. Ideally, the two certificates should be identical except for the Client Authentication purpose.

 

Test 6:

The evaluator shall perform the following modifications to the traffic:

a)       Configure the server to require mutual authentication and then modify a byte in the client’s certificate. The  evaluator shall verify that the server rejects the connection.

b)      Configure the server to require mutual authentication and then modify a byte in the signature block of the client’s Certificate Verify handshake message. The evaluator shall verify that the server rejects the connection.

 

 

FCS_TLSS_EXT.2.5            For communications configured to require TLS with mutual authentication, the shall not establish a trusted channel if the client certificate is invalid.

Assurance Activity

TSS

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.

Guidance

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

Tests

Testing for FCS_TLSS_EXT.2.5 is included in tests for FCS_TLSS_EXT.2.4

 

FCS_TLSS_EXT.2.6            The TSF shall respond with a fatal TLS error if the distinguished name (DN) or Subject Alternative Name (SAN) contained in a certificate presented for client authentication does not match the expected identifier for the client.

Application Note:            The client identifier may be in the Subject field or the Subject Alternative Name extension of the  certificate.  The  expected  identifier  may  either  be  configured,  may  be  compared  to  the Domain Name, IP address, username, or email address used by the client, or determined by the requested service (self-service requests for certificates).

Assurance Activity

TSS

The evaluator shall verify that the TSS describes how the DN or SAN in the certificate is compared to the expected identifier.

Guidance

For each service using mutual authentication TLS which does not automatically determine the expected identifier, the evaluator shall verify that the AGD guidance includes instructions on configuring the expected identifier.

Tests

The evaluator shall send a client certificate with an identifier that does not match an expected identifier and verify that the server denies the connection.

 

 

Justification

See problem description.

 
 
Site Map              Contact Us              Home