2.0 National Information Assurance Partnership 2025-01-15 WLAN; Wireless LAN; Wireless Networking; 802.11 0.5 2022-01-20 Conversion to PP-Module; Updated to include WPA 3 and Wi-Fi 6. WPA 3 is required. WPA 2 can additionally be included in the ST. 256 bit keys are required. 128 and 192 bit keys can additionally be included in the ST. 1.0 2022-03-31 Initial Release 2.0 2025-01-15 Incorporation of NIAP TDs and CC:2022 changes TDs Applied https://github.com/commoncriteria/tls master https://www.niap-ccevs.org/static_html/protection-profile/439/-439-/index.html https://github.com/commoncriteria/X509 master https://www.niap-ccevs.org/protectionprofiles/511 The scope of the Wireless Local Area Network (WLAN) Client PP-Module is to describe the security functionality of a WLAN Client in terms of [CC] and to define functional and assurance requirements for such products. This PP-Module is intended for use with the following Base-PPs: General Purpose Operating System (GPOS) Protection Profile, Version 5.0 Protection Profile for Mobile Device Fundamentals (MDF), Version 4.0 A conformant TOE will claim conformance to a PP-Configuration that includes exactly one of the Base-PPs identified above, this PP-Module, and any of the PP-Modules or packages identified in Section 2. These Base-PPs are valid because a WLAN Client is a part of either a commercial operating system that can be installed on a general-purpose computer or an operating system that runs on a purpose-built mobile device. A device that provides the network interface that enables wireless client hosts to access a wired network. Once authenticated as trusted nodes on the wired infrastructure, the APs provide the encryption service on the wireless network between the wireless client and the radio frequency (RF) interface of the AP. A user that has administrative privilege to configure the TOE. A server on the wired network that receives authentication credentials from wireless clients and determines their validity. The information the system uses to verify that the user or administrator is authorized to access the TOE or network. Credentials can exist in various forms, such as username/password or digital certificates. Security related information, e.g. secret and private cryptographic keys, and authentication data such as passwords and Personal Identification Numbers (PINs), whose disclosure or modification can compromise the security of a cryptographic module. A cryptographic function that provides a seed for a random number generator by accumulating the outputs from one or more noise sources. The functionality includes a measure of the minimum work required to guess a given output and tests to ensure that the noise sources are operating properly. An authentication framework, used in wireless networks, that uses Public Key Infrastructure (PKI) to authenticate both the authentication server and the wireless client. A cryptographic operation that is specified for use by FIPS 140. A standard for port-based network access control that defines an authentication mechanism for WLAN Clients to attach to a wired network. A user that has not been granted the ability to use the TOE.

This document specifies SFRs for a WLAN Client. The TOE defined by this PP-Module is a WLAN Client, a software component executing on a client machine (often referred to as a "remote access client") to control the use of a wireless networking interface on that machine. The TOE establishes a secure wireless tunnel between the client device and a WLAN Access System through which all data will traverse. The TOE will implement the same security functionality regardless of whether it is a component of a general-purpose operating system or of a mobile device. A WLAN Client allows remote users to use client machines to establish wireless communication with a private network through a WLAN Access System. IP packets passing between the private network and a WLAN Client are encrypted. The WLAN Client protects the confidentiality and integrity of data in transit between itself and the private network, even though it traverses a wireless connection. The focus of the SFRs in this PP-Module is on the following fundamental aspects of a WLAN Client: Authentication of the WLAN Client Authentication of the Authentication Server Cryptographic protection of data in transit Implementation of services The WLAN Client establishes an 802.11 tunnel between the client device and the network infrastructure using IEEE 802.1X with Extensible Authentication Protocol-Transport Layer Security (EAP-TLS) for authentication. It performs mutual authentication to an AS in the private network as part of the EAP-TLS exchange. The EAP-TLS exchange uses certificates for mutual authentication. The WLAN Client examines the machine certificate transmitted from the AS, checks its validity, and ensures the certificate is signed by a trusted Certificate Authority (CA). The AS will authenticate the WLAN Client certificate at the same time. When the EAP-TLS exchange completes successfully, the network allows the WLAN Client to finish establishing a secure communication tunnel to the private network. The WLAN Client sets up an encrypted, authenticated channel to the WLAN Access System using a 4-way handshake, as specified in IEEE 802.11. Once the channel is established, all communication between the WLAN Client to the WLAN Access System is encrypted with Advanced Encryption Standard (AES) in Cipher Block Chaining-Message Authentication Code Protocol (CCMP) mode and optionally AES in Galois/Counter Mode Protocol (GCMP) mode, as specified in . The WLAN Client (Figure 1), as defined by this PP-Module, is a component executing on a remote access client machine. Note the client is depicted as just a small portion of the WLAN client "machine." As such, the TOE must rely heavily on the TOE’s operational environment (host platform, network stack, and operating system) for its execution domain and its proper usage. The TOE will rely on the IT environment to address much of the security functionality related to administrative functions.

Requirements in this PP-Module are designed to address the security problems in at least the following use cases. These use cases are intentionally very broad, as many specific use cases exist within these larger categories. This use case is for a WLAN Client TOE that is part of a general-purpose operating system. Specifically, the WLAN Client TOE is expected to be part of the operating system itself and not a standalone third-party application that is installed on top of it. This use case is for a WLAN Client TOE that is part of a mobile operating system that runs on a mobile device. Specifically, the WLAN Client TOE is expected to be part of the mobile operating system itself and not a standalone third-party application that is acquired from the mobile vendor's application store.

This section contains selections and assignments that are required when the listed Functional Packages are claimed by this PP-Module. Package Usage guidance defined in the TOE's relevant Base-PP applies to the usage of the packages for this module, unless explicitly stated otherwise in this section. The ST author shall include an iteration of X.509 package requirements in the ST with the suffix "WLAN". For instance, FCS_X509_EXT.1 shall be included as FCS_X509_EXT.1/WLAN. dummy-ref-id The ST author shall select the option to verify certificate identities. dummy-ref-id The ST author shall not select the option to validate certificate revocation status by validity period. CRL and/or OCSP are not required to be selected for this PP-Module. Any other options may be selected without restriction. dummy-ref-id The ST author shall not select the option to determine that the certificate expires within a certain period. CRL and/or OCSP are not required to be selected for this PP-Module. Any other options may be selected without restriction. dummy-ref-id The ST author shall select options requiring that certificates presented for TLS clients and TLS servers have appropriate values for the extendedKeyUsage field as defined in the available selections for processing the extendedKeyUsage extension. dummy-ref-id The ST author shall specify in the assignment for supported functions that the TOE will utilize certificates to support authentication for EAP-TLS exchanges. The ST author shall additionally specify in the assignment for other authenticated communications protocols that the TOE will utilize EAP-TLS. dummy-ref-id The ST author shall include an iteration of TLS package requirements in the ST with the suffix "WLAN". For instance, FCS_TLS_EXT.1 shall be included as FCS_TLS_EXT.1/WLAN. dummy-ref-id The ST author shall claim support for TLS as a client. dummy-ref-id The ST author shall ensure that the claims for supported versions in FCS_TLSC_EXT.1 match those in FCS_WLAN_EXT.1.1. dummy-ref-id

exact extended extended Protection Profile for General Purpose Operating Systems, Version 5.0 Protection Profile for Mobile Device Fundamentals, Version 4.0 PP-Module for Virtual Private Network (VPN) Clients, version 3.0 PP-Module for Bluetooth, version 2.0 PP-Module for Mobile Device Management Agent, version 2.0 cPP-Module for Biometric Enrolment and Verification, version 1.1 Functional Package for Transport Layer Security Version 2.1 Functional Package for X.509 Version 1.0 This PP-Module is written to address the situation when an entity desires wireless access to a private network. To allow access to the private network, the entity (machine) must be authenticated before a secure communications channel can be established. The TOE is the entity that seeks to be authenticated and be given access to services offered by the protected network and is the Supplicant in the IEEE 802.1X framework. The following threats are specific to WLAN Clients, and represent an addition to those identified in the Base-PPs. Security mechanisms of the TOE generally build up from a primitive set of mechanisms (e.g, memory management, privileged modes of process execution) to more complex sets of mechanisms. Failure of the primitive mechanisms could lead to a compromise in more complex mechanisms, resulting in a compromise of the TSF. FPT_TST_EXT.3/WLAN Mitigates the threat by performing self-tests to design if a TSF failure has occurred. A user may gain unauthorized access to the TOE data and TOE executable code. A malicious user, process, or external IT entity may masquerade as an authorized entity in order to gain unauthorized access to data or TOE resources. A malicious user, process, or external IT entity may misrepresent itself as the TOE to obtain identification and authentication data. FCS_CKM.1/WPA Mitigates the threat by performing secure key generation in support of protected wireless communications. FCS_CKM.2/WLAN Mitigates the threat by performing secure key distribution in support of protected wireless communications. FCS_WPA_EXT.1 Mitigates the threat by requiring the use of WPA for security. FIA_PAE_EXT.1 Mitigates the threat by implementing 802.1X for secure authentication of wireless communications. FIA_X509_EXT.6 Mitigates the threat by implementing a mechanism to establish a root of trust for X.509 certificates presented to the TOE. FMT_SMF.1/WLAN Mitigates the threat by defining the authorization that is required to access the management functions of the TOE. FTA_WSE_EXT.1 Mitigates the threat by operating in a default-deny posture for wireless networks so that the TOE will not communicate with unknown entities. FTP_ITC.1/WLAN Mitigates the threat by defining the trusted communications protocols the TSF implements to communicate with external entities. Malicious remote users or external IT entities may take actions that adversely affect the security of the TOE. These actions may remain undetected and thus their effects cannot be effectively mitigated. FAU_GEN.1/WLAN Mitigates the threat by implementing a mechanism to detect actions performed on or by the TOE. Information cannot flow between the wireless client and the internal wired network without passing through the TOE. The operational environment objective OE.NO_TOE_BYPASS is realized through A.NO_TOE_BYPASS. TOE Administrators are trusted to follow and apply all administrator guidance in a trusted manner. The Operational Environment objective OE.TRUSTED ADMIN is realized through A.TRUSTED_ADMIN. Information cannot flow between external and internal networks located in different enclaves without passing through the TOE. TOE administrators are trusted to follow and apply all administrator guidance in a trusted manner. This chapter describes the security requirements which have to be fulfilled by the . Those requirements comprise functional components from Part 2 and assurance components from Part 3 of . The following notations are used: Refinement operation (denoted by bold text): Is used to add details to a requirement, and thus further restricts a requirement. Selection operation (denoted by italicized text): Is used to select one or more options provided by the [CC] in stating a requirement. Assignment operation (denoted by italicized text): Is used to assign a specific value to an unspecified parameter, such as the length of a password. Iteration operation: Identified with a slash followed by a unique text string (e.g. "/WLAN") or a number inside parentheses (e.g. "(1)") https://github.com/commoncriteria/operatingsystem release-5.0 https://www.niap-ccevs.org/static_html/protection-profile/469/OS%204.3%20PP/index.html When this PP-Module is used to extend the GPOS PP, the TOE type for the overall TOE is still a general-purpose operating system. The TOE boundary is simply extended to include the WLAN Client functionality that runs on the operating system. The Base-PP defines threats for local attacks and remote attacks, both of which could cause a failure of the TSF. This PP-Module adds a generic TSF failure threat in the event that the WLAN Client fails through unintended system behavior rather than a direct malicious attack. The Base-PP defines threats for local attacks and remote attacks. The threat of unauthorized access to the WLAN Client is a specific threat that results from successful exploitation of one of these Base-PP threats. The Base-PP defines threats for local attacks and remote attacks. It does not define a threat specifically for undetected actions but it does map the local attack and remote attack threats to a TOE objective for accountability. Therefore, the threat of undetected actions is consistent with the Base-PP because this is a subset of the threats defined in the Base-PP, or a mechanism to increase the likelihood that these threats will successfully be exploited. This assumption relates to the deployment of the TOE in relation to the network resources that it interacts with. It does not enforce any restrictions on the TOE's deployment that are contrary to what the Base-PP requires. The Base-PP defines A.PROPER_USER and A.PROPER_ADMIN assumptions that serve the same purpose as A.TRUSTED_ADMIN in this PP-Module. This objective relates to the deployment of the TOE in relation to the network resources that it interacts with. It does not enforce any restrictions on the TOE's deployment that are contrary to what the Base-PP requires. The Base-PP defines OE.PROPER_USER and OE.PROPER_ADMIN objectives that serve the same purpose as OE.TRUSTED_ADMIN in this PP-Module. The Base-PP defines its own auditing mechanism; this PP-Module can use that mechanism or implement its own to generate audit data for security-relevant events that are specific to this PP-Module. This SFR requires the TOE to generate cryptographic keys that are only used by the PP-Module's functionality. It invokes Base-PP functionality to do this in a manner that the Base-PP permits. This SFR requires the TOE to perform a decryption operation using AES Key Wrap, which is a function that the Base-PP provides. This SFR requires the TOE to implement EAP-TLS; this protocol relies on the same cryptographic functionality that the Base-PP uses to implement TLS. This SFR requires the TOE to specify the WPA versions it supports; this is functionality that is specific to the PP-Module and does not affect any Base-PP functionality. This SFR defines the ability of the TOE to implement IEEE 802.1X. This behavior relates entirely to the PP-Module and does not affect the ability of the Base-PP to implement its security functionality. This SFR defines the TOE's X.509 certificate validation specifically when validating EAP-TLS certificates. The Base-PP also defines an iteration of this SFR but the PP-Module requires a separate iteration because EAP-TLS certificates have specific handling requirements that are not present in the Base-PP because the Base-PP does not define implementation of the EAP-TLS protocol. This SFR defines the TOE's use of X.509 certificates in EAP-TLS. This function uses the same certificate validation functionality that the Base-PP defines. This SFR defines behavior for implementing certificate storage. The SFR allows for the possibility that existing platform storage can be used, so it does not conflict with the Base-PP if that portion of the TOE already implements its own storage mechanism. This SFR defines the management activities that are specific to this PP-Module. This behavior relates entirely to the PP-Module and does not affect the ability of the Base-PP to implement its security functionality. This SFR defines self-test behavior for the WLAN Client. This behavior relates entirely to the PP-Module and does not affect the ability of the Base-PP to implement its security functionality. This SFR requires the TOE to restrict the wireless networks that it can connect to. This behavior relates entirely to the PP-Module and does not affect the ability of the Base-PP to implement its security functionality. This SFR defines the protocols that the TOE uses for secure wireless communications. This behavior relates entirely to the PP-Module and does not affect the ability of the Base-PP to implement its security functionality. This SFR requires the TOE to validate a specific TLS extension when establishing EAP-TLS communications. This behavior relates entirely to the PP-Module and does not affect the ability of the Base-PP to implement its security functionality. https://github.com/commoncriteria/mobile-device release-3.3 https://www.niap-ccevs.org/static_html/protection-profile/468/MDF%203.3%20PP/index.html When this PP-Module is used to extend the MDF PP, the TOE type for the overall TOE is still a mobile device. The TOE boundary is simply extended to include the WLAN Client functionality that runs on the mobile device's Rich OS. The Base-PP defines the T.FLAWAPP threat for the threat that application failures may pose to the device as a whole. The T.TSF_FAILURE threat from this PP-Module is a specific example of the T.FLAWAPP threat, though it relates to the WLAN Client as an intrinsic part of the mobile device rather than a third-party application installed on top of it. The Base-PP also defines the T.PERSISTENT threat, which is another specific case of TSF failure. The Base-PP defines threats for network eavesdropping and network attacks. Exploiting either threat could allow an attacker to exploit the T.UNAUTHORIZED_ACCESS threat defined by this PP-Module. The Base-PP defines threats for persistent access to the TOE and flawed applications on the TOE. It does not define a threat specifically for undetected actions but the threat of undetected actions defined by this PP-Module could increase the likelihood that the Base-PP threats can be successfully exploited. This assumption relates to the deployment of the TOE in relation to the network resources that it interacts with. It does not enforce any restrictions on the TOE's deployment that are contrary to what the Base-PP requires. The Base-PP defines the A.TRUSTED_ADMIN assumptions that expects administrators will configure the TOE correctly, which also implies they are non-malicious. This objective relates to the deployment of the TOE in relation to the network resources that it interacts with. It does not enforce any restrictions on the TOE's deployment that are contrary to what the Base-PP requires. The Base-PP defines the OE.CONFIG objective that expects administrators will configure the TOE correctly, which also implies they are non-malicious. The Base-PP defines its own auditing mechanism; this PP-Module can use that mechanism or implement its own to generate audit data for security-relevant events that are specific to this PP-Module. This SFR requires the TOE to generate cryptographic keys that are only used by the PP-Module's functionality. It invokes Base-PP functionality to do this in a manner that the Base-PP permits. This SFR requires the TOE to perform a decryption operation using AES Key Wrap, which is a function that the Base-PP provides. This SFR requires the TOE to implement EAP-TLS; this protocol relies on the same cryptographic functionality that the Base-PP uses to implement TLS. This SFR requires the TOE to specify the WPA versions it supports; this is functionality that is specific to the PP-Module and does not affect any Base-PP functionality. This SFR defines the ability of the TOE to implement IEEE 802.1X. This behavior relates entirely to the PP-Module and does not affect the ability of the Base-PP to implement its security functionality. This SFR defines the TOE's X.509 certificate validation specifically when validating EAP-TLS certificates. The Base-PP also defines an iteration of this SFR but the PP-Module requires a separate iteration because EAP-TLS certificates have specific handling requirements that are not present in the Base-PP because the Base-PP does not define implementation of the EAP-TLS protocol. This SFR defines the TOE's use of X.509 certificates in EAP-TLS. This function uses the same certificate validation functionality that the Base-PP defines. This SFR defines behavior for implementing certificate storage. The SFR allows for the possibility that existing platform storage can be used, so it does not conflict with the Base-PP if that portion of the TOE already implements its own storage mechanism. This SFR defines the management activities that are specific to this PP-Module. This behavior relates entirely to the PP-Module and does not affect the ability of the Base-PP to implement its security functionality. This SFR defines self-test behavior for the WLAN Client. This behavior relates entirely to the PP-Module and does not affect the ability of the Base-PP to implement its security functionality. This SFR requires the TOE to restrict the wireless networks that it can connect to. This behavior relates entirely to the PP-Module and does not affect the ability of the Base-PP to implement its security functionality. This SFR defines the protocols that the TOE uses for secure wireless communications. This behavior relates entirely to the PP-Module and does not affect the ability of the Base-PP to implement its security functionality. This SFR requires the TOE to generate cryptographic keys that are only used by the PP-Module's functionality. It invokes Base-PP functionality to do this in a manner that the Base-PP permits. This SFR requires the TOE to validate a specific TLS extension when establishing EAP-TLS communications. This behavior relates entirely to the PP-Module and does not affect the ability of the Base-PP to implement its security functionality.

If auditing for the WLAN Client cannot be controlled separately from its underlying platform, the "Startup and shutdown of the audit functions" event defined in each Base-PP is sufficient to address that event for this iteration of the SFR. Auditable events for selection-based SFRs are found in . If the TOE does not claim a particular selection-based SFR, it is not expected to generate any corresponding audit data for that SFR. includes auditable events for FPT_TST_EXT.3/WLAN. If the TOE does not perform its own self-tests (i.e., "TOE platform" is selected in FPT_TST_EXT.3.1/WLAN and FPT_TST_EXT.3.2/WLAN), the audit data for this event may also be generated by the TOE platform. The evaluator shall check the TSS and ensure it provides a format for the audit data. Each format type for audit data must be covered, along with a brief description of each field. If "invoke platform-provided functionality" is selected, the evaluator shall examine the TSS to verify it describes (for each supported platform) how this functionality is invoked (it should be noted that this may be through a mechanism that is not implemented by the WLAN Client; however, that mechanism will be identified in the TSS as part of this evaluation activity). The evaluator shall check the operational guidance and ensure it lists all of the auditable events and provides a format for the audit data. Each format type for audit data must be covered, along with a brief description of each field. The evaluator shall check to make sure that every audit event type mandated by the PP-Module is described and that the description of the fields contains the information required in FAU_GEN.1.2/WLAN, and the additional information specified in and . The evaluator shall in particular ensure that the operational guidance is clear in relation to the contents for failed cryptographic events. In the Auditable Events tables, information detailing the cryptographic mode of operation and a name or identifier for the object being encrypted is required. The evaluator shall ensure that name or identifier is sufficient to allow an administrator reviewing the audit log to determine the context of the cryptographic operation (for example, performed during a key negotiation exchange, performed when encrypting data for transit) as well as the non-TOE endpoint of the connection for cryptographic failures relating to communications with other IT systems. The evaluator shall also make a determination of the administrative actions that are relevant in the context of this PP-Module. The TOE may contain functionality that is not evaluated in the context of this PP-Module because the functionality is not specified in an SFR. This functionality may have administrative aspects that are described in the operational guidance. Since such administrative actions will not be performed in an evaluated configuration of the TOE, the evaluator shall examine the operational guidance and make a determination of which administrative commands, including subcommands, scripts, and configuration files, are related to the configuration (including enabling or disabling) of the mechanisms implemented in the TOE that are necessary to enforce the requirements specified in the PP-Module, which thus form the set of “all administrative actions”. The evaluator may perform this activity as part of the activities associated with ensuring the AGD_OPE guidance satisfies the requirements. The evaluator shall test the TOE’s ability to correctly generate audit data by having the TOE generate audit data in accordance with the evaluation activities associated with the functional requirements in this PP-Module. When verifying the test results, the evaluator shall ensure the audit data that is generated during testing matches the format specified in the administrative guidance, and that the fields in the audit data have the proper entries. Note that the testing here can be accomplished in conjunction with the testing of the security mechanisms directly. For example, testing performed to ensure that the administrative guidance provided is correct verifies that AGD_OPE.1 is satisfied and should address the invocation of the administrative actions that are needed to verify the audit data is generated as expected. The cryptographic key derivation algorithm required by IEEE 802.11-2020 (Section 11.6.1.2) and verified in WPA2 certification is PRF-384, which uses the HMAC-SHA-1 function and outputs 384 bits. The use of GCMP was first defined in IEEE 802.11ac-2014 (Section 11.4.5) but subsequently integrated into 802.11-2020. This protocol requires a key derivation function (KDF) KDF based on HMAC-SHA-256 (for 128-bit symmetric keys) or HMAC-SHA384 (for 256-bit symmetric keys). This KDF outputs 704 bits. This requirement applies only to the keys that are generated/derived for the communications between the access point and the client once the client has been authenticated. It refers to the derivation of the Pairwise Temporal Key (PTK) from the PMK, which is done using a random value generated by the RBG specified in this PP-Module, the HMAC function using SHA-1 as specified in this PP-Module, as well as other information. The evaluator shall verify that the TSS describes how the primitives defined and implemented by this PP-Module are used by the TOE in establishing and maintaining secure connectivity to the wireless clients. The TSS shall also provide a description of the developer’s method(s) of assuring that their implementation conforms to the cryptographic standards; this includes not only testing done by the developing organization, but also any third-party testing that is performed. There are no guidance evaluation activities for this component. The evaluator shall perform the following tests: The evaluator shall configure the access point so the cryptoperiod of the session key is 1 hour. The evaluator shall successfully connect the TOE to the access point and maintain the connection for a length of time that is greater than the configured cryptoperiod. The evaluator shall use a packet capture tool to determine that after the configured cryptoperiod, a re-negotiation is initiated to establish a new session key. Finally, the evaluator shall determine that the renegotiation has been successful and the client continues communication with the access point. The evaluator shall perform the following test using a packet sniffing tool to collect frames between the TOE and a wireless LAN access point: Step 1: The evaluator shall configure the access point to an unused channel and configure the WLAN sniffer to sniff only on that channel (i.e., lock the sniffer on the selected channel). The sniffer should also be configured to filter on the MAC address of the TOE and/or access point. Step 2: The evaluator shall configure the TOE to communicate with a WLAN access point using IEEE 802.11-2020 and a 256-bit (64 hex values 0-f) pre-shared key. The pre-shared key is only used for testing. Step 3: The evaluator shall start the sniffing tool, initiate a connection between the TOE and the access point, and allow the TOE to authenticate, associate, and successfully complete the 4-way handshake with the client. Step 4: The evaluator shall set a timer for 1 minute, at the end of which the evaluator shall disconnect the TOE from the wireless network and stop the sniffer. Step 5: The evaluator shall identify the 4-way handshake frames (denoted EAPOL-key in Wireshark captures) and derive the PTK from the 4-way handshake frames and pre-shared key as specified in IEEE 802.11-2020. Step 6: The evaluator shall select the first data frame from the captured packets that was sent between the TOE and access point after the 4-way handshake successfully completed, and without the frame control value 0x4208 (the first 2 bytes are 08 42). The evaluator shall use the PTK to decrypt the data portion of the packet as specified in IEEE 802.11-2020, and shall verify that the decrypted data contains ASCII-readable text. Step 7: The evaluator shall repeat Step 6 for the next 2 data frames between the TOE and access point and without frame control value 0x4208. This requirement applies to the Group Temporal Key (GTK) that is received by the TOE for use in decrypting broadcast and multicast messages from the access point to which it's connected. 802.11-2020 specifies the format for the transfer as well as the fact that it must be wrapped by the AES Key Wrap method specified in RFC 3394; the TOE must be capable of unwrapping such keys. The evaluator shall check the TSS to ensure that it describes how the GTK is unwrapped prior to being installed for use on the TOE using the AES implementation specified in this PP-Module. There are no guidance evaluation activities for this component. The evaluator shall perform the following test using a packet sniffing tool to collect frames between the TOE and a wireless access point (which may be performed in conjunction with the assurance activity for FCS_CKM.1.1/WLAN). Step 1: The evaluator shall configure the access point to an unused channel and configure the WLAN sniffer to sniff only on that channel (i.e., lock the sniffer on the selected channel). The sniffer should also be configured to filter on the MAC address of the TOE and/or access point. Step 2: The evaluator shall configure the TOE to communicate with the access point using IEEE 802.11-2020 and a 256-bit (64 hex values 0-f) pre-shared key, setting up the connections as described in the operational guidance. The pre-shared key is only used for testing. Step 3: The evaluator shall start the sniffing tool, initiate a connection between the TOE and access point, and allow the TOE to authenticate, associate, and successfully complete the 4-way handshake with the TOE. Step 4: The evaluator shall set a timer for 1 minute, at the end of which the evaluator shall disconnect the TOE from the access point and stop the sniffer. Step 5: The evaluator shall identify the 4-way handshake frames (denoted EAPOL-key in Wireshark captures) and derive the PTK and GTK from the 4-way handshake frames and pre-shared key as specified in IEEE 802.11-2020. Step 6: The evaluator shall select the first data frame from the captured packets that was sent between the TOE and access point after the 4-way handshake successfully completed, and with the frame control value 0x4208 (the first 2 bytes are 08 42). The evaluator shall use the GTK to decrypt the data portion of the selected packet as specified in IEEE 802.11-2020, and shall verify that the decrypted data contains ASCII-readable text. Step 7: The evaluator shall repeat Step 6 for the next 2 data frames with frame control value 0x4208. Components in this family define requirements for the support of EAP-TLS. requires the TSF to support EAP-TLS with specified versions. There are no management functions foreseen. There are no auditable events foreseen. FCS_TLSC_EXT.1 TLS Client Protocol Components in this family define requirements for supporting Wi-Fi Protected Access (WPA). requires the TSF to support WPA3 at minimum, with optional support for WPA2. The following actions could be considered for the management functions in FMT: Configure the supported WPA versions. There are no auditable events foreseen. FCS_COP.1 Cryptographic Operation The WLAN client can support connecting to networks of other security types (e.g., open); however, those will not be tested as part of this evaluation and FMT_SMF.1 will ensure that WPA3 and, if selected, WPA2 can be configured. There are no TSS evaluation activities for this component. The evaluator shall ensure that the AGD contains guidance on how to configure the WLAN client to connect to networks supporting WPA3 and, if selected, WPA2. The evaluator shall configure a Wi-Fi network that utilizes WPA3 and verify that the client can connect. The same test shall be repeated for WPA2 if it is selected. Components in this family define requirements for TOE support of IEEE 802.1X authentication. describes the ability of the TOE to act as a supplicant for 802.1X authentication. The following actions could be considered for the management functions in FMT: Enable/disable IEEE 802.1X pre-authentication. Enable/disable PMK caching. Set the amount of time (in minutes) for which PMK entries are cached. Set the maximum number of PMK entries that can be cached. There are no auditable events foreseen. No dependencies. This requirement covers the TOE's role as the supplicant in an 802.1X authentication exchange. If the exchange is completed successfully, the TOE will derive the PMK as a result of the EAP-TLS (or other appropriate EAP exchange) and perform the 4-way handshake with the wireless access system (authenticator) to begin 802.11 communications. As indicated previously, there are at least two communication paths present during the exchange; one with the wireless access system and one with the authentication server that uses the wireless access system as a relay. The TOE establishes an EAP over LAN (EAPOL) connection with the wireless access system as specified in 802.1X-2020. The TOE and authentication server establish an EAP-TLS session (RFC 5216). The point of performing 802.1X authentication is to gain access to the network (assuming the authentication was successful and that all 802.11 negotiations are performed successfully); in the terminology of 802.1X, this means the TOE will gain access to the "controlled port" maintained by the wireless access system. There are no TSS evaluation activities for this component. There are no guidance evaluation activities for this component. The evaluator shall perform the following tests: The evaluator shall demonstrate that the TOE has no access to the test network. After successfully authenticating with an authentication server through a wireless access system, the evaluator shall demonstrate that the TOE does have access to the test network. The evaluator shall demonstrate that the TOE has no access to the test network. The evaluator shall attempt to authenticate using an invalid client certificate, such that the EAP-TLS negotiation fails. This should result in the TOE still being unable to access the test network. The evaluator shall demonstrate that the TOE has no access to the test network. The evaluator shall attempt to authenticate using an invalid authentication server certificate, such that the EAP-TLS negotiation fails. This should result in the TOE still being unable to access the test network. Components in this family define requirements for the use of X.509 certificates. requires the TOE to implement the ability to store X.509 certificates. The following actions could be considered for the management functions in FMT: Loading of X.509 certificates into the TOE. Revocation of loaded X.509 certificates. The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST: Basic: Attempts to load certificates. Basic: Attempts to revoke certificates. No dependencies. This PP-Module assumes that any platform mechanism used for X.509 certificate loading is capable of enforcing access control to prevent unauthorized subjects from manipulating the contents of the certificate storage. The evaluator shall examine the TSS to determine that it describes all certificate stores implemented that contain certificates used to meet the requirements of this PP-Module. This description shall contain information pertaining to how certificates are loaded into the store, and how the store is protected from unauthorized access. If the TOE relies on a platform mechanism for certificate loading and storage, the evaluator shall verify that the TSS identifies this mechanism and describes how use of this mechanism is protected against unauthorized access. The evaluator shall check the administrative guidance to ensure that it describes how to load X.509 certificates into the TOE's certificate store, regardless of whether the TSF provides this mechanism itself or the TOE relies on a platform-provided mechanism for this. The evaluator shall perform the following test for each TOE function that requires the use of certificates: The evaluator shall demonstrate that using a certificate without a valid certification path results in the function failing. The evaluator shall then load any certificates needed to validate the certificate to be used in the function and demonstrate that the function succeeds. The evaluator shall then delete one of these dependent certificates and show that the function fails. The evaluator shall demonstrate that the mechanism used to load or configure X.509 certificates cannot be accessed without appropriate authorization. Attempts to load certificates. Attempts to revoke certificates. For installation, the WLAN Client relies on the underlying platform to authenticate the administrator to the client machine on which the TOE is installed. For the function "configure the cryptoperiod for the established session keys," the unit of measure for configuring the cryptoperiod must be no greater than an hour. For example: units of measure in seconds, minutes and hours are acceptable and units of measure in days or greater are not acceptable. There are no TSS evaluation activities for this component. The evaluator shall check the operational guidance to verify that every management function claimed by the TOE is described there. The evaluator shall also verify that these descriptions include the information required to perform the management duties associated with the function. The evaluator shall test the TOE’s ability to provide the management functions by configuring the TOE and performing the management activities associated with each function claimed in the SFR. Note that this may be accomplished in conjunction with the testing of other requirements, such as the FCS_TLSC_EXT requirements from the and FTA_WSE_EXT.1. Components in this family define requirements for self-testing to verify the functionality and integrity of the TOE. requires the TOE or its platform to perform power on self-tests to verify its functionality and the integrity of its stored executable code. No management functions are foreseen. The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST: Basic: Execution of TSF self-tests. Basic: Detected integrity violation. FCS_COP.1 Cryptographic Operation While the TOE is defined as a software package running on a platform defined by the claimed Base-PP, it is still capable of performing the self-test activities required above. However, if the cryptographic algorithm implementation is provided by the underlying platform, it may be the case where the TSF self-testing is a check to verify that the underlying platform has successfully completed its own self-tests prior to the TSF attempting to use the implementation. It should be understood that there is a significant dependency on the host platform in assessing the assurance provided by these self-tests since a compromise of the underlying platform could potentially result in the self-tests functioning incorrectly. The evaluator shall examine the TSS to ensure that it details the self tests that are run by the TSF on start-up; this description should include an outline of what the tests are actually doing (e.g., rather than saying "memory is tested", a description similar to "memory is tested by writing a value to each memory location and reading it back to ensure it is identical to what was written" shall be used). The evaluator shall ensure that the TSS makes an argument that the tests are sufficient to demonstrate that the TSF is operating correctly. The evaluator shall examine the TSS to ensure that it describes how to verify the integrity of stored TSF executable code when it is loaded for execution. The evaluator shall ensure that the TSS makes an argument that the tests are sufficient to demonstrate that the integrity of stored TSF executable code has not been compromised. The evaluator also ensures that the TSS (or the operational guidance) describes the actions that take place for successful (e.g. hash verified) and unsuccessful (e.g., hash not verified) cases. The evaluator shall ensure that the operational guidance describes the actions that take place for successful (e.g. hash verified) and unsuccessful (e.g., hash not verified) cases. The evaluator shall perform the following tests: The evaluator shall perform the integrity check on a known good TSF executable and verify that the check is successful. The evaluator shall modify the TSF executable, perform the integrity check on the modified TSF executable, and verify that the check fails. Execution of this set of TSF self-tests. Detected integrity violation The TSF binary file that caused the integrity violation Components in this family define requirements for specifying wireless networks that the TOE can connect to. describes the ability of the TOE to apply administrative limits on the wireless networks that it can connect to. The following actions could be considered for the management functions in FMT: Specify allowed wireless networks based on Service Set Identifier (SSID). The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST: Basic: All attempts to connect to access points. FMT_SMF.1 Specification of Management Functions The intent of this requirement is to allow the administrator to limit the wireless networks to which the TOE is allowed to connect. The evaluator shall examine the TSS to determine that it defines SSIDs as the attribute to specify acceptable networks. The evaluator shall examine the operational guidance to determine that it contains guidance for configuring the list of SSIDs that the WLAN Client is able to connect to. The evaluator shall perform the following tests for each attribute: The evaluator configures the TOE to allow a connection to a wireless network with a specific SSID. The evaluator configures the test environment such that the allowed SSID and an SSID that is not allowed are both "visible" to the TOE. The evaluator shall demonstrate that they can successfully establish a connection with the allowed SSID. The evaluator shall then attempt to establish a session with the disallowed SSID and observe that the attempt fails. All attempts to connect to access points. For each access point record the Complete SSID and MAC Certificate Check Message and the last integer greater than or equal to 2 octets of the MAC Address Success and failures (including reason for failure). The intent of the above requirement is to use the cryptographic protocols identified in the requirement to protect communications between the TOE and the Access Point. The requirement implies that not only are communications protected when they are initially established, but also on resumption after an outage. It may be the case that some part of the TOE setup involves manually setting up tunnels to protect other communication, and if after an outage the TOE attempts to re-establish the communication automatically with (the necessary) manual intervention, there may be a window created where an attacker might be able to gain critical information or compromise a connection. The following tests are only intended to cover the WLAN communication channel (not other communication channels that may be available on the TOE such as mobile broadband). The evaluator shall examine the TSS to determine that it describes the details of the TOE connecting to an access point in terms of the cryptographic protocols specified in the requirement, along with TOE-specific options or procedures that might not be reflected in the specification. The evaluator shall also confirm that all protocols listed in the TSS are specified and included in the requirements in the ST. The evaluator shall confirm that the operational guidance includes instructions for establishing the connection to the access point and that it includes recovery instructions should a connection be unintentionally broken. The evaluator shall perform the following tests: The evaluator shall ensure that the TOE is able to initiate communications with an access point using the protocols specified in the requirement by setting up the connections as described in the operational guidance and ensuring that communications are successful. The evaluator shall ensure, for each communication channel with an authorized IT entity, the channel data is not sent in plaintext. The evaluator shall ensure, for each communication channel with an authorized IT entity, modification of the channel data is detected by the TOE. The evaluators shall physically interrupt the connection from the TOE to the access point (e.g., moving the TOE host out of range of the access point, turning the access point off). The evaluators shall ensure that subsequent communications are appropriately protected, at a minimum in the case of any attempts to automatically resume the connection or connect to a new access point. Further evaluation activities are associated with the specific protocols. All attempts to establish a trusted channel. Identification of the non-TOE endpoint of the channel. As indicated in the introduction to this PP-Module, the baseline requirements are contained in the body of this PP-Module. There are additional requirements based on selections in the body of the PP-Module: if certain selections are made, then additional requirements below will need to be included. This appendix includes requirements that specify security functionality which also addresses threats. The requirements are not currently mandated in the body of this PP-Module as they describe security functionality not yet widely available in commercial technology. However, these requirements may be included in the ST such that the TOE is still conformant to this PP-Module, and it is expected that they be included as soon as possible. This PP-Module has no implicitly satisfied requirements. All SFR dependencies are explicitly met either through SFRs defined by the PP-Module, SFRs inherited from the Base-PPs, or SFRs that are hierarchical to the listed dependency. The TOE does not require any additional supplementary information to describe its entropy sources beyond the requirements outlined in the Base-PPs. 802.11-2020 802.11-2020 - IEEE Standard for Information technology—Telecommunications and information exchange between systems Local and metropolitan area networks—Specific requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications 802.1X-2020 802.1X-2020 - IEEE Standard for Local and metropolitan area networks--Port-Based Network Access Control RFC 3394 RFC 3394 - Advanced Encryption Standard (AES) Key Wrap Algorithm RFC 4346 RFC 4346 - The Transport Layer Security (TLS) Protocol Version 1.1 RFC 5216 RFC 5216 - The EAP-TLS Authentication Protocol RFC 5246 RFC 5246 - The Transport Layer Security (TLS) Protocol Version 1.2 RFC 5280 RFC 5280 - Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile RFC 5288 RFC 5288 - AES Galois Counter Mode (GCM) Cipher Suites for TLS RFC 5289 RFC 5289 - TLS Elliptic Curve Cipher Suites with SHA-256/384 and AES Galois Counter Mode (GCM)