Comment: Comment-1-
Comment: Comment-2-
Comment: Comment-3-
Comment: Comment-4-
Comment: Comment-5-
Comment: Comment-6-

PP-Module for WLAN Clients

NIAP Logo
Version: 2.0
2025-01-15
National Information Assurance Partnership

Revision History

VersionDateComment
0.52022-01-20Conversion 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.02022-03-31Initial Release
2.02025-01-15Incorporation of NIAP TDs and CC:2022 changes

Contents

1Introduction1.1Overview1.2Terms1.2.1Common Criteria Terms1.2.2Technical Terms1.3Compliant Targets of Evaluation1.3.1TOE Boundary1.4Use-Cases2Conformance Claims3Security Problem Definition3.1Threats3.2Assumptions3.3Organizational Security Policies4Security Objectives4.1Security Objectives for the Operational Environment4.2Security Objectives Rationale5Security Requirements5.1 Protection Profile for General Purpose Operating System Security Functional Requirements Direction 5.1.1 Modified SFRs 5.1.2 Additional SFRs5.2 Protection Profile for Mobile Device Fundamentals Security Functional Requirements Direction 5.2.1 Modified SFRs 5.2.2 Additional SFRs5.3TOE Security Functional Requirements5.3.1Auditable Events for Mandatory SFRs5.3.2Security Audit (FAU)5.3.3Cryptographic Support (FCS)5.3.4Identification and Authentication (FIA)5.3.5Security Management (FMT)5.3.6Protection of the TSF (FPT)5.3.7TOE Access (FTA)5.3.8Trusted Path/Channels (FTP)5.4TOE Security Functional Requirements Rationale6Consistency Rationale6.1 Protection Profile for General Purpose Operating System6.1.1 Consistency of TOE Type 6.1.2 Consistency of Security Problem Definition 6.1.3 Consistency of OE Objectives 6.1.4 Consistency of Requirements 6.2 Protection Profile for Mobile Device Fundamentals6.2.1 Consistency of TOE Type 6.2.2 Consistency of Security Problem Definition 6.2.3 Consistency of OE Objectives 6.2.4 Consistency of Requirements Appendix A - Optional SFRsA.1Strictly Optional Requirements A.2Objective Requirements A.3Implementation-dependent Requirements Appendix B - Selection-based Requirements B.1Auditable Events for Selection-based SFRsB.2Cryptographic Support (FCS)Appendix C - Extended Component DefinitionsC.1Extended Components TableC.2Extended Component DefinitionsC.2.1Cryptographic Support (FCS)C.2.1.1FCS_WPA_EXT Supported WPA VersionsC.2.2Identification and Authentication (FIA)C.2.2.1FIA_PAE_EXT Port Access Entity AuthenticationC.2.2.2FIA_X509_EXT X.509 Certificate Use and ManagementC.2.3Protection of the TSF (FPT)C.2.3.1FPT_TST_EXT TSF Self-TestC.2.4TOE Access (FTA)C.2.4.1FTA_WSE_EXT Wireless Network AccessAppendix D - Implicitly Satisfied RequirementsAppendix E - Entropy Documentation and AssessmentAppendix F - AcronymsAppendix G - Bibliography

1 Introduction

1.1 Overview

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:

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.

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.
Collaborative Protection Profile (cPP)
A Protection Profile developed by international technical communities and approved by multiple schemes.
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.
Extended Package (EP)
A deprecated document form for collecting SFRs that implement a particular protocol, technology, or functionality. See Functional Packages.
Functional Package (FP)
A document that collects SFRs for a particular protocol, technology, or functionality.
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-PPs.
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.
Target of Evaluation (TOE)
The product under evaluation.
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.

1.2.2 Technical Terms

Access Point (AP)
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.
Administrator
A user that has administrative privilege to configure the TOE.
Authentication Credentials
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.
Authentication Server (AS)
A server on the wired network that receives authentication credentials from wireless clients and determines their validity.
Critical Security Parameter (CSP)
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.
Entropy Source
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.
Extensible Authentication Protocol (EAP)
An authentication framework, used in wireless networks, that uses Public Key Infrastructure (PKI) to authenticate both the authentication server and the wireless client.
FIPS-Approved Cryptographic Function
A cryptographic operation that is specified for use by FIPS 140.
IEEE 802.1X
A standard for port-based network access control that defines an authentication mechanism for WLAN Clients to attach to a wired network.
Unauthorized User
A user that has not been granted the ability to use the TOE.

1.3 Compliant Targets of Evaluation

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:

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 [802.11-2020].

1.3.1 TOE Boundary

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.

Figure 1: WLAN Client Operating Environment

1.4 Use-Cases

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.
[USE CASE 1] General-Purpose Operating System
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.
[USE CASE 2] Mobile Device
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.

2 Conformance Claims

Conformance Statement

An ST must claim exact conformance to this PP-Module.

The evaluation methods used for evaluating the TOE are a combination of the workunits defined in [CEM] as well as the Evaluation Activities for ensuring that individual SFRs and SARs have a sufficient level of supporting evidence in the Security Target and guidance documentation and have been sufficiently tested by the laboratory as part of completing ATE_IND.1. Any functional packages this PP claims similarly contain their own Evaluation Activities that are used in this same manner.
CC Conformance Claims

This PP-Module is conformant to Part 2 (extended) and Part 3 (extended) of Common Criteria CC:2022, Revision 1.
PP Claim

This PP-Module does not claim conformance to any Protection Profile.

The following PPs and PP-Modules are allowed to be specified in a PP-Configuration with this PP-Module:
Package Claim

The functional packages to which the PP conforms may include SFRs that are not mandatory to claim for the sake of conformance. An ST that claims one or more of these functional packages may include any non-mandatory SFRs that are appropriate to claim based on the capabilities of the TSF and on any triggers for their inclusion based inherently on the SFR selections made.

3 Security Problem Definition

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.

3.1 Threats

The following threats are specific to WLAN Clients, and represent an addition to those identified in the Base-PPs.
T.TSF_FAILURE
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.
T.UNAUTHORIZED_ACCESS
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.
T.UNDETECTED_ACTIONS
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.

3.2 Assumptions

These assumptions are made on the Operational Environment (OE) in order to be able to ensure that the security functionality specified in the PP-Module can be provided by the TOE. If the TOE is placed in an OE that does not meet these assumptions, the TOE may no longer be able to provide all of its security functionality.
A.NO_TOE_BYPASS
Information cannot flow between the wireless client and the internal wired network without passing through the TOE.
A.TRUSTED_ADMIN
TOE Administrators are trusted to follow and apply all administrator guidance in a trusted manner.

3.3 Organizational Security Policies

An organization deploying the TOE is expected to satisfy the organizational security policy listed below in addition to all organizational security policies defined by the claimed Base-PP.

This document does not define any additional OSPs.

4 Security Objectives

4.1 Security Objectives for the Operational Environment

OE.NO_TOE_BYPASS
Information cannot flow between external and internal networks located in different enclaves without passing through the TOE.
OE.TRUSTED_ADMIN
TOE administrators are trusted to follow and apply all administrator guidance in a trusted manner.

4.2 Security Objectives Rationale

This section describes how the assumptions and organizational security policies map to operational environment security objectives.
Table 1: Security Objectives Rationale
Assumption or OSPSecurity ObjectivesRationale
A.NO_​TOE_​BYPASSOE.NO_​TOE_​BYPASSThe operational environment objective OE.NO_TOE_BYPASS is realized through A.NO_TOE_BYPASS.
A.TRUSTED_​ADMINOE.TRUSTED_​ADMINThe Operational Environment objective OE.TRUSTED ADMIN is realized through A.TRUSTED_ADMIN.

5 Security 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 and assurance components from Part 3 of [CC]. The following conventions are used for the completion of operations:

5.1 Protection Profile for General Purpose Operating System Security Functional Requirements Direction

In a PP-Configuration that includes the GPOS PP, the TOE is expected to rely on some of the security functions implemented by the Operating System as a whole and evaluated against the GPOS PP. The following sections describe any modifications that the ST author must make to the SFRs defined in the GPOS PP in addition to what is mandated by Section 5.3 TOE Security Functional Requirements.

5.1.1 Modified SFRs

This PP-Module does not modify any SFRs defined by the GPOS PP.

5.1.2 Additional SFRs

This PP-Module does not define any additional SFRs for any PP-Configuration where the GPOS PP is claimed as the Base-PP.

5.2 Protection Profile for Mobile Device Fundamentals Security Functional Requirements Direction

In a PP-Configuration that includes the MDF PP, the TOE is expected to rely on some of the security functions implemented by the Mobile Device as a whole and evaluated against the MDF PP. The following sections describe any modifications that the ST author must make to the SFRs defined in the MDF PP in addition to what is mandated by Section 5.3 TOE Security Functional Requirements.

5.2.1 Modified SFRs

This PP-Module does not modify any SFRs defined by the MDF PP.

5.2.2 Additional SFRs

This PP-Module does not define any additional SFRs for any PP-Configuration where the MDF PP is claimed as the Base-PP.

5.3 TOE Security Functional Requirements

The following section describes the SFRs that must be satisfied by any TOE that claims conformance to this PP-Module. These SFRs must be claimed regardless of which PP-Configuration is used to define the TOE.

5.3.1 Auditable Events for Mandatory SFRs

Table 2: Auditable Events for Mandatory Requirements
RequirementAuditable EventsAdditional Audit Record Contents
FAU_GEN.1/WLAN
No events specifiedN/A
FCS_CKM.1/WPA
No events specifiedN/A
FCS_CKM.2/WLAN
No events specifiedN/A
FCS_WPA_EXT.1
No events specifiedN/A
FIA_PAE_EXT.1
No events specifiedN/A
FIA_X509_EXT.1/WLAN
No events specifiedN/A
FIA_X509_EXT.2/WLAN
No events specifiedN/A
FIA_X509_EXT.6
Attempts to load certificates. No additional information
Attempts to revoke certificates. No additional information
FMT_SMF.1/WLAN
No events specifiedN/A
FPT_TST_EXT.3/WLAN
Execution of this set of TSF self-tests. No additional information
[selection: Detected integrity violation, None][selection: The TSF binary file that caused the integrity violation, No additional information]
FTA_WSE_EXT.1
All attempts to connect to access points.
  • For each access point record the [selection: Complete SSID and MAC, Certificate Check Message and the last [assignment: integer greater than or equal to 2] octets] of the MAC Address
  • Success and failures (including reason for failure).
FTP_ITC.1/WLAN
All attempts to establish a trusted channel.Identification of the non-TOE endpoint of the channel.

5.3.2 Security Audit (FAU)

FAU_GEN.1/WLAN Audit Data Generation (Wireless LAN)

The TSF shall [selection: invoke platform-provided functionality, implement functionality] to generate audit data of the following auditable events:
  1. Startup and shutdown of the audit functions;
  2. All auditable events for [not specified] level of audit;
  3. [all auditable events for mandatory SFRs specified in Table 2, selected SFRs in Table 11, applicable audit events specified in Functional Package for Transport Layer Security (TLS), version 2.1, and applicable audit events specified in Functional Package for X.509, version 1.0].
Application Note:

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 Table 11. If the TOE does not claim a particular selection-based SFR, it is not expected to generate any corresponding audit data for that SFR.

Table 2 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 [selection: TSF, TOE platform] shall record within the audit data at least the following information:
  1. Date and time of the event, type of event, subject identity, (if applicable), and the outcome (success or failure) of the event;
  2. For each audit event type, based on the auditable event definitions of the functional components included in the PP, PP-Module, functional package or ST, [Additional Audit Record Contents as specified in Table 2, Table 11, applicable audit events specified in Functional Package for Transport Layer Security (TLS), version 2.1, and applicable audit events specified in Functional Package for X.509, version 1.0].

5.3.3 Cryptographic Support (FCS)

FCS_CKM.1/WPA Cryptographic Key Generation (Symmetric Keys for WPA2/WPA3 Connections)

The TSF shall generate symmetric cryptographic keys in accordance with a specified cryptographic key generation algorithm [PRF-384 and [selection: PRF-512, PRF-704, no other algorithm] (as defined in IEEE 802.11-2020)] and specified cryptographic key sizes [256 bits] using a Random Bit Generator as specified in FCS_RBG.1.
Application Note:

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.

FCS_CKM.2/WLAN Cryptographic Key Distribution (Group Temporal Key for WLAN)

The TSF shall decrypt Group Temporal Key in accordance with a specified cryptographic key distribution method [AES Key Wrap (as defined in RFC 3394) in an EAPOL-Key frame (as defined in IEEE 802.11-2020 for the packet format and timing considerations] and does not expose the cryptographic keys.
Application Note: 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.

FCS_TLSC_EXT.1/WLAN TLS Client Protocol (EAP-TLS for WLAN)

This SFR defines EAP-TLS behavior specific for this PP-Module. The expectation is that this can now be inherited from the TLS FP rather than be defined here. However, we do not currently have a mechanism to tell ST authors what to do here. Specifically, we don't want to reproduce the SFR elements from the FP with whatever modifications are needed for the package because that causes the same problem that the FP was created to solve (having multiple sets of the same SFR that then get out of sync as documents don't all get updated at the same time). But at the same time, we need a way to communicate to the ST author how they should identify the SFR iteration (i.e. we would want it called "FCS_TLSC_EXT.1/WLAN" consistently in any ST that claims this module) as well as guidance on any required or forbidden selections in the context of the desired behavior (e.g. are there any ciphersuites we would want to ban ST authors from selecting).

Note that it may end up being the case that EAP-TLS also requires us to define behavior that is not part of the TLS FP. In this case we would still need to have guidance on what the ST author is expected to do with the TLS FP but then we would also need to keep an SFR here to cover the delta between the FP and the desired EAP-TLS functions. For the sake of avoiding confusion this would then be given a unique name (e.g. FCS_EAP_EXT.1).

FCS_WPA_EXT.1 Supported WPA Versions

The TSF shall support WPA3 and [selection: WPA2, no other] security type.
Application Note: 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.

5.3.4 Identification and Authentication (FIA)

FIA_PAE_EXT.1 Port Access Entity Authentication

The TSF shall conform to IEEE Standard 802.1X for a Port Access Entity (PAE) in the “Supplicant” role.
Application Note:

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.

FIA_X509_EXT.1/WLAN X.509 Certificate Validation

This SFR defines X.509 validation behavior specific for this PP-Module. The expectation is that this can now be inherited from the X.509 FP rather than be defined here. However, we do not currently have a mechanism to tell ST authors what to do here. Specifically, we don't want to reproduce the SFR elements from the FP with whatever modifications are needed for the package because that causes the same problem that the FP was created to solve (having multiple sets of the same SFR that then get out of sync as documents don't all get updated at the same time). But at the same time, we need a way to communicate to the ST author how they should identify the SFR iteration (i.e. we would want it called "FIA_X509_EXT.1/WLAN" consistently in any ST that claims this module) as well as guidance on any required or forbidden selections in the context of the desired behavior (e.g. prohibiting certain revocation methods from being used).

This SFR is only a subset of what the X.509 FP requires for certificate validation so it's unclear whether there are functions in the X.509 FP that cannot be satisfied by the X.509 functionality that is needed specifically for EAP-TLS. (i.e. is the definition of this function intentionally complete or will the FP version of it be usable?)

FIA_X509_EXT.2/WLAN X.509 Certificate Authentication (EAP-TLS for WLAN)

This SFR is just for defining the TOE's use of X.509 certificates for EAP-TLS. This can be covered by FIA_X509_EXT.2 from the X.509 FP but there is currently no way to instruct the ST author that this claim must be made there (whether as its own separate iteration as it is here or part of a single un-iterated FIA_X509_EXT.2 that also covers any other uses the TOE has for X.509).

FIA_X509_EXT.6 X.509 Certificate Storage and Management

The TSF shall [selection: store and protect, invoke [assignment: platform storage mechanism] to store and protect] certificate(s) from unauthorized deletion and modification.
The TSF shall [selection: provide the capability for authorized administrators to load X.509v3 certificates into the TOE, rely on [assignment: platform mechanism] to load X.509v3 certificates into [assignment: platform storage mechanism]] for use by the TSF.
Application Note: 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.

5.3.5 Security Management (FMT)

FMT_SMF.1/WLAN Specification of Management Functions (WLAN Client)

The TSF shall be capable of performing the following management functions:

Table 3: Management Functions

Status Markers:
M - Mandatory
O - Optional/Objective
#Management FunctionImplAdminUser
WL-1configure security policy for each wireless network:
  • [selection: specify the CA(s) from which the TSF will accept WLAN authentication server certificate(s), specify the Fully Qualified Domain Names (FQDNs) of acceptable WLAN authentication server certificate(s)],
  • security type,
  • authentication protocol,
  • client credentials to be used for authentication,
MMandatory
MMandatory
OOptional/Conditional
WL-2specify wireless networks (SSIDs) to which the TSF may connect
MMandatory
MMandatory
OOptional/Conditional
WL-3 enable/disable wireless network bridging capability (for example, bridging a connection between the WLAN and cellular radios to function as a hotspot) authenticated by [selection: pre-shared key, passcode, no authentication]
MMandatory
MMandatory
OOptional/Conditional
WL-4enable/disable certificate revocation list checking
OOptional/Conditional
OOptional/Conditional
OOptional/Conditional
WL-5disable ad hoc wireless client-to-client connection capability
OOptional/Conditional
OOptional/Conditional
OOptional/Conditional
WL-6disable roaming capability
OOptional/Conditional
OOptional/Conditional
OOptional/Conditional
WL-7enable/disable IEEE 802.1X pre-authentication
OOptional/Conditional
OOptional/Conditional
OOptional/Conditional
WL-8loading X.509 certificates into the TOE
OOptional/Conditional
OOptional/Conditional
OOptional/Conditional
WL-9revoke X.509 certificates loaded into the TOE
OOptional/Conditional
OOptional/Conditional
OOptional/Conditional
WL-10enable/disable and configure 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
OOptional/Conditional
OOptional/Conditional
OOptional/Conditional
WL-11configure security policy for each wireless network: set wireless frequency band to [selection: 2.4 GHz, 5 GHz, 6 GHz]
OOptional/Conditional
OOptional/Conditional
OOptional/Conditional
Application Note:

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.

5.3.6 Protection of the TSF (FPT)

FPT_TST_EXT.3/WLAN TSF Cryptographic Functionality Testing (WLAN Client)

The [selection: TOE, TOE platform] shall run a suite of self-tests during initial start-up (on power on) to demonstrate the correct operation of the TSF.
The [selection: TOE, TOE platform] shall provide the capability to verify the integrity of stored TSF executable code when it is loaded for execution through the use of the TSF-provided cryptographic services.
Application Note: 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.

5.3.7 TOE Access (FTA)

FTA_WSE_EXT.1 Wireless Network Access

The TSF shall be able to attempt connections only to wireless networks specified as acceptable networks as configured by the administrator in FMT_SMF.1.1/WLAN.
Application Note: The intent of this requirement is to allow the administrator to limit the wireless networks to which the TOE is allowed to connect.

5.3.8 Trusted Path/Channels (FTP)

FTP_ITC.1/WLAN Trusted Channel Communication (Wireless LAN)

The TSF shall use 802.11-2020, 802.1X, and EAP-TLS to provide a trusted communication channel between itself and a wireless access point that is logically distinct from other communication channels and provides assured identification of its end points and protection of the channel data from modification or disclosure.
The TSF shall permit [the TSF] to initiate communication via the trusted channel.
The TSF shall initiate communication via the trusted channel for [wireless access point connections].
Application Note:

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

5.4 TOE Security Functional Requirements Rationale

The following rationale provides justification for each SFR for the TOE, showing that the SFRs are suitable to address the specified threats:

Table 4: SFR Rationale
ThreatAddressed byRationale
T.TSF_​FAILURE
 FPT_TST_EXT.3/WLAN Mitigates the threat by performing self-tests to design if a TSF failure has occurred.
T.UNAUTHORIZED_​ACCESS
 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_TLSC_EXT.1/WLAN Mitigates the threat by implementing EAP-TLS for secure authentication of 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.1/WLAN Mitigates the threat by using X.509 for secure connectivity and non-repudiation of external IT entities.
FIA_X509_EXT.2/WLAN Mitigates the threat by using X.509 for secure connectivity and non-repudiation of external IT entities.
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.
FCS_TLSC_EXT.2/WLAN (selection-based) Mitigates the threat by defining secure connection parameters for EAP-TLS.
T.UNDETECTED_​ACTIONS
 FAU_GEN.1/WLAN Mitigates the threat by implementing a mechanism to detect actions performed on or by the TOE.

6 Consistency Rationale

6.1 Protection Profile for General Purpose Operating System

6.1.1 Consistency of TOE Type

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.

6.1.2 Consistency of Security Problem Definition

Table 5: Consistency of Security Problem Definition (GPOS PP base)
PP-Module Threat, Assumption, OSPConsistency Rationale
T.TSF_FAILUREThe 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.
T.UNAUTHORIZED_ACCESSThe 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.
T.UNDETECTED_ACTIONSThe 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.
A.NO_TOE_BYPASSThis 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.
A.TRUSTED_ADMINThe Base-PP defines A.PROPER_USER and A.PROPER_ADMIN assumptions that serve the same purpose as A.TRUSTED_ADMIN in this PP-Module.

6.1.3 Consistency of OE Objectives

Table 6: Consistency of OE Objectives (GPOS PP base)
PP-Module OE ObjectiveConsistency Rationale
OE.NO_TOE_BYPASSThis 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.
OE.TRUSTED_ADMINThe Base-PP defines OE.PROPER_USER and OE.PROPER_ADMIN objectives that serve the same purpose as OE.TRUSTED_ADMIN in this PP-Module.

6.1.4 Consistency of Requirements

This PP-Module identifies several SFRs from the GPOS PP that are needed to support WLAN Client functionality. This is considered to be consistent because the functionality provided by the GPOS PP is being used for its intended purpose. The rationale for why this does not conflict with the claims defined by the GPOS PP are as follows:
Table 7: Consistency of Requirements (GPOS PP base)
PP-Module RequirementConsistency Rationale
Modified SFRs
This PP-Module does not modify any requirements when the GPOS PP is the base.
Additional SFRs
This PP-Module does not add any requirements when the GPOS PP is the base.
Mandatory SFRs
FAU_GEN.1/WLANThe 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.
FCS_CKM.1/WPAThis 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.
FCS_CKM.2/WLANThis SFR requires the TOE to perform a decryption operation using AES Key Wrap, which is a function that the Base-PP provides.
FCS_TLSC_EXT.1/WLANThis SFR requires the TOE to implement EAP-TLS; this protocol relies on the same cryptographic functionality that the Base-PP uses to implement TLS.
FCS_WPA_EXT.1This 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.
FIA_PAE_EXT.1This 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.
FIA_X509_EXT.1/WLANThis 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.
FIA_X509_EXT.2/WLANThis 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.
FIA_X509_EXT.6This 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.
FMT_SMF.1/WLANThis 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.
FPT_TST_EXT.3/WLANThis 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.
FTA_WSE_EXT.1This 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.
FTP_ITC.1/WLANThis 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.
Optional SFRs
This PP-Module does not define any Optional requirements.
Objective SFRs
This PP-Module does not define any Objective requirements.
Implementation-dependent SFRs
This PP-Module does not define any Implementation-dependent requirements.
Selection-based SFRs
FCS_TLSC_EXT.2/WLANThis 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.

6.2 Protection Profile for Mobile Device Fundamentals

6.2.1 Consistency of TOE Type

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.

6.2.2 Consistency of Security Problem Definition

Table 8: Consistency of Security Problem Definition (MDF PP base)
PP-Module Threat, Assumption, OSPConsistency Rationale
T.TSF_FAILURE 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.
T.UNAUTHORIZED_ACCESS 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.
T.UNDETECTED_ACTIONS 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.
A.NO_TOE_BYPASS 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.
A.TRUSTED_ADMIN The Base-PP defines the A.TRUSTED_ADMIN assumptions that expects administrators will configure the TOE correctly, which also implies they are non-malicious.

6.2.3 Consistency of OE Objectives

Table 9: Consistency of OE Objectives (MDF PP base)
PP-Module OE ObjectiveConsistency Rationale
OE.NO_TOE_BYPASS 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.
OE.TRUSTED_ADMIN The Base-PP defines the OE.CONFIG objective that expects administrators will configure the TOE correctly, which also implies they are non-malicious.

6.2.4 Consistency of Requirements

This PP-Module identifies several SFRs from the MDF PP that are needed to support WLAN Client functionality. This is considered to be consistent because the functionality provided by the MDF PP is being used for its intended purpose. The rationale for why this does not conflict with the claims defined by the MDF PP are as follows:
Table 10: Consistency of Requirements (MDF PP base)
PP-Module RequirementConsistency Rationale
Modified SFRs
This PP-Module does not modify any requirements when the MDF PP is the base.
Additional SFRs
This PP-Module does not add any requirements when the MDF PP is the base.
Mandatory SFRs
FAU_GEN.1/WLAN 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.
FCS_CKM.1/WPAThis 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 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.
FCS_CKM.2/WLANThis SFR requires the TOE to perform a decryption operation using AES Key Wrap, which is a function that the Base-PP provides.
FCS_TLSC_EXT.1/WLANThis SFR requires the TOE to implement EAP-TLS; this protocol relies on the same cryptographic functionality that the Base-PP uses to implement TLS.
FCS_WPA_EXT.1This 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.
FIA_PAE_EXT.1This 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.
FIA_X509_EXT.1/WLANThis 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.
FIA_X509_EXT.2/WLANThis 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.
FIA_X509_EXT.6This 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.
FMT_SMF.1/WLANThis 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.
FPT_TST_EXT.3/WLANThis 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.
FTA_WSE_EXT.1This 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.
FTP_ITC.1/WLANThis 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.
Optional SFRs
This PP-Module does not define any Optional requirements.
Objective SFRs
This PP-Module does not define any Objective requirements.
Implementation-dependent SFRs
This PP-Module does not define any Implementation-dependent requirements.
Selection-based SFRs
FCS_TLSC_EXT.2/WLANThis 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.

Appendix A - Optional SFRs

A.1 Strictly Optional Requirements

This PP-Module does not define any Strictly Optional SFRs or SARs.

A.2 Objective Requirements

This PP-Module does not define any Objective SFRs.

A.3 Implementation-dependent Requirements

This PP-Module does not define any Implementation-dependent SFRs.

Appendix B - Selection-based Requirements

B.1 Auditable Events for Selection-based SFRs

Table 11: Auditable Events for Selection-based Requirements
RequirementAuditable EventsAdditional Audit Record Contents

B.2 Cryptographic Support (FCS)

FCS_TLSC_EXT.2/WLAN TLS Client Support for Supported Groups Extension (EAP-TLS for WLAN)

This SFR is just for defining the supported groups that are offered in the TLS client hello. This is part of the TLS FP natively so it is expected that this SFR can be removed. It is being kept here for now as a placeholder until the appropriate way to handle defining a TLS iteration for WLAN EAP-TLS (FCS_TLSC_EXT.1/WLAN) is determined.

Appendix C - Extended Component Definitions

This appendix contains the definitions for all extended requirements specified in the PP-Module.

C.1 Extended Components Table

All extended components specified in the PP-Module are listed in this table:
Table 12: Extended Component Definitions
Functional ClassFunctional Components
Cryptographic Support (FCS)FCS_WPA_EXT Supported WPA Versions
Identification and Authentication (FIA)FIA_PAE_EXT Port Access Entity Authentication
FIA_X509_EXT X.509 Certificate Use and Management
Protection of the TSF (FPT)FPT_TST_EXT TSF Self-Test
TOE Access (FTA)FTA_WSE_EXT Wireless Network Access

C.2 Extended Component Definitions

C.2.1 Cryptographic Support (FCS)

This PP-Module defines the following extended components as part of the FCS class originally defined by CC Part 2:

C.2.1.1 FCS_WPA_EXT Supported WPA Versions

Family Behavior

Components in this family define requirements for supporting Wi-Fi Protected Access (WPA).

Component Leveling

FCS_WPA_EXT1

FCS_WPA_EXT.1, Supported WPA Versions, requires the TSF to support WPA3 at minimum, with optional support for WPA2.

Management: FCS_WPA_EXT.1

The following actions could be considered for the management functions in FMT:

  • Configure the supported WPA versions.

Audit: FCS_WPA_EXT.1

There are no auditable events foreseen.

FCS_WPA_EXT.1 Supported WPA Versions

Hierarchical to:No other components.
Dependencies to:FCS_COP.1 Cryptographic Operation

FCS_WPA_EXT.1.1

The TSF shall support WPA3 and [selection: WPA2, no other] security type.

C.2.2 Identification and Authentication (FIA)

This PP-Module defines the following extended components as part of the FIA class originally defined by CC Part 2:

C.2.2.1 FIA_PAE_EXT Port Access Entity Authentication

Family Behavior

Components in this family define requirements for TOE support of IEEE 802.1X authentication.

Component Leveling

FIA_PAE_EXT1

FIA_PAE_EXT.1, Port Access Entity Authentication, describes the ability of the TOE to act as a supplicant for 802.1X authentication.

Management: FIA_PAE_EXT.1

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.

Audit: FIA_PAE_EXT.1

There are no auditable events foreseen.

FIA_PAE_EXT.1 Port Access Entity Authentication

Hierarchical to:No other components.
Dependencies to:No dependencies.

FIA_PAE_EXT.1.1

The TSF shall conform to IEEE Standard 802.1X for a Port Access Entity (PAE) in the “Supplicant” role.

C.2.2.2 FIA_X509_EXT X.509 Certificate Use and Management

Family Behavior

Components in this family define requirements for the use of X.509 certificates.

Component Leveling

FIA_X509_EXT6

FIA_X509_EXT.6, X.509 Certificate Storage and Management, requires the TOE to implement the ability to store X.509 certificates.

Management: FIA_X509_EXT.6

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.

Audit: FIA_X509_EXT.6

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.

FIA_X509_EXT.6 X.509 Certificate Storage and Management

Hierarchical to:No other components.
Dependencies to:No dependencies.

FIA_X509_EXT.6.1

The TSF shall [selection: store and protect, invoke [assignment: platform storage mechanism] to store and protect] certificate(s) from unauthorized deletion and modification.

FIA_X509_EXT.6.2

The TSF shall [selection: provide the capability for authorized administrators to load X.509v3 certificates into the TOE, rely on [assignment: platform mechanism] to load X.509v3 certificates into [assignment: platform storage mechanism]] for use by the TSF.

C.2.3 Protection of the TSF (FPT)

This PP-Module defines the following extended components as part of the FPT class originally defined by CC Part 2:

C.2.3.1 FPT_TST_EXT TSF Self-Test

Family Behavior

Components in this family define requirements for self-testing to verify the functionality and integrity of the TOE.

Component Leveling

FPT_TST_EXT3

FPT_TST_EXT.3, TSF Cryptographic Functionality Testing, requires the TOE or its platform to perform power on self-tests to verify its functionality and the integrity of its stored executable code.

Management: FPT_TST_EXT.3

No management functions are foreseen.

Audit: FPT_TST_EXT.3

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.

FPT_TST_EXT.3 TSF Cryptographic Functionality Testing

Hierarchical to:No other components.
Dependencies to:FCS_COP.1 Cryptographic Operation

FPT_TST_EXT.3.1

The [selection: TOE, TOE platform] shall run a suite of self-tests during initial start-up (on power on) to demonstrate the correct operation of the TSF.

FPT_TST_EXT.3.2

The [selection: TOE, TOE platform] shall provide the capability to verify the integrity of stored TSF executable code when it is loaded for execution through the use of the TSF-provided cryptographic services.

C.2.4 TOE Access (FTA)

This PP-Module defines the following extended components as part of the FTA class originally defined by CC Part 2:

C.2.4.1 FTA_WSE_EXT Wireless Network Access

Family Behavior

Components in this family define requirements for specifying wireless networks that the TOE can connect to.

Component Leveling

FTA_WSE_EXT1

FTA_WSE_EXT.1, Wireless Network Access, describes the ability of the TOE to apply administrative limits on the wireless networks that it can connect to.

Management: FTA_WSE_EXT.1

The following actions could be considered for the management functions in FMT:

  • Specify allowed wireless networks based on Service Set Identifier (SSID).

Audit: FTA_WSE_EXT.1

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.

FTA_WSE_EXT.1 Wireless Network Access

Hierarchical to:No other components.
Dependencies to:FMT_SMF.1 Specification of Management Functions

FTA_WSE_EXT.1.1

The TSF shall be able to attempt connections only to wireless networks specified as acceptable networks as configured by the administrator in FMT_SMF.1.1/WLAN.

Appendix D - Implicitly Satisfied Requirements

This appendix lists requirements that should be considered satisfied by products successfully evaluated against this PP-Module. These requirements are not featured explicitly as SFRs and should not be included in the ST. They are not included as standalone SFRs because it would increase the time, cost, and complexity of evaluation. This approach is permitted by [CC] Part 1, 8.3 Dependencies between components.

This information benefits systems engineering activities which call for inclusion of particular security controls. Evaluation against the PP-Module provides evidence that these controls are present and have been evaluated.

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.

Appendix E - Entropy Documentation and Assessment

The TOE does not require any additional supplementary information to describe its entropy sources beyond the requirements outlined in the Base-PPs.

Appendix F - Acronyms

Table 13: Acronyms
AcronymMeaning
AESAdvanced Encryption Standard
APAccess Point
ASAuthentication Server
Base-PPBase Protection Profile
CACertification Authority
CBCCipher Block Chaining
CCCommon Criteria
CCEVSCommon Criteria Evaluation and Validation Scheme
CCMPCounter mode CBC-MAC Protocol
CCTLCommon Criteria Test Laboratory
CEMCommon Evaluation Methodology
cPPCollaborative Protection Profile
CSPCritical Security Parameter
EAPExtensible Authentication Protocol
EAPOLEAP over LAN
EPExtended Package
FIPSFederal Information Processing Standards
FPFunctional Package
FQDNFully Qualified Domain Name
GPOSGeneral-Purpose Operating System
GTKGroup Temporal Key
HMACHash-Based Message Authentication Code
IECInternational Electrotechnical Commission
IEEEInstitute of Electrical and Electronics Engineers
ISOInternational Organization for Standardization
ITInformation Technology
KDFKey Derivation Function
LANLocal Area Network
MACMessage Authentication Code (cryptography) or Media Control Address (system property)
MDFMobile Device Fundamentals
NIAPNational Information Assurance Partnership
NVLAPNational Voluntary Laboratory Accreditation Program
OEOperational Environment
OSPOrganizational Security Policy
PAEPort Access Entity
PINPersonal Identification Number
PKIPublic Key Infrastructure
PMKPairwise Master Key
PPProtection Profile
PPProtection Profile
PP-ConfigurationProtection Profile Configuration
PP-ModuleProtection Profile Module
PRFPseudo-Random Function
PTKPairwise Temporal Key
RBGRandom Bit Generator
RFRadio Frequency
RFCRequest for Comment
SARSecurity Assurance Requirement
SFRSecurity Functional Requirement
SFRSecurity Functional Requirement
SHASecure Hash Algorithm
SSIDService Set Identifier
STSecurity Target
STSecurity Target
TLSTransport Layer Security
TOETarget of Evaluation
TOETarget of Evaluation
TSFTOE Security Function
TSFTOE Security Functionality
TSFITSF Interface
TSSTOE Summary Specification
TSSTOE Summary Specification
WLANWireless Local Area Network
WPAWireless Protected Access

Appendix G - Bibliography

Table 14: Bibliography
IdentifierTitle
[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
[CC]Common Criteria for Information Technology Security Evaluation -
[CEM]Common Methodology for Information Technology Security Evaluation -
[GPOS]Protection Profile for General Purpose Operating Systems, Version 5.0, September 27, 2022 Adjust date when published.
[MDF]Protection Profile for Mobile Device Fundamentals, Version 4.0, September 12, 2022 Adjust date when published.
[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)