The WLAN AS EP currently makes the use of IPsec mandatory for conformant TOEs. This is because 802.1X conformance requires the use of RADIUS, which is an insecure UDP protocol. IPsec is meant to provide a tunnel to protect RADIUS communications. Since RadSec allows the use of TLS to protect RADIUS communications, it should be included as an alternative to IPsec.

Section 4.2.1.2 (FCS_IPSEC_EXT.1) in the WLAN AS EP shall be moved to Appendix C (Selection-Based Requirements) and its wording changed to "FCS_IPSEC_EXT.1 is inherited from Appendix B of the NDcPP and is selection-based for FTP_ITC.1."

FTP_ITC.1 in the WLAN AS EP shall be modified as follows:

FTP_ITC.1.1 Refinement: The TSF shall be capable of using IEEE 802.11-2012 (WPA2), IEEE 802.1X, [selection: IPsec, RADIUS over TLS] and [selection: SSH, TLS, HTTPS, no other protocol] to provide a trusted communication channel between itself and authorized IT entities supporting the following capabilities: WLAN clients, audit servers, 802.1X authentication servers, and [assignment: [other capabilities]] that is logically distinct from other communication channels and provides assured identification of its end points and protection of the channel data from disclosure and detection of modification of the channel data.

Application Note: The intent of the above requirement is to use a cryptographic protocol to protect all external communications with authorized IT entities that the TOE interacts with to perform its functions. IEEE 802.11-2012 (WPA2) with IEEE 802.1X is required for communications with wireless clients; IPsec or RADIUS over TLS (commonly known as "RadSec") is required at least for communications with the authentication server.

If the TOE communicates with other necessary authorized IT entities (NTP server, audit server), then they must use IPsec, RADIUS over TLS or one of the other listed protocols (SSH, TLS and TLS/HTTPS are allowed), and the ST author makes the appropriate selections, then ensures the detailed requirements in Appendix B (of the NDcPP or of this EP) corresponding to their selection are included in the ST if not already present. While there are no requirements on the party initiating the communication, the ST author lists in the assignment for FTP_ITC.1.3 the services for which the TOE can initiate the communication with the authorized IT entity.

The requirement implies that not only are communications protected when they are initially established, but also on resumption after an outage.

The remaining elements of this SFR are inherited directly from the base NDcPP, with no modifications. Communications with remote administrators are covered by FTP_TRP, inherited directly from the NDcPP.

In addition, Appendix C - Selection-Based requirements are updated to include FCS_RADSEC_EXT.1 and FCS_RADSEC_EXT.2 as follows:

The following FCS_RADSEC_EXT.1 SFRs shall be included in the ST if RADIUS over TLS is selected in FTP_ITC.1.

FCS_RADSEC_EXT.1.1 – The TSF shall implement RADIUS over TLS as specified in RFC 6614 to communicate securely with a RADIUS server.

FCS_RADSEC_EXT.1.2 – The TSF shall perform peer authentication using [selection: X.509v3 certificates, pre-shared keys].

Application Note: If X.509v3 certificates is selected, then FCS_TLSC_EXT.2 from Appendix B of the Network Device collaborative Protection Profile must be included in the ST.

If pre-shared keys is selected, then FCS_RADSEC_EXT.2 must be included in the ST.

Assurance Activity

TSS

The evaluator shall verify that the TSS description includes the use of RADIUS over TLS, as described in RFC 6614.

If X.509v3 certificates is selected, the evaluator shall ensure that the TSS description includes the use of client-side certificates for TLS mutual authentication.

AGD

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

Test

The evaluator shall demonstrate the ability to successfully establish a RADIUS over TLS connection with a RADIUS server. This test shall be performed with X.509v3 certificates if selected and performed with pre-shared keys if selected.

The following FCS_RADSEC_EXT.2 SFRs shall be included in the ST if pre-shared keys is selected in FCS_RADSEC_EXT.1.2.

FCS_RADSEC_EXT.2.1 – The TSF shall implement [selection: TLS 1.2 (RFC 5246), TLS 1.1 (RFC 4346)] and reject all other TLS and SSL versions. The TLS implementation shall support the following ciphersuites for use when acting as a RADIUS over TLS client:

[selection:

 TLS_PSK_WITH_AES_128_CBC_SHA

-          TLS_PSK_WITH_AES_256_CBC_SHA

-          TLS_DHE_PSK_WITH_AES_128_CBC_SHA

-          TLS_DHE_PSK_WITH_AES_256_CBC_SHA

-          TLS_RSA_PSK_WITH_AES_128_CBC_SHA

-          TLS_RSA_PSK_WITH_AES_256_CBC_SHA

-          TLS_PSK_WITH_AES_128_GCM_SHA256

-          TLS_PSK_WITH_AES_256_GCM_SHA384

-          TLS_DHE_PSK_WITH_AES_128_GCM_SHA256

-          TLS_DHE_PSK_WITH_AES_256_GCM_SHA384

-          TLS_RSA_PSK_WITH_AES_128_GCM_SHA256

-          TLS_RSA_PSK_WITH_AES_256_GCM_SHA384

-         ]

Application Note: The above ciphersuites are only for use when the TSF is acting as a RADIUS over TLS client, not for other uses of the TLS protocol. The ciphersuites to be tested in the evaluated configuration are limited by this requirement. The ST author should select the ciphersuites that are supported. If "X.509v3 certificates" is selected in FCS_RADSEC_EXT.1.2, the ciphersuites selected in (and tested by) FCS_TLSC_EXT.2.1 are also supported for RADIUS over TLS client use.

FCS_RADSEC_EXT.2.2 - The TSF shall be able to [selection: accept, generate using the random bit generator specified in FCS_RBG_EXT.1] bit-based pre-shared keys.

FCS_RADSEC_EXT.2.3 - If ciphersuites beginning with TLS_RSA_PSK are selected in FCS_RADSEC_EXT.2.1, the TSF shall, when any are used for a RADIUS over TLS connection, verify that the presented identifier matches the reference identifier per RFC 6125 section 6.

Application Note: The rules for verification of identity are described in Section 6 of RFC 6125. The reference identifier is typically established by configuration (e.g. configuring the name of the authentication server). 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 for the Subject Alternative Name field. The client then compares this list of all acceptable reference identifiers to the presented identifiers in the TLS server’s certificate.

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

FCS_RADSEC_EXT.2.4 - If ciphersuites beginning with TLS_RSA_PSK are selected in FCS_RADSEC_EXT.2.1, the TSF shall, when any are used for a RADIUS over TLS connection, only establish a trusted channel if the server certificate is valid. If the server certificate is deemed invalid, then the TSF shall [selection: not establish the connection, request authorization to establish the connection, [assignment: other action]].

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 is tested in accordance with testing performed for FIA_X509_EXT.1/Rev.

Assurance Activity

TSS

The evaluator shall check the description of the implementation of this protocol in the TSS to ensure that the ciphersuites supported are specified. The evaluator shall check the TSS to ensure that the ciphersuites specified are identical to those listed for this component. The evaluator shall also verify that the TSS contains a description of the denial of old SSL and TLS versions.

The evaluator shall examine the TSS to ensure it describes the process by which the bit-based pre-shared keys are generated (if the TOE supports this functionality), and confirm that this process uses the RBG specified in FCS_RBG_EXT.1.

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

AGD

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

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

The evaluator shall confirm the operational guidance contains instructions for either entering bit-based pre-shared keys, or generating a bit-based pre-shared key (or both).

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.    

Test

The evaluator shall perform the following tests:

Test 1: The evaluator shall establish a RADIUS over TLS connection using each of the ciphersuites selected in FCS_RADSEC_EXT.2.1. It is sufficient to observe the successful negotiation of a ciphersuite to satisfy the intent of the test; it is not necessary to examine the characteristics of the encrypted traffic in an attempt to discern the ciphersuite being used (for example, that the cryptographic algorithm is 128-bit AES and not 256-bit AES).

Test 2: The evaluator shall set the pre-shared key to a value that does not match the server's pre-shared key and demonstrate that the TOE cannot successfully complete a protocol negotiation using this key.

Test 3: 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 4: The evaluator shall perform the following modifications to the traffic:

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

Test 5: [conditional] If any of the TLS_RSA_PSK ciphersuites are selected:

• The evaluator shall attempt to establish the connection using a server with a server certificate that contains the Server Authentication purpose in the extendedKeyUsage field and verify that a connection is established. The evaluator will then verify that the client rejects an otherwise valid server certificate that lacks the Server Authentication purpose in the extendedKeyUsage field and a connection is not established. Ideally, the two certificates should be identical except for the extendedKeyUsage field.
• The evaluator shall present a server certificate that does not contain an identifier in either the Subject Alternative Name (SAN) or Common Name (CN) that matches the reference identifier. The evaluator shall verify that the connection fails.
• 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.
• 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.
• 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.
• If wildcards are supported by the TOE, the evaluator shall perform the following tests:

• The evaluator shall present a server certificate containing a wildcard that is not in the left-most label of the presented identifier (e.g. foo.*.example.com) and verify that the connection fails.
• The evaluator shall present a server certificate containing a wildcard in the left-most label 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). The evaluator shall 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.com) and verify that the connection fails.
• 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.
• If wildcards are not supported by the TOE, the evaluator shall present a server certificate containing a wildcard 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.

Test 6: [conditional] If the TOE does not generate bit-based pre-shared keys, the evaluator shall obtain a bit-based pre-shared key of the appropriate length and enter it according to the instructions in the operational guidance. The evaluator shall then demonstrate that a successful protocol negotiation can be performed with the key.

Test 7: [conditional] If the TOE does generate bit-based pre-shared keys, the evaluator shall generate a bit-based pre-shared key of the appropriate length and use it according to the instructions in the operational guidance. The evaluator shall then demonstrate that a successful protocol negotiation can be performed with the key.

See issue description.