Functional Package for Transport Layer Security (TLS)

NIAP Logo
Version: 1.1
2019-03-01
National Information Assurance Partnership

Revision History

VersionDateComment
1.02018-12-17First publication
1.12019-03-01Clarifications regarding override for invalid certificates, renegotation_info extension, DTLS versions, and named Diffie-Hellman groups in DTLS contexts

Contents

1Introduction1.1Overview1.2Terms1.2.1Common Criteria Terms1.2.2Technical Terms1.3Format of this Document1.4Compliant Targets of Evaluation2Conformance Claims3Security Functional Requirements3.1Cryptographic Support (FCS)Appendix A - Optional RequirementsA.1Strictly Optional Requirements A.2Objective Requirements A.2.1Cryptographic Support (FCS)A.3Implementation-based Requirements Appendix B - Selection-based Requirements B.1Cryptographic Support (FCS)Appendix C - ReferencesAppendix D - Acronyms

1 Introduction

1.1 Overview

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.

1.2 Terms

The following sections list Common Criteria and technology terms used in this document.

1.2.1 Common Criteria Terms

Assurance
Grounds for confidence that a TOE meets the SFRs [CC].
Base Protection Profile (Base-PP)
Protection Profile used as a basis to build a PP-Configuration.
Common Criteria (CC)
Common Criteria for Information Technology Security Evaluation (International Standard ISO/IEC 15408).
Common Criteria Testing Laboratory
 Within the context of the Common Criteria Evaluation and Validation Scheme (CCEVS), an IT security evaluation facility, accredited by the National Voluntary Laboratory Accreditation Program (NVLAP) and approved by the NIAP Validation Body to conduct Common Criteria-based evaluations.
Common Evaluation Methodology (CEM)
Common Evaluation Methodology for Information Technology Security Evaluation.
Distributed TOE
A TOE composed of multiple components operating as a logical whole.
Operational Environment (OE)
Hardware and software that are outside the TOE boundary that support the TOE functionality and security policy.
Protection Profile (PP)
An implementation-independent set of security requirements for a category of products.
Protection Profile Configuration (PP-Configuration)
A comprehensive set of security requirements for a product type that consists of at least one Base-PP and at least one PP-Module.
Protection Profile Module (PP-Module)
An implementation-independent statement of security needs for a TOE type complementary to one or more Base Protection Profiles.
Security Assurance Requirement (SAR)
A requirement to assure the security of the TOE.
Security Functional Requirement (SFR)
A requirement for security enforcement by the TOE.
Security Target (ST)
A set of implementation-dependent security requirements for a specific product.
TOE Security Functionality (TSF)
The security functionality of the product under evaluation.
TOE Summary Specification (TSS)
A description of how a TOE satisfies the SFRs in an ST.
Target of Evaluation (TOE)
The product under evaluation.

1.2.2 Technical Terms

Certificate Authority (CA)
 Issuer of digital certificates
Datagram Transport Layer Security (DTLS)
 Cryptographic network protocol, based on TLS, which provides communications security for datagram protocols
Transport Layer Security (TLS)
 Cryptographic network protocol for providing communications security over a TCP/IP network

1.3 Format of this Document

Section 3 Security Functional Requirements contains baseline requirements which must be implemented in the product and included in any PP/PP-Module/ST that claims conformance to this Package. There are three other types of requirements that can be included in a PP/PP-Module/ST claiming conformance to this Package:

1.4 Compliant Targets of Evaluation

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 [CC].

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:
ComponentExplanation
FCS_CKM.2To 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.1To 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.1To 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.2To 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.

2 Conformance Claims

Conformance Statement
An ST must claim exact conformance to this Package, as defined in the CC and CEM addenda for Exact Conformance, Selection-Based SFRs, and Optional SFRs (dated May 2017).
CC Conformance Claims
This Package is conformant to Parts 2 (extended) and 3 (conformant) of Common Criteria Version 3.1, Revision 5.
PP Claim
This Package does not claim conformance to any Protection Profile.
Package Claim
This Package does not claim conformance to any packages.
Conformance Statement
This Package serves to provide Protection Profiles with additional SFRs and associated Evaluation Activities specific to TLS clients and servers.

This Package conforms to Common Criteria [CC] for Information Technology Security Evaluation, Version 3.1, Revision 5. It is CC Part 2 extended conformant.

In accordance with CC Part 1, dependencies are not included when they are addressed by other SFRs. The evaluation activities provide adequate proof that any dependencies are also satisfied.

3 Security Functional Requirements

This chapter describes the security requirements which have to be fulfilled by the product under evaluation. Those requirements comprise functional components from Part 2 of [CC]. The following conventions are used for the completion of operations:

3.1 Cryptographic Support (FCS)

FCS_TLS_EXT.1 TLS Protocol

The product shall implement [selection: ].
Application Note: 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.
Evaluation Activities
FCS_TLS_EXT.1:
Guidance
The evaluator shall ensure that the selections indicated in the ST are consistent with selections in the dependent components.

Appendix A - Optional Requirements

As indicated in the introduction to this Package, the baseline requirements (those that must be performed by the TOE) are contained in the body of this Package. This appendix contains three other types of optional requirements that may be included in the ST, but are not required in order to conform to this Package. However, applied modules, packages and/or use cases may refine specific requirements as mandatory.

The first type ( A.1 Strictly Optional Requirements ) are strictly optional requirements that are independent of the TOE implementing any function. If the TOE fulfills any of these requirements or supports a certain functionality, the vendor is encouraged to included the SFRs in the ST, but are not required in order to conform to this Package.

The second type ( A.2 Objective Requirements ) are objective requirements that describe security functionality not yet widely available in commercial technology. The requirements are not currently mandated in the body of this Package, but will be included in the baseline requirements in future versions of this Package. Adoption by vendors is encouraged and expected as soon as possible.

The third type ( A.3 Implementation-based Requirements ) are dependent on the TOE implementing a particular function. If the TOE fulfills any of these requirements, the vendor must either add the related SFR or disable the functionality for the evaluated configuration.

A.1 Strictly Optional Requirements

This Package does not define any Strictly Optional requirements.

A.2 Objective Requirements

A.2.1 Cryptographic Support (FCS)

FCS_TLSC_EXT.3 TLS Client Support for Signature Algorithms Extension

The product shall present the signature_algorithms extension in the Client Hello with the supported_signature_algorithms value containing the following hash algorithms: [selection: SHA256, SHA384, SHA512] and no other hash algorithms.
Application Note: 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.
Evaluation Activities
FCS_TLSC_EXT.3:
TSS
The evaluator shall verify that TSS describes the signature_algorithm extension and whether the required behavior is performed by default or may be configured.
Guidance
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.
Tests
The evaluator shall also perform the following tests:
  • Test 1: 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.
  • Test 2: [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.

FCS_TLSS_EXT.3 TLS Server Support for Signature Algorithms Extension

The product shall present the HashAlgorithm enumeration in supported_signature_algorithms in the Certificate Request with the following hash algorithms: [selection: SHA256, SHA384, SHA512] and no other hash algorithms.
Application Note: 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.
Evaluation Activities
FCS_TLSS_EXT.3:
TSS
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.
Guidance
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.
Tests
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.

A.3 Implementation-based Requirements

This Package does not define any Implementation-based requirements.

Appendix B - Selection-based Requirements

As indicated in the introduction to this Package, the baseline requirements (those that must be performed by the TOE or its underlying platform) are contained in the body of this Package. There are additional requirements based on selections in the body of the Package: if certain selections are made, then additional requirements below must be included.

B.1 Cryptographic Support (FCS)

FCS_TLSC_EXT.1 TLS Client Protocol

The inclusion of this selection-based component depends upon a selection in FCS_TLS_EXT.1.1.
The product shall implement TLS 1.2 (RFC 5246) and [selection: TLS 1.1 (RFC 4346), no earlier TLS versions] as a client that supports the cipher suites [selection:
  • TLS_RSA_WITH_AES_128_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_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_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
] and also supports functionality for [selection:
  • mutual authentication,
  • session renegotiation,
  • none
].
Application Note: The ST author should select the cipher suites that are supported, and must select at least one cipher suite. The cipher suites to be tested in the evaluated configuration are limited by this requirement. However, this requirement does not restrict the TOE's ability to propose additional cipher suites beyond the ones listed in this requirement in its Client Hello message. That is, the TOE may propose any cipher suite but the evaluation will only test cipher suites from the above list. It is necessary to limit the cipher suites that can be used in an evaluated configuration administratively on the server in the test environment. GCM cipher suites are preferred over CBC cipher suites, ECDHE preferred over RSA and DHE, and SHA256 or SHA384 over SHA.

TLS_RSA_WITH_AES_128_CBC_SHA is not required despite being mandated by RFC 5246.

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

If any 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 product shall verify that the presented identifier matches the reference identifier according to RFC 6125.
Application Note: The rules for verification of identity are described in Section 6 of RFC 6125. The reference identifier is established by the user (e.g. entering a URL into a web browser or clicking a link), by configuration (e.g. configuring the name of a mail server or authentication server), or by an application (e.g. a parameter of an API) depending on the 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 product shall not establish a trusted channel if the server certificate is invalid [selection:
  • with no exceptions,
  • except when override is authorized
].
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 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 Section 1.4 Compliant Targets of Evaluation, note that a PP author may instantiate this SFR using only the first selection, preventing the ability to allow overrides.
Evaluation Activities
FCS_TLSC_EXT.1:
TSS
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.
Tests
The evaluator shall also perform the following tests:
  • Test 1: The evaluator shall establish a TLS connection using each of the cipher suites specified by the requirement. This connection may be established as part of the establishment of a higher-level protocol, e.g., as part of an EAP session. It is sufficient to observe the successful negotiation of a cipher suite to satisfy the intent of the test; it is not necessary to examine the characteristics of the encrypted traffic in an attempt to discern the cipher suite being used (for example, that the cryptographic algorithm is 128-bit AES and not 256-bit AES).
  • Test 2: The 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.
  • Test 3: 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.
  • Test 4: The evaluator shall configure the server to select the TLS_NULL_WITH_NULL_NULL cipher suite and verify that the client denies the connection.
  • Test 5: The evaluator shall perform the following modifications to the traffic:
    • Test 5.1: 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.
    • Test 5.2: 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.
    • Test 5.3: [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.
    • Test 5.4: 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 5.5: [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.
    • Test 5.6: Modify a byte in the Server Finished handshake message, and verify that the client does not complete the handshake and no application data flows.
    • Test 5.7: 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.
TSS
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.
Guidance
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.
Tests
The evaluator shall configure the reference identifier according to the AGD guidance and perform the following tests during a TLS connection:
  • Test 1: The evaluator shall present a server certificate that 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.
  • 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 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.
    • Test 5.1: [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.
    • Test 5.2: [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.
    • Test 5.3: [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.
    • Test 5.4: [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.
  • 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.
TSS
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.
Tests
The evaluator shall demonstrate that using an invalid certificate (unless excepted) results in the function failing as follows, unless excepted:
  • Test 1: The evaluator shall demonstrate that a server using a certificate without a valid certification path results in an authentication failure. Using the administrative guidance, the evaluator shall then load the trusted CA certificate(s) needed to validate the server's certificate, and demonstrate that the connection succeeds. The evaluator then shall delete one of the CA certificates, and show that the connection fails.
  • Test 2: The evaluator shall demonstrate that a server using a certificate which has been revoked results in an authentication failure.
  • Test 3: The evaluator shall demonstrate that a server using a certificate which has passed its expiration date results in an authentication failure.
  • Test 4: The evaluator shall demonstrate that a server using a certificate which does not have a valid identifier results in an authentication failure.

FCS_TLSC_EXT.2 TLS Client Support for Mutual Authentication

The inclusion of this selection-based component depends upon a selection in FCS_TLSC_EXT.1.1.
The product shall support mutual authentication using X.509v3 certificates.
Application Note: The use of X.509v3 certificates for TLS is addressed in FIA_X509_EXT.2.1. This requirement adds that 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.
Evaluation Activities
FCS_TLSC_EXT.2:
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. 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.
Guidance
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.
Tests
The evaluator shall also perform the following tests:
  • Test 1: 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.
  • Test 2: 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.

FCS_TLSC_EXT.4 TLS Client Support for Renegotiation

The inclusion of this selection-based component depends upon a selection in FCS_TLS_EXT.1.1.
The product shall support secure renegotiation through use of the “renegotiation_info” TLS extension in accordance with RFC 5746.
Application Note: 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.
Evaluation Activities
FCS_TLSC_EXT.4:
Tests
The evaluator shall perform the following tests:
  • Test 1: 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.
  • Test 2: 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.
  • Test 3: 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.

FCS_TLSC_EXT.5 TLS Client Support for Supported Groups Extension

The inclusion of this selection-based component depends upon a selection in FCS_TLSC_EXT.1.1, FCS_DTLSC_EXT.1.1.
The product shall present the Supported Groups Extension in the Client Hello with the supported groups [selection:
  • secp256r1,
  • secp384r1,
  • secp521r1,
  • ffdhe2048(256),
  • ffdhe3072(257),
  • ffdhe4096(258),
  • ffdhe6144(259),
  • ffdhe8192(260)
].
Application Note: 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.
Evaluation Activities
FCS_TLSC_EXT.5:
TSS
The evaluator shall verify that TSS describes the Supported Groups Extension.
Tests
The evaluator shall also perform the following test:
  • Test 1: 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.

FCS_TLSS_EXT.1 TLS Server Protocol

The inclusion of this selection-based component depends upon a selection in FCS_TLS_EXT.1.1.
The product shall implement TLS 1.2 (RFC 5246) and [selection: TLS 1.1 (RFC 4346), no earlier TLS versions] as a server that supports the cipher suites [selection:
  • TLS_RSA_WITH_AES_128_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_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_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
] and no other cipher suites, and also supports functionality for [selection:
  • mutual authentication,
  • session renegotiation,
  • none
].
Application Note: The ST author should select the cipher suites that are supported, and must select at least one cipher suite. It is necessary to limit the cipher suites that can be used in an evaluated configuration administratively on the server in the test environment. If administrative steps need to be taken so that the cipher suites negotiated by the implementation are limited to those in this requirement, then the appropriate instructions need to be contained in the guidance. GCM cipher suites are preferred over CBC cipher suites, ECDHE preferred over RSA and DHE, and SHA256 or SHA384 over SHA.

TLS_RSA_WITH_AES_128_CBC_SHA is not required despite being mandated by RFC 5246.

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

If mutual authentication is selected, then the ST must additionally include the requirements from FCS_TLSS_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_TLSS_EXT.4. If the TOE implements session renegotiation, this selection must be made.
The product shall deny connections from clients requesting SSL 2.0, SSL 3.0, TLS 1.0 and [selection: TLS 1.1, none].
Application Note: All SSL versions are denied. Any TLS version not selected in FCS_TLSS_EXT.1.1 should be selected here.
The product shall perform key establishment for TLS using [selection:
  • RSA with size [selection: 2048 bits, 3072 bits, 4096 bits, no other sizes] ,
  • Diffie-Hellman parameters with size [selection: 2048 bits, 3072 bits, 4096 bits, 6144 bits, 8192 bits, no other sizes] ,
  • Diffie-Hellman groups [selection: ffdhe2048, ffdhe3072, ffdhe4096, ffdhe6144, ffdhe8192, no other groups] ,
  • ECDHE parameters using elliptic curves [selection: secp256r1, secp384r1, secp521r1] and no other curves ,
  • no other key establishment methods
].
Application Note: 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.
Evaluation Activities
FCS_TLSS_EXT.1:
TSS
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 TOE so that TLS conforms to the description in the TSS.
Tests
The evaluator shall also perform the following tests:
  • Test 1: The evaluator shall establish a TLS connection using each of the cipher suites specified by the requirement. This connection may be established as part of the establishment of a higher-level protocol, e.g., as part of an EAP session. It is sufficient to observe the successful negotiation of a cipher suite to satisfy the intent of the test; it is not necessary to examine the characteristics of the encrypted traffic in an attempt to discern the cipher suite being used (for example, that the cryptographic algorithm is 128-bit AES and not 256-bit AES).
  • Test 2: The evaluator shall 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.
  • Test 3: 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.
  • Test 4: The evaluator shall perform the following modifications to the traffic:
    • Test 4.1: Change the TLS version proposed by the client in the Client Hello to a non-supported TLS version (for example 1.3 represented by the two bytes 03 04) and verify that the server rejects the connection.
    • Test 4.2: 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.
    • Test 4.3: 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.
    • Test 4.4: Send a message consisting of random bytes from the client after the client has issued the ChangeCipherSpec message and verify that the server denies the connection.
TSS
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.
Guidance
The evaluator shall verify that the AGD guidance includes any configuration necessary to meet this requirement.
Tests
  • Test 1: 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.
TSS
The evaluator shall verify that the TSS describes the key agreement parameters of the server's Key Exchange message.
Guidance
The evaluator shall verify that any configuration guidance necessary to meet the requirement must be contained in the AGD guidance.
Tests
    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.
  • Test 1: [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.
  • Test 2: [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.
  • Test 3: [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.

FCS_TLSS_EXT.2 TLS Server Support for Mutual Authentication

The inclusion of this selection-based component depends upon a selection in FCS_TLSS_EXT.1.1.
The product shall support authentication of TLS clients using X.509v3 certificates.
The product shall not establish a trusted channel if the client certificate is invalid.
Application Note: The use of X.509v3 certificates for TLS is addressed in FIA_X509_EXT.2.1 This requirement adds that this use must include 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 product shall not establish a trusted channel if the Distinguished Name (DN) or Subject Alternative Name (SAN) contained in a certificate does not match one of the expected identifiers 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 may be passed to a directory server for comparison. In the latter case, the matching itself may be performed outside the TOE.
Evaluation Activities
FCS_TLSS_EXT.2:
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 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.
Tests
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:
  • Test 1: 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.
  • Test 2: 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.
  • Test 3: 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.
  • Test 4: 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 5: 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.
  • Test 6: 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 7: 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.
TSS
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.
Guidance
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.
Tests
  • Test 1: 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).

FCS_TLSS_EXT.4 TLS Server Support for Renegotiation

The inclusion of this selection-based component depends upon a selection in FCS_TLSS_EXT.1.1.
The product shall support the "renegotiation_info" TLS extension in accordance with RFC 5746.
The product shall include the renegotiation_info extension in ServerHello messages.
Application Note: RFC 5746 defines an extension to TLS that binds renegotiation handshakes to the cryptography in the original handshake.
Evaluation Activities
FCS_TLSS_EXT.4:
Tests
The following tests require connection with a client that supports secure renegotiation and the "renegotiation_info" extension.
  • Test 1: 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.
  • Test 2: 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.
  • Test 3: 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.

FCS_DTLSC_EXT.1 DTLS Client Protocol

The inclusion of this selection-based component depends upon a selection in FCS_TLSC_EXT.1.1.
The product shall implement DTLS 1.2 (RFC 6347) and [selection: DTLS 1.0 (RFC 4347), no earlier DTLS versions] as a client that supports the cipher suites [selection:
  • TLS_RSA_WITH_AES_128_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_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_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
] and also supports functionality for [selection:
  • mutual authentication,
  • none
].
Application Note: 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 product shall verify that the presented identifier matches the reference identifier according to RFC 6125.
Application Note: All application notes listed for FCS_TLSC_EXT.1.2 that are relevant to DTLS apply to this requirement.
The product shall not establish a trusted channel if the server certificate is invalid [selection: with no exceptions, except when override is authorized].
Application Note: All application notes listed for FCS_TLSC_EXT.1.3 that are relevant to DTLS apply to this requirement.
The product shall [selection: terminate the DTLS session, silently discard the record] if a message received contains an invalid MAC or if decryption fails in the case of GCM and other AEAD ciphersuites.
Evaluation Activities
FCS_DTLSC_EXT.1:
Tests
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.
Tests
The evaluator shall perform the evaluation activities listed for FCS_TLSC_EXT.1.2.
Tests
The evaluator shall perform the evaluation activities listed for FCS_TLSC_EXT.1.3.
TSS
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.
Tests
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.

FCS_DTLSC_EXT.2 DTLS Client Support for Mutual Authentication

The inclusion of this selection-based component depends upon a selection in FCS_DTLSC_EXT.1.1.
The product shall support mutual authentication using X.509v3 certificates.
Application Note: All application notes listed for FCS_TLSC_EXT.2.1 that are relevant to DTLS apply to this requirement.
Evaluation Activities
FCS_DTLSC_EXT.2:
Tests
The evaluator shall perform the evaluation activities listed for FCS_TLSC_EXT.2.1.

FCS_DTLSS_EXT.1 DTLS Server Protocol

The inclusion of this selection-based component depends upon a selection in FCS_TLS_EXT.1.1.
The product shall implement DTLS 1.2 (RFC 6347) and [selection: DTLS 1.0 (RFC 4347), no earlier DTLS versions] as a server that supports the ciphersuites [selection:
  • TLS_RSA_WITH_AES_128_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_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_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
] and no other cipher suites, and also supports functionality for [selection:
  • mutual authentication,
  • none
].
Application Note: 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 product shall deny connections from clients requesting [assignment: list of DTLS protocol versions].
Application Note: 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 product shall not proceed with a connection handshake attempt if the DTLS Client fails validation.
Application Note: 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 product shall perform key establishment for DTLS using [selection:
  • RSA with size [selection: 2048 bits, 3072 bits, 4096 bits, no other sizes] ,
  • Diffie-Hellman parameters with size [selection: 2048 bits, 3072 bits, 4096 bits, 6144 bits, 8192 bits, no other size] ,
  • Diffie-Hellman groups [selection: ffdhe2048, ffdhe3072, ffdhe4096, ffdhe6144, ffdhe8192, no other groups] ,
  • ECDHE parameters using elliptic curves [selection: secp256r1, secp384r1, secp521r1] and no other curves,
  • no other key establishment methods
].
Application Note: 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 product shall [selection: terminate the DTLS session, silently discard the record] if a message received contains an invalid MAC or if decryption fails in the case of GCM and other AEAD ciphersuites.
Evaluation Activities
FCS_DTLSS_EXT.1:
Tests
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.
The following evaluation activities shall be conducted unless "none" is assigned.

TSS
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.
Guidance
The evaluator shall verify that the AGD guidance includes any configuration necessary to meet this requirement.
Tests
  • Test 1: 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.
TSS
The evaluator shall verify that the TSS describes how the DTLS Client IP address is validated prior to issuing a ServerHello message.
Tests
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.
Tests
The evaluator shall perform the evaluation activities listed for FCS_TLSS_EXT.1.3.
TSS
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.
Tests
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.

FCS_DTLSS_EXT.2 DTLS Server Support for Mutual Authentication

The inclusion of this selection-based component depends upon a selection in FCS_DTLSS_EXT.1.1.
The product shall support mutual authentication of DTLS clients using X.509v3 certificates.
Application Note: All application notes listed for FCS_TLSS_EXT.2.1 that are relevant to DTLS apply to this requirement.
The product shall not establish a trusted channel if the client certificate is invalid.
Application Note: All application notes listed for FCS_TLSS_EXT.2.2 that are relevant to DTLS apply to this requirement.
The product shall not establish a trusted channel if the Distinguished Name (DN) or Subject Alternative Name (SAN) contained in a certificate does not match one of the expected identifiers for the client.
Application Note: All application notes listed for FCS_TLSS_EXT.2.3 that are relevant to DTLS apply to this requirement.
Evaluation Activities
FCS_DTLSS_EXT.2:
Tests
The evaluator shall perform the evaluation activities listed for FCS_TLSS_EXT.2.1.
Tests
The evaluator shall perform the evaluation activities listed for FCS_TLSS_EXT.2.2.
Tests
The evaluator shall perform the evaluation activities listed for FCS_TLSS_EXT.2.3.

Appendix C - References

ext-comp-def
IdentifierTitle
[CC] Common Criteria for Information Technology Security Evaluation -

Appendix D - Acronyms

AcronymMeaning
AESAdvanced Encryption Standard
Base-PPBase Protection Profile
CACertificate Authority
CACertificate Authority
CBCCipher Block Chaining
CCCommon Criteria
CEMCommon Evaluation Methodology
CNCommon Name
DHEDiffie-Hellman Ephemeral
DNDistinguished Name
DNSDomain Name Server
DTLSDatagram Transport Layer Security
DTLSDatagram Transport Layer Security
EAPExtensible Authentication Protocol
ECDHEElliptic Curve Diffie-Hellman Ephemeral
ECDSAElliptic Curve Digital Signature Algorithm
GCMGalois/Counter Mode
HTTPHypertext Transfer Protocol
IETFInternet Engineering Task Force
IPInternet Protocol
LDAPLightweight Directory Access Protocol
NISTNational Institute of Standards and Technology
OEOperational Environment
PPProtection Profile
PP-ConfigurationProtection Profile Configuration
PP-ModuleProtection Profile Module
RFCRequest for Comment (IETF)
RSARivest Shamir Adelman
SANSubject Alternative Name
SARSecurity Assurance Requirement
SCSVSignaling Cipher Suite Value
SFRSecurity Functional Requirement
SHASecure Hash Algorithm
SIPSession Initiation Protocol
STSecurity Target
TCPTransmission Control Protocol
TLSTransport Layer Security
TOETarget of Evaluation
TSFTOE Security Functionality
TSFITSF Interface
TSSTOE Summary Specification
UDPUser Datagram Protocol
URIUniform Resource Identifier
URLUniform Resource Locator