Functional Package for Transport Layer Security (TLS) 1.1 National Information Assurance Partnership 2019-03-01 TLS 1.0 2018-12-17 First publication 1.1 2019-03-01 Clarifications regarding override for invalid certificates, renegotation_info extension, DTLS versions, and named Diffie-Hellman groups in DTLS contexts TDs Applied588 (20210512)513 ()499 (2020.02.04)469 (2019.11.20)442 (2019.11.20)

Transport Layer Security (TLS) and the closely-related Datagram TLS (DTLS) are cryptographic protocols designed to provide communications security over IP networks. Several versions of the protocol are in widespread use in software that provides functionality such as web browsing, email, instant messaging, and voice-over-IP (VoIP). Major web sites use TLS to protect communications to and from their servers. TLS is also used to protect communications between hosts and network infrastructure devices for administration. The underlying platform, such as an operating system, often provides the actual TLS implementation. The primary goal of the TLS protocol is to provide confidentiality and integrity of data transmitted between two communicating endpoints, as well as authentication of at least the server endpoint. TLS supports many different methods for exchanging keys, encrypting data, and authenticating message integrity. These methods are dynamically negotiated between the client and server when the TLS connection is established. As a result, evaluating the implementation of both endpoints is typically necessary to provide assurance for the operating environment. This "Functional Package for Transport Layer Security" (short name "TLS-PKG") defines functional requirements for the implementation of the Transport Layer Security (TLS) and Datagram TLS (DTLS) protocols. The requirements are intended to improve the security of products by enabling their evaluation.

Issuer of digital certificates Cryptographic network protocol, based on TLS, which provides communications security for datagram protocols Cryptographic network protocol for providing communications security over a TCP/IP network

The Target of Evaluation (TOE) in this Package is a product which acts as a TLS client or server, or both. This Package describes the security functionality of TLS in terms of . The contents of this Package must be appropriately combined with a PP or PP-Module". When this Package is instantiated by a PP or PP-Module, the Package must include selection-based requirements in accordance with the selections or assignments indicated in the PP or PP-Module. These may be expanded by the the ST author. The PP or PP-Module which instantiates this Package must typically include the following components in order to satisfy dependencies of this Package. It is the responsibility of the PP or PP-Module author who instantiates this Package to ensure that dependence on these components is satisfied: FCS_CKM.2 To support TLS ciphersuites that use RSA, DHE or ECDHE for key exchange, the PP or PP-Module must include FCS_CKM.2 and specify the corresponding algorithm. FCS_COP.1 To support TLS ciphersuites that use AES for encryption/decryption, the PP or PP-module must include FCS_COP.1 (iterating as needed) and specify AES with corresponding key sizes and modes. To support TLS ciphersuites that use SHA for hashing, the PP or PP-Module must include FCS_COP.1 (iterating as needed) and specify SHA with corresponding digest sizes. FCS_RBG_EXT.1 To support random bit generation needed for the TLS handshake, the PP or PP-Module must include FCS_RBG_EXT.1. FIA_X509_EXT.1 To support validation of certificates needed during TLS connection setup, the PP or PP-Module must include FIA_X509_EXT.1. FIA_X509_EXT.2 To support the use of X509 certificates for authentication in TLS connection setup, the PP or PP-Module must include FIA_X509_EXT.2. An ST must identify the applicable version of the PP or PP-Module and this Package in its conformance claims.

If TLS as a client is selected, then the ST must include the requirements from FCS_TLSC_EXT.1. If TLS as a server is selected, then the ST must include the requirements from FCS_TLSS_EXT.1. If DTLS as a client is selected, then the ST must include the requirements from FCS_DTLSC_EXT.1. If DTLS as a server is selected, then the ST must include the requirements from FCS_DTLSS_EXT.1. The evaluator shall ensure that the selections indicated in the ST are consistent with selections in the dependent components. The Security Target 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 ECDHE or DHE cipher suites are selected, then FCS_TLSC_EXT.5 is required. If mutual authentication is selected, then the ST must additionally include the requirements from FCS_TLSC_EXT.2. If the TOE implements mutual authentication, this selection must be made. If session renegotiation is selected, then the ST must additionally include the requirements from FCS_TLSC_EXT.4. If the TOE implements session renegotiation, this selection must be made. 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. 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. The evaluator shall also perform the following tests: 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). The goal of the following test is to verify that the TOE accepts only certificates with appropriate values in the extendedKeyUsage extension, and implicitly that the TOE correctly parses the extendedKeyUsage extension as part of X.509v3 server certificate validation. The evaluator shall attempt to establish the connection using a server with a server certificate that contains the Server Authentication purpose in the extendedKeyUsage extension and verify that a connection is established. The evaluator shall repeat this test using a different, but otherwise valid and trusted, certificate that lacks the Server Authentication purpose in the extendedKeyUsage extension and ensure that a connection is not established. Ideally, the two certificates should be similar in structure, the types of identifiers used, and the chain of trust. The evaluator shall send a server certificate in the TLS connection that 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 product disconnects after receiving the server’s Certificate handshake message. The evaluator shall configure the server to select the TLS_NULL_WITH_NULL_NULL cipher suite and verify that the client denies the connection. The evaluator shall perform the following modifications to the traffic: Change the TLS version selected by the server in the Server Hello to an undefined TLS version (for example 1.5 represented by the two bytes 03 06) and verify that the client rejects the connection. Change the TLS version selected by the server 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 client rejects the connection. [conditional] 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 client does not complete the handshake and no application data flows. 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. [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 client does not complete the handshake and no application data flows. This test does not apply to cipher suites using RSA key exchange. If a TOE only supports RSA key exchange in conjunction with TLS, then this test shall be omitted. Modify a byte in the Server Finished handshake message, and verify that the client does not complete the handshake and no application data flows. Send a message consisting of random bytes 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 message must still have a valid 5-byte record header in order to ensure the message will be parsed as TLS. 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 product 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 for the purposes of backwards compatibility is optional. 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. The evaluator shall ensure that the TSS describes the client’s method of establishing all reference identifiers from the 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 product. The evaluator shall verify that the AGD guidance includes instructions for setting the reference identifier to be used for the purposes of certificate validation in TLS. The evaluator shall configure the reference identifier according to the AGD guidance and perform the following tests during a TLS connection. If the TOE supports certificate pinning, all pinned certificates must be removed before performing Tests 1 through 6. A pinned certificate must be added prior to performing Test 7. 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. Note that 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. 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. [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. 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. The evaluator shall perform the following wildcard tests with each supported type of reference identifier. The support for wildcards is intended to be optional. If wildcards are supported, the first, second, and third tests below shall be executed. If wildcards are not supported, then the fourth test below shall be executed. [conditional]: If wildcards are supported, 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. [conditional]: If wildcards are supported, the evaluator shall present a server certificate containing a wildcard in the left-most label but not preceding the public suffix (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. [conditional]: If wildcards are supported, the evaluator shall present a server certificate containing a wildcard in the left-most label immediately preceding the public suffix (e.g. *.com). The evaluator shall configure the reference identifier with a single left-most label (e.g. foo.com) and verify that the connection fails. The evaluator shall configure the reference identifier with two left-most labels (e.g. bar.foo.com) and verify that the connection fails. [conditional]: If wildcards are not supported, 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 fails. [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. [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. 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 as defined in any PP or PP-Module which instantiates this Package. The selection that permits override for invalid certificates should be interpreted as follows: explicit administrator or user action is needed to authorize the override, on a per-certificate basis override may be sought or granted at any time, though this typically occurs when an invalid certificate is presented during connection setup override decisions may be stored and then consulted later, to permit connections using these otherwise-invalid certificates to establish trusted channels without user or administrator action As indicated in , note that a PP author may instantiate this SFR using only the first selection, preventing the ability to allow overrides. If the selection for authorizing override of invalid certificates is made, then the evaluator shall ensure that the TSS includes a description of how and when user or administrator authorization is obtained. The evaluator shall also ensure that the TSS describes any mechanism for storing such authorizations, such that future presentation of such otherwise-invalid certificates permits establishment of a trusted channel without user or administrator action. The evaluator shall demonstrate that using an invalid certificate (unless excepted) results in the function failing as follows, unless excepted: The evaluator will perform the following subtests: The evaluator will demonstrate that a server using a certificate with a valid certification path successfully connects. The evaluator will modify the certificate chain used by the server in test to be invalid and demonstrate that a server using a certificate without a valid certification path to a trust store element of the TOE results in an authentication failure. [conditional]: If the TOE trust store can be managed, the evaluator will modify the trust store element used in to be untrusted and demonstrate that a connection attempt from the same server used in results in an authentication failure. The evaluator shall demonstrate that a server using a certificate which has been revoked results in an authentication failure. The evaluator shall demonstrate that a server using a certificate which has passed its expiration date results in an authentication failure. The evaluator shall demonstrate that a server using a certificate which does not have a valid identifier results in an authentication failure. The use of X.509v3 certificates for TLS is addressed in FIA_X509_EXT.2.1. This requirement adds that a client must be capable of presenting a certificate to a TLS server for TLS mutual authentication. Presenting a certificate is not mandatory in all circumstances: it may depend on the configuration of the client or other factors. 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. The evaluator shall also ensure that the TSS describes any factors beyond configuration that are necessary in order for the client to engage in mutual authentication using X.509v3 certificates. The evaluator shall ensure that the AGD guidance includes any instructions necessary to configure the TOE to perform mutual authentication. The evaluator also shall verify that the AGD guidance required per FIA_X509_EXT.2.1 includes instructions for configuring the client-side certificates for TLS mutual authentication. The evaluator shall also perform the following tests: The evaluator shall establish a connection to a 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. The evaluator shall establish a connection to a 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) message. This requirement limits the hashing algorithms supported for the purpose of digital signature verification by the client and limits the server to the supported hashes for the purpose of digital signature generation by the server. The signature_algorithms extension is only supported by TLS 1.2. The evaluator shall verify that TSS describes the signature_algorithm extension and whether the required behavior is performed by default or may be configured. If the TSS indicates that the signature_algorithm extension must be configured to meet the requirement, the evaluator shall verify that AGD guidance includes configuration of the signature_algorithm extension. The evaluator shall also perform the following tests: The evaluator shall configure the server to send a certificate in the TLS connection that is not supported according to the Client's HashAlgorithm enumeration within the signature_algorithms extension (for example, send a certificate with a SHA-1 signature). The evaluator shall verify that the product disconnects after receiving the server's Certificate handshake message. [conditional] If the client supports a DHE or ECDHE cipher suite, the evaluator shall configure the server to send a Key Exchange handshake message including a signature not supported according to the client's HashAlgorithm enumeration (for example, the server signed the Key Exchange parameters using a SHA-1 signature). The evaluator shall verify that the product disconnects after receiving the server's Key Exchange handshake message. RFC 5746 defines an extension to TLS that binds renegotiation handshakes to the cryptography in the original handshake. Per RFC 5746, the client may present either the "renegotiation_info" extension or the signaling cipher suite value TLS_EMPTY_RENEGOTIATION_INFO_SCSV in the initial ClientHello message to indicate support for renegotiation. (A signaling cipher suite value (SCSV) is presented as a cipher suite, but its only purpose is to provide other information and not to advertise support for a cipher suite.) The TLS_EMPTY_RENEGOTIATION_INFO_SCSV signaling cipher suite value exists as an alternative to presenting the "renegotation_info" extension so that TLS server implementations that immediately terminate the connection when they encounter any extension they do not understand can still proceed with a connection. The client may still choose to reject the connection later, if it insists upon renegotiation support and the server does not support it. In any case, RFC 5746 states that during any renegotiation the "renegotiation_info" extension must be presented by the peer initiating renegotiation, and so the client must support use of this extension. The evaluator shall perform the following tests: The evaluator shall use a network packet analyzer/sniffer to capture the traffic between the two TLS endpoints. The evaluator shall verify that either the “renegotiation_info” field or the SCSV cipher suite is included in the ClientHello message during the initial handshake. The evaluator shall verify the Client’s handling of ServerHello messages received during the initial handshake that include the “renegotiation_info” extension. The evaluator shall modify the length portion of this field in the ServerHello message to be non-zero and verify that the client sends a failure and terminates the connection. The evaluator shall verify that a properly formatted field results in a successful TLS connection. The evaluator shall verify that ServerHello messages received during secure renegotiation contain the “renegotiation_info” extension. The evaluator shall modify either the “client_verify_data” or “server_verify_data” value and verify that the client terminates the connection. If an elliptic curve or Diffie-Hellman ciphersuite is selected in FCS_TLSC_EXT.1.1 or FCS_DTLSC_EXT.1.1, then FCS_TLSC_EXT.5 shall be included in the ST. This requirement does not limit the elliptic curves the client may propose for authentication and key agreement. The Supported Groups Extension was previously referred to as the Supported Elliptic Curves Extension and is described in RFC 7919. The evaluator shall verify that TSS describes the Supported Groups Extension. The evaluator shall also perform the following test: The evaluator shall configure a server to perform key exchange using each of the TOE’s supported curves and/or groups. The evaluator shall verify that the TOE successfully connects to the server. 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 session renegotiation is selected, then the ST must additionally include the requirements from FCS_TLSS_EXT.4. If the TOE implements session renegotiation, this selection must be made. If the TOE does not support session resumption or session tickets, select 'no session resumption or session tickets’. If the TOE supports session resumption based on session IDs according to RFC 4346 (TLS1.1) or RFC 5246 (TLS1.2), select 'session resumption based on session IDs according to RFC 4346 (TLS1.1) or RFC 5246 (TLS1.2)'. If the TOE supports session resumption based on session tickets according to RFC 5077, select 'session resumption based on session tickets according to RFC 5077'. If session renegotiation is selected, then the ST must additionally include the requirements from FCS_TLSS_EXT.4. If the TOE implements session renegotiation, this selection must be made. 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. 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. The evaluator shall also perform the following tests: 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). The evaluator shall send a Client Hello to the server with a list of cipher suites that does not contain any of the cipher suites 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 cipher suite and verify that the server denies the connection. If RSA key exchange is used in one of the selected ciphersuites, the evaluator shall use a client to send a properly constructed Key Exchange message with a modified EncryptedPreMasterSecret field during the TLS handshake. The evaluator shall verify that the handshake is not completed successfully and no application data flows. The evaluator shall perform the following modifications to the traffic: Modify a byte in the data of the client's Finished handshake message, and verify that the server rejects the connection and does not send any application data. 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 Client Hello with the session identifier from the previous incomplete session, and verify that the server does not resume the session. 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): Test 4.3i [conditional]: If the TOE does not support session resumption based on session IDs according to RFC4346 (TLS1.1) or RFC5246 (TLS1.2) or session tickets according to RFC5077, the evaluator shall perform the following test: The evaluator shall send a Client Hello with a zero-length session identifier and with a SessionTicket extension containing a zero-length ticket. The evaluator shall verify the server does not send a NewSessionTicket handshake message (at any point in the handshake). The evaluator shall verify the Server Hello message contains a zero-length session identifier or passes the following steps: Note: The following steps are only performed if the ServerHello message contains a non-zero length SessionID. The evaluator shall complete the TLS handshake and capture the SessionID from the ServerHello. The evaluator shall send a ClientHello containing the SessionID captured in . This can be done by keeping the TLS session in open or start a new TLS session using the SessionID captured in step . The evaluator shall verify the TOE (1) implicitly rejects the SessionID by sending a ServerHello containing a different SessionID and by performing a full handshake (as shown in Figure 1 of RFC 4346 or RFC 5246), or (2) terminates the connection in some way that prevents the flow of application data. Test 4.3ii [conditional]: If the TOE supports session resumption using session IDs according to RFC4346 (TLS1.1) or RFC5246 (TLS1.2), the evaluator shall carry out the following steps (note that for each of these tests, it is not necessary to perform the test case for each supported version of TLS): a) The evaluator shall conduct a successful handshake and capture the TOE-generated session ID in the Server Hello message. The evaluator shall then initiate a new TLS connection and send the previously captured session ID to show that the TOE resumed the previous session by responding with ServerHello containing the same SessionID immediately followed by ChangeCipherSpec and Finished messages (as shown in Figure 2 of RFC 4346 or RFC 5246). b) The evaluator shall initiate a handshake and capture the TOE-generated session ID in the Server Hello message. The evaluator shall then, within the same handshake, generate or force an unencrypted fatal Alert message immediately before the client would otherwise send its ChangeCipherSpec message thereby disrupting the handshake. The evaluator shall then initiate a new Client Hello using the previously captured session ID, and verify that the server (1) implicitly rejects the session ID by sending a ServerHello containing a different SessionID and performing a full handshake (as shown in figure 1 of RFC 4346 or RFC 5246), or (2) terminates the connection in some way that prevents the flow of application data. Test 4.3iii [conditional]: If the TOE supports session tickets according to RFC5077, the evaluator shall carry out the following steps (note that for each of these tests, it is not necessary to perform the test case for each supported version of TLS): a) The evaluator shall permit a successful TLS handshake to occur in which a session ticket is exchanged with the non-TOE client. The evaluator shall then attempt to correctly reuse the previous session by sending the session ticket in the ClientHello. The evaluator shall confirm that the TOE responds with a ServerHello with an empty SessionTicket extension, NewSessionTicket, ChangeCipherSpec and Finished messages (as seen in figure 2 of RFC 5077). b) The evaluator shall permit a successful TLS handshake to occur in which a session ticket is exchanged with the non-TOE client. The evaluator will then modify the session ticket and send it as part of a new Client Hello message. The evaluator shall confirm that the TOE either (1) implicitly rejects the session ticket by performing a full handshake (as shown in figure 3 or 4 of RFC 5077), or (2) terminates the connection in some way that prevents the flow of application data. All SSL versions are denied. Any TLS version not selected in FCS_TLSS_EXT.1.1 should be selected here. The evaluator shall verify that the TSS contains a description of the denial of old SSL and TLS versions consistent relative to selections in FCS_TLSS_EXT.1.2. The evaluator shall verify that the AGD guidance includes any configuration necessary to meet this requirement. The evaluator shall send a Client Hello requesting a connection with version SSL 2.0 and verify that the server denies the connection. The evaluator shall repeat this test with SSL 3.0 and TLS 1.0, and TLS 1.1 if it is selected. If the ST lists an RSA cipher suite in FCS_TLSS_EXT.1.1, the ST must include the RSA selection in the requirement. If the ST lists a DHE cipher suite in FCS_TLSS_EXT.1.1, the ST must include either the Diffie-Hellman selection for parameters of a certain size, or for particular Diffie-Hellman groups. The selection for "Diffie-Hellman parameters" refers to the method defined by RFC 5246 (and RFC 4346) Section 7.4.3 where the server provides Diffie-Hellman parameters to the client. The Supported Groups extension defined in RFC 7919 identifies particular Diffie-Hellman groups, which are listed in the following selection. Regarding this distinction, it is acceptable to use Diffie-Hellman group 14 with TLS (there is currently no ability to negotiate group 14 using the Supported Groups extension, but it could be used with the "Diffie-Hellman parameters" selection). As in RFC 7919, the terms "DHE" and "FFDHE" are both used to refer to the finite-field-based Diffie-Hellman ephemeral key exchange mechanism, distinct from elliptic-curve-based Diffie Hellman ephemeral key exchange (ECDHE). If the ST lists an ECDHE cipher suite in FCS_TLSS_EXT.1.1, the ST must include the selection for ECDHE using elliptic curves in the requirement. The evaluator shall verify that the TSS describes the key agreement parameters of the server's Key Exchange message. The evaluator shall verify that any configuration guidance necessary to meet the requirement must be contained in the AGD guidance. The evaluator shall conduct the following tests. The testing can be carried out manually with a packet analyzer or with an automated framework that similarly captures such empirical evidence. Note that this testing can be accomplished in conjunction with other testing activities. For each of the following tests, determining that the size matches the expected size is sufficient. [conditional] If RSA-based key establishment is selected, the evaluator shall configure the TOE with a certificate containing a supported RSA size and attempt a connection. The evaluator shall verify that the size used matches that which is configured and that the connection is successfully established. The evaluator shall repeat this test for each supported size of RSA-based key establishment. [conditional] If finite-field (i.e. non-EC) Diffie-Hellman ciphers are selected, the evaluator shall attempt a connection using a Diffie-Hellman key exchange with a supported parameter size or supported group. The evaluator shall verify that the key agreement parameters in the Key Exchange message are the ones configured. The evaluator shall repeat this test for each supported parameter size or group. [conditional] If ECDHE ciphers are selected, the evaluator shall attempt a connection using an ECDHE ciphersuite with a supported curve. The evaluator shall verify that the key agreement parameters in the Key Exchange message are the ones configured. The evaluator shall repeat this test for each supported elliptic curve. The use of X.509v3 certificates for TLS is addressed in FIA_X509_EXT.2.1 This requirement adds that this use must include support for client-side certificates for TLS mutual authentication. Validity is determined by the 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. 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. The evaluator shall verify that the AGD guidance required per FIA_X509_EXT.2.1 includes instructions for configuring the client-side certificates for TLS mutual authentication. The evaluator shall ensure that the AGD guidance includes instructions for configuring the server to require mutual authentication of clients using these certificates. The evaluator shall use TLS as a function to verify that the validation rules in FIA_X509_EXT.1.1 are adhered to and shall perform the following tests. The evaluator shall apply the AGD guidance to configure the server to require TLS mutual authentication of clients for the following tests, unless overridden by instructions in the test activity: The evaluator shall configure the server to send a certificate request to the client. The client shall send a certificate_list structure which has a length of zero. The evaluator shall verify that the handshake is not finished successfully and no application data flows. The evaluator shall configure the server to send a certificate request to the client. The client shall send no client certificate message, and instead send a client key exchange message in an attempt to continue the handshake. The evaluator shall verify that the handshake is not finished successfully and no application data flows. 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 handshake is not finished successfully and no application data flows. 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. The aim of this test is to check the response of the server when it receives a client identity certificate that is signed by an impostor CA (either Root CA or intermediate CA). To carry out this test the evaluator shall configure the client to send a client identity certificate with an issuer field that identifies a CA recognised by the TOE as a trusted CA, but where the key used for the signature on the client certificate does not in fact correspond to the CA certificate trusted by the TOE (meaning that the client certificate is invalid because its certification path does not in fact terminate in the claimed CA certificate). The evaluator shall verify that the attempted connection is denied. 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. 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. 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 may be passed to a directory server for comparison. In the latter case, the matching itself may be performed outside the TOE. If the product implements mutual authentication, the evaluator shall verify that the TSS describes how the DN and SAN in the certificate is compared to the expected identifier. If the DN is not compared automatically to the domain name, IP address, username, or email address, the evaluator shall ensure that the AGD guidance includes configuration of the expected identifier or the directory server for the connection. The evaluator shall send a client certificate with an identifier that does not match any of the expected identifiers and verify that the server denies the connection. The matching itself might be performed outside the TOE (e.g. when passing the certificate on to a directory server for comparison). This requirement limits the hashing algorithms supported for the purpose of digital signature verification by the server and limits the client to the supported hashes for the purpose of digital signature generation by the client. The supported_signature_algorithms is only supported by TLS 1.2. The evaluator shall verify that TSS describes the supported_signature_algorithms field of the Certificate Request and whether the required behavior is performed by default or may be configured. If the TSS indicates that the supported_signature_algorithms field must be configured to meet the requirement, the evaluator shall verify that AGD guidance includes configuration of the supported_signature_algorithms field. The evaluator shall also perform the following test: The evaluator shall configure the server to send the signature_algorithms extension in the Certificate Request message indicating that the hash algorithm used by the client’s certificate is not supported. The evaluator shall attempt a connection using that client certificate and verify that the server denies the client’s connection. RFC 5746 defines an extension to TLS that binds renegotiation handshakes to the cryptography in the original handshake. The following tests require connection with a client that supports secure renegotiation and the "renegotiation_info" extension. The evaluator shall use a network packet analyzer/sniffer to capture the traffic between the two TLS endpoints. The evaluator shall verify that the “renegotiation_info” field is included in the ServerHello message. The evaluator shall modify the length portion of the field in the ClientHello message in the initial handshake to be non-zero and verify that the server sends a failure and terminates the connection. The evaluator shall verify that a properly formatted field results in a successful TLS connection. The evaluator shall modify the "client_verify_data" or "server_verify_data" value in the ClientHello message received during secure renegotiation and verify that the server terminates the connection. If any ECDHE or DHE cipher suites are selected, then FCS_TLSC_EXT.5 is required. If mutual authentication is selected, then the ST must additionally include the requirements from FCS_DTLSC_EXT.2. If the TOE implements mutual authentication, this selection must be made. Differences between DTLS 1.2 and TLS 1.2 are outlined in RFC 6347; otherwise the protocols are the same. All application notes listed for FCS_TLSC_EXT.1.1 that are relevant to DTLS apply to this requirement. The evaluator shall perform the evaluation activities listed for FCS_TLSC_EXT.1.1, but ensuring that DTLS (and not TLS) is used in each evaluation activity. For tests which involve version numbers, note that in DTLS the on-the-wire representation is the 1's complement of the corresponding textual DTLS version numbers. This is described in Section 4.1 of RFC 6347 and RFC 4347. For example, DTLS 1.0 is represented by the bytes 0xfe 0xff, while the undefined DTLS 1.4 would be represented by the bytes 0xfe 0xfb. All application notes listed for FCS_TLSC_EXT.1.2 that are relevant to DTLS apply to this requirement. The evaluator shall perform the evaluation activities listed for FCS_TLSC_EXT.1.2. All application notes listed for FCS_TLSC_EXT.1.3 that are relevant to DTLS apply to this requirement. The evaluator shall perform the evaluation activities listed for FCS_TLSC_EXT.1.3. The evaluator shall verify that the TSS describes the actions that take place if a message received from the DTLS Server fails the MAC integrity check. The evaluator shall establish a connection using a server. The evaluator will then modify at least one byte in a record message, and verify that the client discards the record or terminates the DTLS session. All application notes listed for FCS_TLSC_EXT.2.1 that are relevant to DTLS apply to this requirement. The evaluator shall perform the evaluation activities listed for FCS_TLSC_EXT.2.1. If mutual authentication is selected, then the ST must additionally include the requirements from FCS_DTLSS_EXT.2. If the TOE implements mutual authentication, this selection must be made. All application notes listed for FCS_TLSS_EXT.1.1 that are relevant to DTLS apply to this requirement. The evaluator shall perform the evaluation activities listed for FCS_TLSS_EXT.1.1, but ensuring that DTLS (and not TLS) is used in each stage of the evaluation activities. For tests which involve version numbers, note that in DTLS the on-the-wire representation is the 1's complement of the corresponding textual DTLS version numbers. This is described in Section 4.1 of RFC 6347 and RFC 4347. For example, DTLS 1.0 is represented by the bytes 0xfe 0xff, while the undefined DTLS 1.4 would be represented by the bytes 0xfe 0xfb. Any specific DTLS version not selected in FCS_DTLSS_EXT.1.1 should be assigned here. This version of the PP does not require the server to deny DTLS 1.0, and if the TOE supports DTLS 1.0 then "none" can be assigned. In a future version of this PP, DTLS 1.0 will be required to be denied. The following evaluation activities shall be conducted unless "none" is assigned. The evaluator shall verify that the TSS contains a description of the denial of old DTLS versions consistent relative to selections in FCS_DTLSS_EXT.1.2. The evaluator shall verify that the AGD guidance includes any configuration necessary to meet this requirement. The evaluator shall send a Client Hello requesting a connection with each version of DTLS specified in the selection and verify that the server denies the connection. The process to validate the IP address of a DTLS client is specified in section 4.2.1 of RFC 6347 (DTLS 1.2) and RFC 4347 (DTLS 1.0). The server validates the DTLS client during Connection Establishment (Handshaking) and prior to sending a Server Hello message. After receiving a ClientHello, the DTLS Server sends a HelloVerifyRequest along with a cookie. The cookie is a signed message using a keyed hash function. The DTLS Client then sends another ClientHello with the cookie attached. If the DTLS server successfully verifies the signed cookie, the Client is not using a spoofed IP address. The evaluator shall verify that the TSS describes how the DTLS Client IP address is validated prior to issuing a ServerHello message. Modify at least one byte in the cookie from the Server's HelloVerifyRequest message, and verify that the Server rejects the Client's handshake message. If the ST lists an RSA cipher suite in FCS_DTLSS_EXT.1.1, the ST must include the RSA selection in the requirement. If the ST lists a DHE cipher suite in FCS_DTLSS_EXT.1.1, the ST must include either the Diffie-Hellman selection for parameters of a certain size, or for particular Diffie-Hellman groups. If the ST lists an ECDHE cipher suite in FCS_DTLSS_EXT.1.1, the ST must include the NIST curves selection in the requirement. The evaluator shall perform the evaluation activities listed for FCS_TLSS_EXT.1.3. The evaluator shall verify that the TSS describes the actions that take place if a message received from the DTLS client fails the MAC integrity check. The evaluator shall establish a connection using a client. The evaluator will then modify at least one byte in a record message, and verify that the server discards the record or terminates the DTLS session. All application notes listed for FCS_TLSS_EXT.2.1 that are relevant to DTLS apply to this requirement. The evaluator shall perform the evaluation activities listed for FCS_TLSS_EXT.2.1. All application notes listed for FCS_TLSS_EXT.2.2 that are relevant to DTLS apply to this requirement. The evaluator shall perform the evaluation activities listed for FCS_TLSS_EXT.2.2. All application notes listed for FCS_TLSS_EXT.2.3 that are relevant to DTLS apply to this requirement. The evaluator shall perform the evaluation activities listed for FCS_TLSS_EXT.2.3.

There are currently no Optional Requirements in this Package. As indicated in the introduction to this Package, this appendix lists requirements that are activated based on selections made in the PP/PP-Module/ST or in other portions of this Package itself. This appendix includes requirements that specify security functionality which also addresses threats. The requirements are not currently mandated in the body of this Package as they describe security functionality not yet widely-available in commercial technology. However, these requirements may be included in the ST such that the product is still conformant to this Package, and it is expected that they be included as soon as possible. CC Common Criteria for Information Technology Security Evaluation - Part 1: Introduction and General Model, CCMB-2017-04-001, Version 3.1 Revision 5, April 2017. Part 2: Security Functional Components, CCMB-2017-04-002, Version 3.1 Revision 5, April 2017. Part 3: Security Assurance Components, CCMB-2017-04-003, Version 3.1 Revision 5, April 2017.