Comment: Comment-1-
Comment: Comment-2-
Comment: Comment-3-

PP-Module for Wireless Local Area Network (WLAN) Access Systems

NIAP Logo
Version: 2.0
2025-03-31
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.
Mandated Distributed TOE
1.02022-03-31Initial Release
2.02025-03-31Incorporate NIAP Technical Decisions, Update to CC:2022

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.1Collaborative Protection Profile for Network Device Security Functional Requirements Direction 5.1.1 Modified SFRs 5.1.1.1Class FCS: Cryptographic Support5.1.1.2Class FTP: Trusted Path/Channels5.2TOE Security Functional Requirements5.2.1Auditable Events for Mandatory SFRs5.2.2Class FAU: Security Audit5.2.3Class FCS: Cryptographic Support5.2.4Class FIA: Identification and Authentication5.2.5Class FMT: Security Management5.2.6Class FTA: TOE Access5.2.7Class FTP: Trusted Path/Channels5.3TOE Security Functional Requirements Rationale6Consistency Rationale6.1Collaborative Protection Profile for Network Device6.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 Appendix A - Optional SFRsA.1Strictly Optional Requirements A.1.1Auditable Events for Optional SFRsA.1.2Class FCS: Cryptographic SupportA.2Objective Requirements A.3Implementation-dependent Requirements Appendix B - Selection-based Requirements B.1Auditable Events for Selection-Based SFRsB.2Class FCS: Cryptographic SupportB.3Class FIA: Identification and AuthenticationAppendix C - Extended Component DefinitionsC.1Extended Components TableC.2Extended Component DefinitionsC.2.1Class FCS: Cryptographic SupportC.2.1.1FCS_RADSEC_EXT RadSecC.2.2Class FIA: Identification and AuthenticationC.2.2.1FIA_8021X_EXT 802.1X Port Access Entity (Authenticator) AuthenticationC.2.2.2FIA_PSK_EXT Pre-Shared Key CompositionC.2.3Class FMT: Security ManagementC.2.3.1FMT_SMR_EXT Security Management RestrictionsAppendix D - Implicitly Satisfied RequirementsAppendix E - Allocation of Requirements in Distributed TOEsAppendix F - Entropy Documentation and AssessmentAppendix G - AcronymsAppendix H - Bibliography

1 Introduction

1.1 Overview

The scope of this PP-Module is to describe the security functionality of a Wireless Local Area Network (WLAN) Access System (AS) 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-PP:

This Base-PP is valid because a WLAN AS is a device at the edge of a private network that establishes an encrypted IEEE 802.11 link that protects wireless data in transit from disclosure and modification. A network device typically implements this functionality.

Access Point (AP)

A TOE that conforms to a Protection Profile Configuration (PP-Configuration) containing this PP-Module can either be a standalone or distributed TOE as defined in the NDcPP. For distributed TOEs, the expectation for this PP-Module is that a WLAN AS is composed of a single controller and one or more access points (APs).

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.
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.
Service Set Identifier (SSID)
 The primary name associated with an 802.11 wireless local area network (WLAN).
Wireless Local Area Network (WLAN)
 A wireless computer network that links two or more devices using wireless communication to form a local area network within a limited area such as a home, school, computer laboratory, campus, office building, etc.

1.3 Compliant Targets of Evaluation

1.3.1 TOE Boundary

This PP-Module specifically addresses WLAN (IEEE 802.11) ASes. A compliant WLAN AS is a system composed of hardware and software that is connected to a network and has an infrastructure role in the overall enterprise network. In particular, a WLAN AS establishes a secure wireless (IEEE 802.11) link that provides an authenticated and encrypted path to an enterprise network and thereby decreases the risk of exposure of information transiting “over-the-air”.

Since this PP-Module extends the NDcPP, conformant TOEs are obligated to implement the functionality required in the NDcPP along with the additional functionality defined in this PP-Module in response to the threat environment discussed subsequently herein.

1.4 Use Cases

[USE CASE 1] Standalone Device
The TOE is a standalone network device that serves as a single network endpoint providing connectivity to wireless clients.
[USE CASE 2] Distributed System
The TOE is a distributed system consisting of multiple network devices that collectively serve as the wireless network endpoint. In addition to claiming the relevant "Distributed TOE" requirement in the NDcPP, this use case also requires the TOE to claim the optional SFR FCS_CKM.2/DISTRIB to describe the key distribution method between distributed TOE components.

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 (conformant) 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 network packets cross the boundary between a wired private network and a wireless client via a WLAN AS. The WLAN Access System provides secure communication between a user (wireless client) and a wired (trusted) network by supporting security functions such as administration, authentication, encryption, and the protection and handling of data in transit. To protect the data in transit from disclosure and modification, a WLAN AS is used to establish secure communications. The WLAN AS provides one end of the secure cryptographic tunnel and performs encryption and decryption of network packets in accordance with a WLAN AS security policy negotiated with its authenticated wireless client. It supports multiple simultaneous wireless connections and is capable of establishing and terminating multiple cryptographic tunnels to and from those peers.

The proper installation, configuration, and administration of the WLAN AS are critical to its correct operation.

Note that this PP-Module does not repeat the threats identified in the NDcPP, though they all apply given the conformance and hence dependence of this PP-Module on the NDcPP. Note also that while the NDcPP contains only threats to the ability of the TOE to provide its security functions, this PP-Module addresses only threats to resources in the Operational Environment (OE). Together the threats of the NDcPP and those defined in this PP-Module define the comprehensive set of security threats addressed by a WLAN AS TOE.

3.1 Threats

T.NETWORK_DISCLOSURE
Devices on a protected network may be exposed to threats presented by devices located outside the protected network, which may attempt to conduct unauthorized activities. If malicious external devices are able to communicate with devices on the protected network, or if devices on the protected network can establish communications with those external devices (e.g., as a result of nonexistent or insufficient WLAN data encryption that exposes the WLAN data in transit to rogue elements), then those internal devices may be susceptible to the unauthorized disclosure of information.
T.NETWORK_ACCESS
Devices located outside the protected network may seek to exercise services located on the protected network that are intended to be only accessed from inside the protected network or only accessed by entities using an authenticated path into the protected network.
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.DATA_INTEGRITY
Devices on a protected network may be exposed to threats presented by devices located outside the protected network, which may attempt to modify the data without authorization. If known malicious external devices are able to communicate with devices on the protected network or if devices on the protected network can establish communications with those external devices then the data contained within the communications may be susceptible to a loss of integrity.
T.REPLAY_ATTACK
If an unauthorized individual successfully gains access to the system, the adversary may have the opportunity to conduct a “replay” attack. This method of attack allows the individual to capture packets traversing throughout the wireless network and send the packets at a later time, possibly unknown by the intended receiver.

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. All assumptions for the OE of the Base-PP also apply to this PP-Module. A.NO_THRU_TRAFFIC_PROTECTION is still operative, but only for the interfaces in the TOE that are defined by the Base-PP and not the PP-Module.
A.CONNECTIONS
It is assumed that the TOE is connected to distinct networks in a manner that ensures that the TOE's security policies will be enforced on all applicable network traffic flowing among the attached networks.

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

All objectives for the OE of the Base-PP also apply to this PP-Module. OE.NO_THRU_TRAFFIC_PROTECTION is still operative, but only for the interfaces in the TOE that are defined by the Base-PP and not the PP-Module.
OE.CONNECTIONS
TOE administrators will ensure that the TOE is installed in a manner that will allow the TOE to effectively enforce its policies on the network traffic of monitored networks.

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.CONNECTIONSOE.CONNECTIONS The OE objective OE.CONNECTIONS is realized through A.CONNECTIONS.

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 Collaborative Protection Profile for Network Device Security Functional Requirements Direction

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

5.1.1 Modified SFRs

The SFRs listed in this section are defined in the NDcPP and relevant to the secure operation of the TOE.

5.1.1.1 Class FCS: Cryptographic Support

FCS_COP.1/AEAD: Cryptographic Operation - Authenticated Encryption with Associated Data

This SFR has been modified frmo its definition in the NDcPP to mandate selection of AES-CCM mode and 256-bit key sizes. Other selections may still be made if they are needed for other part of the TSF.

The text of FCS_COP.1.1/AEAD is replaced with:

FCS_COP.1.1/AEAD The TSF shall perform [authenticated encryption with associated data] in accordance with a specified cryptographic algorithm [selection: Cryptographic algorithm] and cryptographic key sizes [selection: Cryptographic key sizes] that meet the following: [selection: List of standards].

The following table provides the allowable choices for completion of the selection operations of FCS_COP.1.1/AEAD. In the last column, an X indicates it is mandatory for the ST author to include this row, and an O indicates that the row is optional and need not be included in the table if the TSF does not perform that function. Note that it is not necessary for the ST author to reproduce this final column in the ST.

Allowable choices for FCS_COP.1/AEAD:
Identifier Cryptographic algorithm Cryptographic Key Sizes List of standards Mandatory or Optional
AES-CCM AES in CCM mode with unpredictable, non-repeating nonce, minimum size of 64 bits 256 bits

[selection: ISO/IEC 18033-3:2010 (Subclause 5.2), FIPS PUB 197] [AES]

[selection: ISO/IEC 19772:2020 (Clause 7), NIST SP 800-38C] [CCM]

 X
AES-GCM AES in GCM mode with non-repeating IVs using [selection: deterministic, RBG-based], IV construction; the tag must be of length [selection: 96, 104, 112, 120, 128] bits. 256 bits

[selection: ISO/IEC 18033-3:2010 (Subclause 5.2), FIPS PUB 197] [AES]

[selection: ISO/IEC 19772:2020 (Clause 10), NIST SP 800-38D] [GCM]

 O

FCS_COP.1/DataEncryption: Cryptographic Operation (AES Data Encryption/Decryption)

This SFR has been modified from its definition in the NDcPP to mandate the inclusion of CCM mode as defined in FCS_COP.1/AEAD.

The text of FCS_COP.1.1/DataEncryption is replaced with:

FCS_COP.1.1/DataEncryption The TSF shall perform encryption/decryption in accordance with a specified cryptographic algorithm AES operating in CCM mode as defined in FCS_COP.1/AEAD and [selection:

].

Application Note: This requirement is modified from its definition in the NDcPP by mandating the selection of CCM mode in support of AES-CCMP as defined in IEEE 802.11-2020. If the TOE supports AES-GCMP as defined in IEEE 802.11ax-2021, support for GCM mode is also selected. Other AES modes are selectable if needed by another part of the TSF (e.g., CBC mode would need to be supported if the TOE provides VPN gateway functionality and supports AES-CBC for ESP) but are not required specifically for conformance to this PP-module. A selection for 'no other modes' has not been added as it is expected that a conformant TOE will require the use of at least one of CBC, CTR, XTS, and GCM modes to function in its evaluated configuration.

5.1.1.2 Class FTP: Trusted Path/Channels

FTP_ITC.1: Inter-TSF Trusted Channel

This SFR has been modified from its definition in the Base-PP to mandate communications protocols that are necessary for a WLAN AS. Any element that is not mentioned in this section is unchanged from its definition in the Base-PP.

The text of FTP_ITC.1.1 is replaced with:

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

Application Note: This requirement has been modified from its definition in the NDcPP to mandate the communications protocols and environmental components that a WLAN AS must use for infrastructure communications (802.11 support is also required for wireless client communications, but this is covered by the FTP_ITC.1/Client SFR in this PP-Module). IPsec or RADIUS over TLS (commonly known as "RadSec") is required at least for communications with the 802.1X authentication server. Other selections may be made if needed by other parts of the TSF. The requirement implies that not only are communications protected when they are initially established, but also on resumption after an outage.

The IT entity of "802.1X authentication server" is distinct from "authentication server" because the latter may be used for administrator authentication rather than authorization of WLAN clients.

If "IPsec" is selected in FTP_ITC.1.1, then FCS_IPSEC_EXT.1 from the NDcPP must be claimed. If "RADIUS over TLS" is selected in FTP_ITC.1.1, then FCS_RADSEC_EXT.1 in this PP-Module must be claimed, as well as FCS_TLSC_EXT.1 from the Functional Package for TLS, version 2.0. SSH is defined in the Functional Package for SSH, version 2.0.

5.2 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.2.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/GTK
No events specifiedN/A
FCS_CKM.2/PMK
No events specifiedN/A
FIA_8021X_EXT.1
Attempts to access the 802.1X controlled port prior to successful completion of the authentication exchange. Provided client identity (e.g. Media Access Control [Media Access Control (MAC)] address).
Failed authentication attempt. Provided client identity (e.g. MAC address).
FIA_UAU.6
Attempts to re-authenticate. Origin of the attempt (e.g., IP address).
FMT_SMF.1/AccessSystem
No events specifiedN/A
FMT_SMR_EXT.1
No events specifiedN/A
FTA_TSE.1
Denial of a session establishment due to the session establishment mechanism. Reason for denial, origin of establishment attempt.
FTP_ITC.1/Client
No events specifiedN/A

5.2.2 Class FAU: Security Audit

FAU_GEN.1/WLAN Audit Data Generation

The TSF shall be able to generate audit data of the following auditable events:
  1. Start-up and shutdown of the audit functions;
  2. All auditable events for the [not specified] level of audit; and
  3. [Auditable events listed in the Auditable Events for Mandatory SFRs table (Table 2)
    The modified audit events for FCS_IPSEC_EXT.1 and FTP_ITC.1 have been omitted from the respective audit tables due to a change in the syntax making it impossible to add an audit entry for an SFR that is not defined within the PP-Module itself. The modifications made to these SFRs' audit events can likely be covered through application of the original audit events or modification to the NDcPP itself. If this is insufficient, these SFRs may need to be converted to iterations instead of modified SFRs.
  4. Failure of wireless sensor communication
    5. ]
.
Application Note:

The auditable events defined in Table 2, Table 7, and Table 8 are for the SFRs that are explicitly defined in this PP-Module and are intended to extend FAU_GEN.1 in the Base-PP (only Table 2 is referenced in the SFR because the SFRs in the other sections do not have any associated auditable events). The events in the Auditable Events table should be combined with those of the NDcPP in the context of a conforming Security Target.

If the ST includes any selection-based SFRs, the selection for "Auditable events listed in the Auditable Events for Selection-Based SFRs table" must be selected. If no selection-based SFRs are included, "no other events" should be selected. The Auditable Events for Selection-Based SFRs (Table 8) include audit records for selection-based SFRs. The auditing of selection-based SFRs is only required if that SFR is included in the ST.

Per FAU_STG.1 in the Base-PP, the TOE must support transfer of the audit data to an external IT entity using a trusted channel.

The TSF shall record within the audit data at least the following information:
  1. Date and time of the auditable event, type of event, subject identity (if applicable), and the outcome (success or failure) of the event;
  2. For each auditable event type, based on the auditable event definitions of the functional components included in the PP, PP-Module, functional package or ST, [ information specified in column three of the Auditable Events table in which the auditable event was defined].
Evaluation Activities
FAU_GEN.1/WLAN
TSS
There are no TSS evaluation activities for this SFR.

Guidance
There are no operational guidance activities for this SFR.

Tests
The evaluator shall test the TOE’s ability to correctly generate audit records by having the TOE generate audit records 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 records generated during testing match the format specified in the administrative guide and that the fields in each audit record have the proper entries.

Note that the testing here can be accomplished in conjunction with the testing of the security mechanisms directly.

5.2.3 Class FCS: Cryptographic Support

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

It's not clear how CNSA 1.0 requirements are applied (if at all) to 802.11 crypto. This comment also applies to FCS_CKM.2/GTK and FCS_CKM.2/PMK. No substantive changes have been made to these SFRs yet. 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]] and specified cryptographic key sizes [256 bits and [selection: 128 bits, 192 bits, no other key sizes]] using a Random Bit Generator as specified in FCS_RBG.1 that meet the following: [IEEE 802.11-2020 and [selection: IEEE 802.11ax-2021, no other standards]].
Application Note:

The cryptographic key derivation algorithm required by IEEE 802.11-2020 (Section 12.7.1.2) and verified in WPA2 certification is PRF-384, which uses the HMAC-SHA-1 function and outputs a 384 bit key. The use of GCMP is defined in IEEE 802.11ax-2021 (Section 12.5.5) and requires a Key Derivation Function (KDF) based on HMAC-SHA-256 (for 128-bit symmetric keys) or HMAC-SHA-384 (for 256-bit symmetric keys). This KDF outputs 704 bits.

This requirement applies only to the keys that are generated or derived for the communications between the AP and the client once the client has been authenticated. It refers to the derivation of the Group Temporal Key (GTK), through the Random Bit Generator (RBG) specified in this PP-Module, as well as the derivation of the Pairwise Transient Key (PTK) from the Pairwise Master Key (PMK), which is done using a random value generated by the RBG specified in this PP-Module, the HMAC function as specified in this PP-Module, as well as other information. This is specified in IEEE 802.11-2020, primarily in chapter 12. FCS_RBG.1 is defined in the NDcPP.

Evaluation Activities
FCS_CKM.1/WPA
TSS
The cryptographic primitives will be verified through evaluation activities specified elsewhere in this PP-Module. 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. This description will include how the GTK and PTK are generated or derived. The TSS will also provide a description of the developer’s methods of assuring that their implementation conforms to the cryptographic standards; this includes not only testing done by the developing organization, but also proof of third-party testing that is performed (e.g. WPA2 certification). The evaluator shall ensure that the description of the testing methodology is of sufficient detail to determine the extent to which the details of the protocol specifics are tested.

Guidance
There are no guidance evaluation activities for this component.

Tests
The evaluator shall perform the following test using a packet sniffing tool to collect frames between the TOE and a wireless client:

Step 1: The evaluator shall configure the AP 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 client.

Step 2: The evaluator shall configure the TOE to communicate with a WLAN client 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 WLAN client, and allow the TOE to authenticate, associate, and successfully complete the four-way handshake with the client.

Step 4: The evaluator shall set a timer for one minute, at the end of which the evaluator will disconnect the client from the TOE and stop the sniffer.

Step 5: The evaluator shall identify the four-way handshake frames (denoted EAPOL-key in Wireshark captures) and derive the PTK from the four-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 client and TOE after the four-way handshake successfully completed and without the frame control value 0x4208 (the first two 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 verify that the decrypted data contains ASCII-readable text.

Step 7: The evaluator shall repeat Step 6 for the next two data frames between the TOE and client, and without frame control value 0x4208.

Additionally, the evaluator shall test the PRF function using the test vectors from:

  • Section 2.4 “The PRF Function – PRF (key, prefix, data, length)” of the IEEE 802.11-02/362r6 document "Proposed Test vectors for IEEE 802.11 TGi" dated September 10, 2002
  • Annex J.3 “PRF reference implementation and test vectors” of IEEE 802.11-2020

FCS_CKM.2/GTK Cryptographic Key Distribution (GTK)

The TSF shall distribute Group Temporal Key (GTK) in accordance with a specified cryptographic key distribution method: [selection: AES Key Wrap in an EAPOL-Key frame, AES Key Wrap with Padding in an EAPOL-Key frame] that meets the following: [NIST SP 800-38F, 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 generated by the TOE for use in broadcast and multicast messages to clients to which it is 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 NIST SP 800-38F.
Evaluation Activities
FCS_CKM.2/GTK
TSS
The evaluator shall check the TSS to ensure that it describes how the GTK is wrapped prior to being distributed using the AES implementation specified in this PP-Module, and also how the GTKs are distributed when multiple clients connect to the TOE.

Guidance
There are no guidance evaluation activities for this component.

Tests
The evaluator shall perform the following test using a packet sniffing tool to collect frames between a wireless client and the TOE (which may be performed in conjunction with the evaluation activity for FCS_CKM.1/PMK.

To fully test the broadcast and multicast functionality, these steps will be performed as the evaluator connects multiple clients to the TOE. The evaluator shall ensure that GTKs established are sent to the appropriate participating clients.

Step 1: The evaluator shall configure the AP 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 client.

Step 2: The evaluator shall configure the TOE to communicate with the client 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 client, and allow the client to authenticate, associate and successfully complete the four-way handshake with the TOE.

Step 4: The evaluator shall set a timer for one minute, at the end of which the evaluator will disconnect the TOE from the client and stop the sniffer.

Step 5: The evaluator shall identify the four-way handshake frames (denoted EAPOL-key in Wireshark captures) and derive the PTK and GTK from the four-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 client after the four-way handshake successfully completed, and with the frame control value 0x4208 (the first two 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 verify that the decrypted data contains ASCII-readable text.

Step 7: The evaluator shall repeat Step 6 for the next two data frames with frame control value 0x4208.

The evaluator shall also perform the following testing based on the supported GTK distribution methods:

AES Key Wrap (AES-KW Tests)

  • Test FCS_CKM.2/GTK:1: The evaluator shall test the authenticated encryption functionality of AES-KW for each combination of the following input parameter lengths:
    • 128 and 256 bit key encryption keys (KEKs)
    • Three plaintext lengths:
      1. One of the plaintext lengths will be two semi-blocks (128 bits).
      2. One of the plaintext lengths will be three semi-blocks (192 bits).
      3. The third data unit length will be the longest supported plaintext length less than or equal to 64 semi-blocks (4096 bits).
    For each combination, generate a set of 100 key and plaintext pairs and obtain the ciphertext that results from AES-KW authenticated encryption. To determine correctness, the evaluator shall use the same key and plaintext values and encrypt them using a known good implementation of AES-KW authenticated-encryption, and ensure that the resulting respective ciphertext values are identical.
  • Test FCS_CKM.2/GTK:2: The evaluator shall test the authenticated-decryption functionality of AES-KW using the same test as for authenticated-encryption, replacing plaintext values with ciphertext values and AES-KW authenticated-encryption with AES-KW authenticated-decryption. Additionally, the evaluator shall modify one byte of the ciphertext, attempt to decrypt the modified ciphertext, and ensure that a failure is returned rather than plaintext.

AES Key Wrap with Padding (AES-KWP Tests)

  • Test FCS_CKM.2/GTK:3:

    The evaluator shall test the authenticated-encryption functionality of AES-KWP for each combination of the following input parameter lengths:

    128 and 256 bit key encryption keys (KEKs)

    Three plaintext lengths. One plaintext length will be one octet. One plaintext length will be 20 octets (160 bits). One plaintext length will be the longest supported plaintext length less than or equal to 512 octets (4096 bits).

    Use a set of 100 key and plaintext pairs and obtain the ciphertext that results from AES-KWP authenticated encryption. To determine correctness, the evaluator shall use the AES-KWP authenticated-encryption function of a known good implementation.

  • Test FCS_CKM.2/GTK:4: The evaluator shall test the authenticated-decryption functionality of AES-KWP using the same test as for AES-KWP authenticated-encryption, replacing plaintext values with ciphertext values and AES-KWP authenticated-encryption with AES-KWP authenticated-decryption. Additionally, the evaluator shall modify one byte of the ciphertext, attempt to decrypt the modified ciphertext, and ensure that a failure is returned rather than plaintext.

FCS_CKM.2/PMK Cryptographic Key Distribution (PMK)

The TSF shall receive the 802.11 Pairwise Master Key (PMK) in accordance with a specified cryptographic key distribution method: [from 802.1X Authorization Server] that meets the following: [IEEE 802.11-2020] and does not expose the cryptographic keys.
Application Note: This requirement applies to the Pairwise Master Key that is received from the RADIUS server by the TOE. The intent of this requirement is to ensure conformant TOEs implement 802.1X authentication prior to establishing secure communications with the client. The intent is that any WLAN AS evaluated against this PP-Module will support both WPA2-Enterprise and WPA3-Enterprise at a minimum and certificate-based authentication mechanisms and therefore disallows implementations that support only pre-shared keys. Because communications with the RADIUS server are required to be performed over a protected connection, the transfer of the PMK will be protected.
Evaluation Activities
FCS_CKM.2/PMK
TSS
The evaluator shall examine the TSS to determine that it describes how the PMK is transferred (that is, through what EAP attribute) to the TOE.

Guidance
There are no guidance evaluation activities for this component.

Tests
The evaluator shall establish a session between the TOE and a RADIUS server according to the configuration guidance provided. The evaluator shall then examine the traffic that passes between the RADIUS server and the TOE during a successful attempt to connect a wireless client to the TOE to determine that the PMK is not exposed.

5.2.4 Class FIA: Identification and Authentication

FIA_8021X_EXT.1 802.1X Port Access Entity (Authenticator) Authentication

The TSF shall conform to IEEE Standard 802.1X for a Port Access Entity (PAE) in the “Authenticator” role.
The TSF shall support communications to a RADIUS authentication server conforming to RFCs 2865 and 3579.
The TSF shall ensure that no access to its 802.1X controlled port is given to the wireless client prior to successful completion of this authentication exchange.
Application Note:

This requirement covers the TOE's role as the authenticator in an 802.1X authentication exchange. If the exchange is completed successfully, the TOE will obtain the PMK from the RADIUS server and perform the four-way handshake with the wireless client (supplicant) to begin 802.11 communications.

As indicated previously, there are at least three communication paths present during the exchange; two with the TOE as an endpoint and one with the TOE acting as a transfer point only. The TOE establishes an EAP over Local Area Network (EAPOL) connection with the wireless client as specified in 802.1X-2007. The TOE also establishes (or has established) a RADIUS protocol connection protected either by IPsec or RadSec (TLS) with the RADIUS server. The wireless client and RADIUS server establish an EAP-TLS session (RFC 5216); in this transaction the TOE merely takes the EAP-TLS packets from its EAPOL/RADIUS endpoint and transfers them to the other endpoint. Because the specific authentication method (TLS in this case) is opaque to the TOE, there are no requirements with respect to RFC 5126 in this PP-Module. However, the base RADIUS protocol (2865) has an update (3579) that will need to be addressed in the implementation and evaluation activities. Additionally, RFC 5080 contains implementation issues that will need to be addressed by developers but which levy no new requirements.

The point of performing 802.1X authentication is to provide 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 wireless client has access to the "controlled port" maintained by the TOE.

TLS is defined in the Functional Package for Transport Layer Security (TLS), version 2.1.

Evaluation Activities
FIA_8021X_EXT.1
TSS
In order to show that the TSF implements the 802.1X-2010 standard correctly, the evaluator shall ensure that the TSS contains the following information:
  • The sections (clauses) of the standard that the TOE implements
  • For each identified section, any options selected in the implementation allowed by the standards are specified
  • For each identified section, any non-conformance is identified and described, including a justification for the non-conformance
Because the connection to the RADIUS server will be contained in an IPsec or RadSec (TLS) tunnel, the security mechanisms detailed in the RFCs identified in the requirement are not relied on to provide protection for these communications. Consequently, no extensive analysis of the RFCs is required. However, the evaluator shall ensure that the TSS describes the measures (documentation, testing) that are taken by the product developer to ensure that the TOE conforms to the RFCs listed in this requirement.

Guidance
There are no guidance evaluation activities for this component.

Tests
The evaluator shall perform the following tests:
  • Test FIA_8021X_EXT.1:1: The evaluator shall demonstrate that a wireless client has no access to the test network. After successfully authenticating with a RADIUS server through the TOE, the evaluator shall demonstrate that the wireless client does have access to the test network.
  • Test FIA_8021X_EXT.1:2: The evaluator shall demonstrate that a wireless client 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 wireless client still being unable to access the test network.
  • Test FIA_8021X_EXT.1:3: The evaluator shall demonstrate that a wireless client has no access to the test network. The evaluator shall attempt to authenticate using an invalid RADIUS certificate, such that the EAP-TLS negotiation fails. This should result in the wireless client still being unable to access the test network.
Note: Tests 2 and 3 above are not tests that "EAP-TLS works," although that is a by-product of the test. The test is actually that a failed authentication (under two failure modes) results in denial of access to the network, which demonstrates the enforcement of FIA_8021X_EXT.1.3.

FIA_UAU.6 Re-Authenticating

The TSF shall re-authenticate the administrative user under the conditions [when the user changes their password, [selection: following TSF-initiated session locking, [assignment: other conditions], no other conditions]].
Evaluation Activities
FIA_UAU.6
TSS
There are no TSS evaluation activities for this component.

Guidance
There are no guidance evaluation activities for this component.

Tests
The evaluator shall attempt to change their password as directed by the operational guidance. While making this attempt, the evaluator shall verify that re-authentication is required.

If other re-authentication conditions are specified, the evaluator shall cause those conditions to occur and verify that the TSF re-authenticates the authenticated user.

5.2.5 Class FMT: Security Management

FMT_SMF.1/AccessSystem Specification of Management Functions (WLAN Access Systems)

The TSF shall be capable of performing the following management functions: [
  • Configure the security policy for each wireless network, including:
    • Security type
    • Authentication protocol
    • Client credentials to be used for authentication
    • SSID
    • If the SSID is broadcasted
    • Frequency band set to [selection: 2.4 GHz, 5 GHz, 6 GHz]
    • Transmit power level
]
Evaluation Activities
FMT_SMF.1/AccessSystem
TSS
The evaluator shall confirm that the TSS includes which security types (e.g., WPA3), authentication protocol (e.g., SAE), and frequency bands the WLAN AS supports. The evaluator shall confirm that the TSS includes how connection attempts from clients that are not operating on an approved security type are handled.

Guidance
The evaluator shall confirm that the operational guidance includes instructions for configuring the WLAN AS for each feature listed.

Tests
  • Test FMT_SMF.1/AccessSystem:1: For each security type specified in the TSS, configure the network to the approved security type and verify that the client can establish a connection. Maintaining the same SSID, change the security type of the client to a non-approved security type and attempt to establish a connection. Verify that the connection was unsuccessful.
  • Test FMT_SMF.1/AccessSystem:2: For each authentication protocol specified in the TSS, configure the network accordingly per the AGD. Verify that the client connection attempt is successful when using the correct client credentials and that the connection is unsuccessful when incorrect authentication credentials are used.
  • Test FMT_SMF.1/AccessSystem:3: Configure the SSID to be broadcasted. Using a network sniffing tool, capture a beacon frame and confirm that the SSID is included. Configure the SSID to be hidden. Using a network sniffing tool, capture a beacon frame and confirm that the SSID is not listed.
  • Test FMT_SMF.1/AccessSystem:4: The evaluator shall configure the AS to operate in each of the selected frequency bands and verify using a network sniffing tool.
  • Test FMT_SMF.1/AccessSystem:5: The evaluator shall demonstrate that the client can establish a connection to the AS on the default power level. After disconnecting, the power level should be adjusted and then the client should be able to successfully connect to the AS again.

FMT_SMR_EXT.1 No Administration from Client

The TSF shall ensure that the ability to remotely administer the TOE from a wireless client shall be disabled by default.
Evaluation Activities
FMT_SMR_EXT.1
TSS
There are no TSS evaluation activities for this component.

Guidance
The evaluator shall review the operational guidance to ensure that it contains instructions for administering the TOE both locally and remotely, including any configuration that needs to be performed on the client for remote administration. The evaluator shall confirm that the TOE does not permit remote administration from a wireless client by default.

Tests
The evaluator shall demonstrate that after configuring the TOE for first use from the operational guidance, it is possible to establish an administrative session with the TOE on the “wired” portion of the device. They will then demonstrate that an identically configured wireless client that can successfully connect to the TOE cannot be used to perform administration.

5.2.6 Class FTA: TOE Access

FTA_TSE.1 TOE Session Establishment

The TSF shall be able to deny session establishment of a wireless client session based on [TOE interface, time, day, [selection: [assignment: other attributes], no other attributes]].
Application Note:

The “TOE interface” can be specified in terms of the device in the TOE that the WLAN client is connecting to (e.g. specific WLAN APs). “Time” and “day” refer to time-of-day and day-of-week, respectively.

The assignment is to be used by the ST author to specify additional attributes on which denial of session establishment can be based. In the case of standalone TOEs with a single interface, the "based on TOE interface" restriction is inherently met.

Evaluation Activities
FTA_TSE.1
TSS
The evaluator shall examine the TSS to determine that all of the attributes on which a client session can be denied are specifically defined.

Guidance
The evaluator shall examine the operational guidance to determine that it contains guidance for configuring each of the attributes identified in the TSS.

Tests
For each supported attribute, the evaluator shall perform the following test:
  • Test FTA_TSE.1:1: The evaluator successfully establishes a client session with a wireless client. The evaluator then follows the operational guidance to configure the system so that the client’s access is denied based on a specific value of the attribute. The evaluator shall then attempt to establish a session in contravention to the attribute setting (for instance, the client is denied WLAN access based upon the TOE interface (e.g. WLAN AP) it is connecting to, or that the client is denied access based upon the time-of-day or day-of-week it is attempting connection on). The evaluator shall observe that the access attempt fails.

5.2.7 Class FTP: Trusted Path/Channels

FTP_ITC.1/Client Inter-TSF Trusted Channel (WLAN Client Communications)

The TSF shall provide a communication channel using WPA3-Enterprise, WPA2-Enterprise and [selection: WPA3-SAE, WPA3-SAE-PK, WPA2-PSK, no other modes] as defined by IEEE 802.11-2020 to provide a trusted channel between itself and WLAN clients 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 [WLAN clients] to initiate communication via the trusted channel.
The TSF shall initiate communication via the trusted channel for [no services].
Evaluation Activities
FTP_ITC.1/Client
This component is adequately evaluated when performing the evaluation activities for FTP_ITC.1 in the Network Device, version 4.0 base-PP.

5.3 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 3: SFR Rationale
ThreatAddressed byRationale
T.NETWORK_​DISCLOSUREFCS_COP.1/DataEncryption (modified from Base-PP)Mitigates the threat by utilizing secure encryption and decryption algorithms to protect data.
FTP_ITC.1 (modified from Base-PP)Mitigates the threat by utilizing a secure channel for administrative traffic (e.g., 802.1X traffic, audit server).
FCS_CKM.1/WPAMitigates the threat by utilizing a secure key generation function for WPA functionality.
FCS_CKM.2/GTKMitigates the threat by securely distributing GTK keys to clients.
FCS_CKM.2/PMKMitigates the threat by securely receiving a key from an authentication server.
FIA_8021X_EXT.1Mitigates the threat by authenticating clients before allowing access to the controlled network.
FIA_UAU.6Mitigates the threat by re-authenticating users when specified criteria are met.
FTA_TSE.1Mitigates the threat by denying sessions based on undesirable characteristics.
FTP_ITC.1/ClientMitigates the threat by providing a secure channel for WLAN client traffic.
FCS_CKM.2/DISTRIB (optional)Mitigates the threat by securely distributing 802.11 keys to clients.
FCS_RADSEC_EXT.1 (selection-based)Mitigates the threat by utilizing a secure RADIUS implementation to authenticate clients.
FCS_RADSEC_EXT.2 (selection-based)Mitigates the threat by utilizing a secure TLS configuration for RADIUS over TLS.
FCS_RADSEC_EXT.3 (selection-based)Mitigates the threat by verifying server identifiers when utilizing RADIUS over TLS.
FIA_PSK_EXT.1 (selection-based)Mitigates the threat by generating and/or accepting secure pre-shared keys.
T.NETWORK_​ACCESSFIA_8021X_EXT.1Mitigates the threat by authenticating clients before allowing access to the controlled network.
FIA_UAU.6Mitigates the threat by re-authenticating users when specified criteria are met.
FMT_SMF.1/AccessSystemMitigates the threat by defining management functions that must be protected.
FMT_SMR_EXT.1Mitigates the threat by preventing remote administration functions from being exercised from a wireless client.
FTA_TSE.1Mitigates the threat by denying sessions based on undesirable characteristics.
FCS_RADSEC_EXT.1 (selection-based)Mitigates the threat by utilizing a secure RADIUS implementation to authenticate clients.
FCS_RADSEC_EXT.2 (selection-based)Mitigates the threat by utilizing a secure TLS configuration for RADIUS over TLS.
FCS_RADSEC_EXT.3 (selection-based)Mitigates the threat by verifying server identifiers when utilizing RADIUS over TLS.
T.TSF_​FAILUREFPT_TST_EXT.1 (from Base-PP)Mitigates the threat by defining a set of self-tests occur and a requirement for the TOE to fail sure in the event of a failure of any self-tests.
FAU_GEN.1/WLANMitigates the threat by notifying administrators of irregular operation that could indicate a failure.
T.DATA_​INTEGRITYFCS_COP.1/DataEncryption (modified from Base-PP)Mitigates the threat by encrypting data in transit to protect its confidentiality and integrity.
FTP_ITC.1 (modified from Base-PP)Mitigates the threat by utilizing a secure channel for administrative traffic (e.g., 802.1X traffic, audit server) that maintains data confidentiality and integrity.
FCS_CKM.1/WPAMitigates the threat by generating a secure key used to encrypt and protect wireless traffic using WPA.
FCS_CKM.2/GTKMitigates the threat by securely distributing GTK keys to clients so that they are not disclosed, maintaining the integrity of the data the key is used to protect.
FCS_CKM.2/PMKMitigates the threat by securely receiving a key from an authentication server so that it is not disclosed, maintaining the integrity of the data the key is used to protect.
FTP_ITC.1/ClientMitigates the threat by providing a secure channel for WLAN client traffic that protects the confidentiality and integrity of the data.
FCS_CKM.2/DISTRIB (optional)Mitigates the threat by securely distributing 802.11 keys to clients so that they are not disclosed, maintaining the integrity of the data the key is used to protect.
T.REPLAY_​ATTACKFCS_COP.1/DataEncryption (modified from Base-PP)Mitigates the threat by utilizing secure encryption and decryption algorithms to protect data from disclosure, modification, or replay.
FCS_CKM.1/WPAMitigates the threat by utilizing a secure key generation function for WPA functionality that is not subject to replay or guessing.
FCS_CKM.2/GTKMitigates the threat by securely distributing GTK keys to clients so that they are not disclosed, maintaining confidentiality and preventing replay.
FCS_CKM.2/PMKMitigates the threat by securely receiving a key from an authentication server so that it is not disclosed, maintaining confidentiality and preventing replay.
FIA_8021X_EXT.1Mitigates the threat by authenticating clients before allowing access to the controlled network and preventing replay of previous authentication sessions.
FIA_UAU.6Mitigates the threat by re-authenticating users when specified criteria are met, which can include if a specified time has passed or other indicators of stale authentication data.
FTA_TSE.1Mitigates the threat by denying sessions based on undesirable characteristics, which can include a detection of replay or other indicators of stale authentication data.
FTP_ITC.1/ClientMitigates the threat by providing a secure channel for WLAN client traffic that prevents the use of replayed data.
FCS_CKM.2/DISTRIB (optional)Mitigates the threat by securely distributing 802.11 keys to clients so that they are not disclosed, maintaining confidentiality and preventing replay.
FCS_RADSEC_EXT.1 (selection-based)Mitigates the threat by utilizing a secure RADIUS implementation to authenticate clients, which protects authentication data from replay attacks.
FCS_RADSEC_EXT.2 (selection-based)Mitigates the threat by utilizing a secure TLS configuration for RADIUS over TLS, which provides protection against replay and data modification.
FCS_RADSEC_EXT.3 (selection-based)Mitigates the threat by verifying server identifiers when utilizing RADIUS over TLS, preventing impersonation attacks that could lead to replay.

6 Consistency Rationale

6.1 Collaborative Protection Profile for Network Device

6.1.1 Consistency of TOE Type

When this PP-Module extends the NDcPP, the TOE type for the overall TOE is still a network device. This PP-Module just defines the TOE as a specific type of network device with functional capabilities distinct to that type.

6.1.2 Consistency of Security Problem Definition

Table 4: Consistency of Security Problem Definition (NDcPP base)
PP-Module Threat, Assumption, OSPConsistency Rationale
T.NETWORK_DISCLOSUREThis threat extends the security problem defined by the Base-PP to include the threat of a malicious entity in an untrusted network interacting with a protected entity in a trusted network. This is not addressed in the Base-PP because not all network devices are responsible for facilitating communications between separate networks. This threat is also consistent with the T.UNTRUSTED_COMMUNICATION_CHANNELS threat defined by the Base-PP because compromise of data in transit is one potential way this threat may be exploited.
T.NETWORK_ACCESSThis threat extends the security problem defined by the Base-PP to include the threat of a malicious entity in an untrusted network interacting with a protected entity in a trusted network. This is not addressed in the Base-PP because not all network devices are responsible for facilitating communications between separate networks.
T.TSF_FAILUREThis threat is an extension of the T.SECURITY_FUNCTIONALITY_FAILURE threat defined by the Base-PP.
T.DATA_INTEGRITYThis threat is a specific type of failure that may result from successful exploitation of the T.WEAK_CRYPTOGRAPHY threat defined by the Base-PP. It is an extension of the Base-PP threat for communications that are specific to this PP-Module.
T.REPLAY_ATTACKThis threat is a specific type of failure that may result from successful exploitation of the T.UNAUTHORIZED_ADMINISTRATOR_ACCESS and T.UNTRUSTED_COMMUNICATIONS_CHANNELS threats defined by the Base-PP. It is an extension of the Base-PP threat for communications that are specific to this PP-Module.
A.CONNECTIONSThe Base-PP does not define where in a particular network architecture a network device must be deployed since it is designed to be generic to various types of network devices. This PP-Module defines the expected architectural deployment specifically for WLAN AS network devices.

6.1.3 Consistency of OE Objectives

Table 5: Consistency of OE Objectives (NDcPP base)
PP-Module OE ObjectiveConsistency Rationale
OE.CONNECTIONSThe Base-PP does not define where in a particular network architecture a network device must be deployed since it is designed to be generic to various types of network devices. This PP-Module defines the expected architectural deployment specifically for WLAN AS network devices.

6.1.4 Consistency of Requirements

This PP-Module identifies several SFRs from the NDcPP that are needed to support Wireless Local Area Network (WLAN) Access System functionality. This is considered to be consistent because the functionality provided by the NDcPP is being used for its intended purpose. The PP-Module also identifies a number of modified SFRs from the NDcPP that are used entirely to provide functionality for Wireless Local Area Network (WLAN) Access Systems. The rationale for why this does not conflict with the claims defined by the NDcPP are as follows:
Table 6: Consistency of Requirements (NDcPP base)
PP-Module RequirementConsistency Rationale
Modified SFRs
FCS_COP.1/AEADThis PP-Module modifies the Base-PP's definition of the SFR by mandating certain selections be chosen in it.
FCS_COP.1/DataEncryptionThis PP-Module modifies the Base-PP's definition of the SFR by adding additional AES modes consistent with the standards referenced in the Base-PP and by mandating specific selections that are relevant to the technology type of the PP-Module.
FTP_ITC.1 For CC:2022 updates, the modified audit events associated with this SFR have been removed. The modified audit events are not fundamentally different from those already defined in the Base-PP for the SFR (both events would already fall into the category of 'Failure of the trusted channel functions', as detection of modification would cause an integrity error and failure of a trusted channel) and new PP syntax is incompatible with modified audit events. This PP-Module modifies the Base-PP's definition of the SFR by specifying a minimum baseline of required communications protocols and also includes additional protocols not originally defined by the Base-PP. The original protocols specified in the Base-PP may still be selected by the ST author.
Additional SFRs
This PP-Module does not add any requirements when the NDcPP is the base.
Mandatory SFRs
FAU_GEN.1/WLANThis SFR iterates the FAU_GEN.1 SFR defined in the Base-PP to define auditable events for the functionality that is specific to this PP-Module.
FCS_CKM.1/WPAThis SFR defines additional cryptographic functionality not defined in the Base-PP, but it implements this using the DRBG mechanism already defined in the Base-PP.
FCS_CKM.2/GTKThis SFR defines additional cryptographic functionality not defined in the Base-PP that is used for functionality outside the original scope of the Base-PP.
FCS_CKM.2/PMKThis SFR defines additional cryptographic functionality not defined in the Base-PP that is used for functionality outside the original scope of the Base-PP.
FIA_8021X_EXT.1This SFR defines support for 802.1X communications, which is a logical interface that extends the scope of what the Base-PP originally defined.
FIA_UAU.6This SFR defines support for re-authentication of wireless users, which are a type of subject beyond the scope of what the Base-PP originally defined.
FMT_SMF.1/AccessSystemThis SFR defines additional management functionality that is specific to the Module’s product type and would therefore not be expected to be present in the Base-PP.
FMT_SMR_EXT.1This SFR applies restrictions on when the execution of management functions is authorized. It does not prevent proper administration of the TSF.
FTA_TSE.1This SFR applies restrictions on establishment of wireless communications, which is a logical interface that extends the scope of what the Base-PP originally defined.
FTP_ITC.1/Client This SFR iterates the FTP_ITC.1 SFR defined in the Base-PP to define trusted communication channels for the functionality that is specific to this PP-Module.
Optional SFRs
FCS_CKM.2/DISTRIBThis SFR defines an additional use for the cryptographic and self-protection mechanisms defined in the Base-PP.
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_RADSEC_EXT.1This SFR defines the implementation of RadSec and the peer authentication method that it uses. This relies on the TLS requirements defined by the Base-PP and may also use the X.509v3 certificate validation methods specified in the Base-PP, depending on the selected peer authentication method.
FCS_RADSEC_EXT.2
FCS_RADSEC_EXT.3This SFR defines the implementation of RadSec when pre-shared key authentication with RSA is used. This functionality is outside the original scope of the Base-PP, but it relies on the TLS client protocol implementation, cryptographic algorithms, and random bit generation functions defined by the Base-PP.
FIA_PSK_EXT.1This SFR defines parameters for pre-shared key generation. The Base-PP supports pre-shared keys as a potential authentication method for IPsec. This PP-Module does not prevent this from being used but does define restrictions on how pre-shared keys may be generated and what constitutes an acceptable key. This may also be used for RadSec, which is outside the original scope of the Base-PP.

Appendix A - Optional SFRs

A.1 Strictly Optional Requirements

A.1.1 Auditable Events for Optional SFRs

Table 7: Auditable Events for Strictly Optional Requirements
RequirementAuditable EventsAdditional Audit Record Contents
FCS_CKM.2/DISTRIB
No events specifiedN/A

A.1.2 Class FCS: Cryptographic Support

FCS_CKM.2/DISTRIB Cryptographic Key Distribution (802.11 Keys)

The TSF shall distribute the IEEE 802.11 keys in accordance with a specified cryptographic key distribution method [trusted channel protocol specified in FPT_ITT.1 (Base-PP)] that meets the following: [standards specified in the various iterations of FCS_COP.1] and does not expose the cryptographic keys.
Application Note:

This requirement applies to any key necessary for successful IEEE 802.11 connections not covered by FCS_CKM.2/GTK. In cases where a key must be distributed to other APs, this communication must be performed via a mechanism of commensurate cryptographic strength. Because communications with any component of a distributed TOE are required to be performed over a trusted connection, the transfer of these keys will be protected.

FCS_COP.1 and FPT_ITT.1 are defined in the NDcPP.

Evaluation Activities
FCS_CKM.2/DISTRIB
TSS
The evaluator shall examine the TSS to determine that it describes which keys are distributed outside the TOE, where they are sent, and the purpose for this transfer.

Guidance
If this function is dependent on TOE configuration, the evaluator shall confirm that the operational guidance contains instructions for how to configure that the keys are adequately protected.

Tests
This requirement will be tested in conjunction with the tests for the cryptographic primitives, the secure protocols, and FPT_ITT.1 (Base-PP).

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 8: Auditable Events for Selection-based Requirements
RequirementAuditable EventsAdditional Audit Record Contents
FCS_RADSEC_EXT.1
No events specifiedN/A
FCS_RADSEC_EXT.2
No events specifiedN/A
FCS_RADSEC_EXT.3
No events specifiedN/A
FIA_PSK_EXT.1
No events specifiedN/A

B.2 Class FCS: Cryptographic Support

FCS_RADSEC_EXT.1 RadSec

The inclusion of this selection-based component depends upon selection in FTP_ITC.1.1.
The TSF shall implement RADIUS over TLS as specified in RFC 6614 to communicate securely with a RADIUS server.
The TSF shall perform peer authentication using [selection: X.509v3 certificates, pre-shared keys].
Application Note:

This SFR is applicable if "RADIUS over TLS" is selected in FTP_ITC.1.1.

If X.509v3 certificates is selected in FCS_RADSEC_EXT.1.2, then FCS_TLSC_EXT.2 from the Functional Package for Transport Layer Security (TLS), version 2.1 must be claimed. If pre-shared keys is selected in FCS_RADSEC_EXT.1.2, then FCS_RADSEC_EXT.2 and FIA_PSK_EXT.1 in this PP-Module must be claimed.

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

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

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

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

FCS_RADSEC_EXT.2 RadSec using Pre-Shared Keys

The inclusion of this selection-based component depends upon selection in FCS_RADSEC_EXT.1.2.
The TSF shall implement TLS 1.2 and [selection: TLS 1.3, no other TLS versions] when acting as a RADIUS over TLS client that supports the following ciphersuites: [selection:
  • TLS 1.2 ciphersuites:[selection:
    • TLS_ECDHE_PSK_WITH_AES_256_GCM_SHA384 as defined in RFC 8442
    • TLS_DHE_PSK_WITH_AES_256_GCM_SHA384 as defined in RFC 5487
    ]
  • TLS 1.3 ciphersuites:
    • TLS_AES_256_GCM_SHA384 as defined in RFC 8446
    [selection:
    • TLS_AES_128_GCM_SHA256 as defined in RFC 8446
    • [assignment: other TLS 1.3 ciphersuites]
    ]
].
Application Note:

The above ciphersuites are only for use when the TSF is acting as a RADIUS over TLS client, not for other uses of the TLS protocol. The ciphersuites to be tested in the evaluated configuration are limited by this requirement. The ST author should select the ciphersuites that are supported.

This requirement must be included if pre-shared keys is selected in FCS_RADSEC_EXT.1.2.

The TSF shall be able to [selection: accept, generate using the random bit generator specified in FCS_RBG.1] bit-based pre-shared keys.
Evaluation Activities
FCS_RADSEC_EXT.2
TSS
The evaluator shall check the description of the implementation of this protocol in the TSS to ensure that the ciphersuites supported are specified. The evaluator shall check the TSS to ensure that the ciphersuites specified are identical to those listed for this component. The evaluator shall also verify that the TSS contains a description of the denial of old SSL and TLS versions. The evaluator shall examine the TSS to ensure it describes the process by which the bit-based pre-shared keys are generated (if the TOE supports this functionality), and confirm that this process uses the RBG specified in FCS_RBG.1.
Guidance
The evaluator shall verify that any configuration necessary to meet the requirement must be contained in the guidance.

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

The evaluator shall confirm the operational guidance contains instructions for either entering bit-based pre-shared keys or generating a bit-based pre-shared key (or both).
Tests
The testing for this requirement is addressed by the functional claims made in for this interface.

FCS_RADSEC_EXT.3 RadSec using Pre-Shared Keys and RSA

When the TSF negotiates a TLS_RSA_PSK cipher suite, the TSF shall verify that the presented identifier matches the reference identifier per RFC 6125 section 6.
Application Note:

This requirement must be claimed if any ciphersuites beginning with 'TLS_RSA_PSK' are selected in FCS_RADSEC_EXT.2.1.

The rules for verification of identity are described in Section 6 of RFC 6125. The reference identifier is typically established by configuration (e.g. configuring the name of the authentication server). Based on a singular reference identifier’s source domain and application service type (e.g. HTTP, SIP, LDAP), the client establishes all reference identifiers which are acceptable, such as a Common Name for the Subject Name field of the certificate and a (case-insensitive) DNS name for the Subject Alternative Name field. The client then compares this list of all acceptable reference identifiers to the presented identifiers in the TLS server’s certificate.

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

When the TSF negotiates a TLS_RSA_PSK cipher suite, the TSF shall [selection: not establish the connection, request authorization to establish the connection, [assignment: other action]] if the presented server certificate is deemed invalid.
Application Note:

This requirement must be claimed if any ciphersuites beginning with 'TLS_RSA_PSK' are selected in FCS_RADSEC_EXT.2.1.

Validity is determined by the identifier verification, certificate path, the expiration date, and the revocation status in accordance with RFC 5280. Certificate validity is tested in accordance with testing performed for FIA_X509_EXT.1/Rev in the NDcPP.

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

Guidance
The evaluator shall verify that the operational guidance includes instructions for setting the reference identifier to be used for the purposes of certificate validation in TLS.

Tests
The evaluator shall perform the following tests:
  • Test FCS_RADSEC_EXT.3:1: The evaluator shall attempt to establish the connection using a server with a server certificate that contains the Server Authentication purpose in the extendedKeyUsage field and verify that a connection is established. The evaluator shall then verify that the client rejects an otherwise valid server certificate that lacks the Server Authentication purpose in the extendedKeyUsage field and a connection is not established. Ideally, the two certificates should be identical except for the extendedKeyUsage field.
  • Test FCS_RADSEC_EXT.3:2: The evaluator shall present a server certificate that does not contain an identifier in either the Subject Alternative Name (SAN) or Common Name (CN) that matches the reference identifier. The evaluator shall verify that the connection fails.
  • Test FCS_RADSEC_EXT.3:3: The evaluator shall present a server certificate that contains a CN that matches the reference identifier, contains the SAN extension, but does not contain an identifier in the SAN that matches the reference identifier. The evaluator shall verify that the connection fails. The evaluator shall repeat this test for each supported SAN type.
  • Test FCS_RADSEC_EXT.3:4: The evaluator shall present a server certificate that contains a CN that does not match the reference identifier but does contain an identifier in the SAN that matches. The evaluator shall verify that the connection succeeds.
  • Test FCS_RADSEC_EXT.3:5: [conditional] If the TOE does not mandate the presence of the SAN extension, the evaluator shall present a server certificate that contains a CN that matches the reference identifier and does not contain the SAN extension. The evaluator shall verify that the connection succeeds. If the TOE does mandate the presence of the SAN extension, this test will be omitted.
  • Test FCS_RADSEC_EXT.3:6: [conditional] If wildcards are supported by the TOE, the evaluator shall perform the following tests:
    • The evaluator shall present a server certificate containing a wildcard that is not in the left-most label of the presented identifier (e.g. foo.*.example.com) and verify that the connection fails.
    • The evaluator shall present a server certificate containing a wildcard in the left-most label but not preceding the public suffix (e.g. *.example.com). The evaluator shall configure the reference identifier with a single left-most label (e.g. foo.example.com). The evaluator shall verify that the connection succeeds. The evaluator shall configure the reference identifier without a left-most label as in the certificate (e.g. example.com) and verify that the connection fails. The evaluator shall configure the reference identifier with two left-most labels (e.g. bar.foo.example.com) and verify that the connection fails.
    • The evaluator shall present a server certificate containing a wildcard in the left-most label immediately preceding the public suffix (e.g. *.com). The evaluator shall configure the reference identifier with a single left-most label (e.g. foo.com) and verify that the connection fails. The evaluator shall configure the reference identifier with two left-most labels (e.g. bar.foo.com) and verify that the connection fails.
  • Test FCS_RADSEC_EXT.3:7: [conditional] If wildcards are not supported by the TOE, the evaluator shall present a server certificate containing a wildcard and verify that the connection fails.
  • Test FCS_RADSEC_EXT.3:8: [conditional] If URI or Service name reference identifiers are supported, the evaluator shall configure the DNS name and the service identifier. The evaluator shall present a server certificate containing the correct DNS name and service identifier in the URIName or SRVName fields of the SAN and verify that the connection succeeds. The evaluator shall repeat this test with the wrong service identifier (but correct DNS name) and verify that the connection fails.

B.3 Class FIA: Identification and Authentication

FIA_PSK_EXT.1 Pre-Shared Key Composition

The inclusion of this selection-based component depends upon selection in FCS_RADSEC_EXT.1.2.
The TSF shall be able to use pre-shared keys for [selection: RADIUS over TLS (RadSec), IPsec, WPA3-SAE, WPA3-SAE-PK, IEEE 802.11 WPA2-PSK, [assignment: other protocols that use pre-shared keys]].
The TSF shall be able to accept text-based pre-shared keys that:
  • are 22 characters and [selection: [assignment: other supported lengths], no other lengths];
  • are composed of any combination of upper and lower case letters, numbers, and special characters (that include: “!”, “@”, “#”, “$”, “%”, “^”, “&”, “*”, “(“, and “)”).
The TSF shall be able to [selection: accept, generate using the random bit generator specified in FCS_RBG.1] bit-based pre-shared keys.
Application Note:

This requirement must be included if IPsec or another protocol that uses pre-shared keys is claimed, and pre-shared key authentication is selected (e.g., "Pre-shared Keys" is selected in FCS_IPSEC_EXT.1.13 or "pre-shared keys" is selected in FCS_RADSEC_EXT.1.2). The intent of this requirement is that all protocols will support both text-based and bit-based pre-shared keys.

For the length of the text-based pre-shared keys, a common length (22 characters) is required to help promote interoperability. If other lengths are supported, they should be listed in the assignment; this assignment can also specify a range of values (e.g., "lengths from 5 to 55 characters").

For FIA_PSK_EXT.1.3, the ST author specifies whether the TSF merely accepts bit-based pre-shared keys or is capable of generating them. If it generates them, the requirement specifies that they must be generated using the RBG provided by the TOE.

Evaluation Activities
FIA_PSK_EXT.1
TSS
The evaluator shall verify that the TSS describes
  1. the protocols that can use pre-shared keys and that these are consistent with the selections made in FIA_PSK_EXT.1.1.
  2. the allowable values for pre-shared keys and that they are consistent with the selections made in FIA_PSK_EXT.1.2.
  3. the way bit-based pre-shared keys are procured and that it is consistent with the selections made in FIA_PSK_EXT.1.3.
Guidance
The evaluator shall examine the operational guidance to determine that it provides guidance to administrators on the composition of strong text-based pre-shared keys, and (if the selection indicates keys of various lengths can be entered) that it provides information on the range of lengths supported. The guidance must specify the allowable characters for pre-shared keys, and that list must be a superset of the list contained in FIA_PSK_EXT.1.2.

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

Tests
The evaluator shall also perform the following tests for each protocol (or instantiation of a protocol, if performed by a different implementation on the TOE). Note that one or more of these tests can be performed with a single test case.
  • Test FIA_PSK_EXT.1:1: The evaluator shall compose a pre-shared key of 22 characters that contains a combination of the allowed characters in accordance with the operational guidance and demonstrates that a successful protocol negotiation can be performed with the key.
  • Test FIA_PSK_EXT.1:2: [conditional]: If the TOE supports pre-shared keys of multiple lengths, the evaluator shall repeat Test 1 using the minimum length; the maximum length; a length inside the allowable range; and invalid lengths beyond the supported range (both higher and lower). The minimum, maximum, and included length tests should be successful, and the invalid lengths must be rejected by the TOE.
  • Test FIA_PSK_EXT.1:3: [conditional]: If the TOE does not generate bit-based pre-shared keys, the evaluator shall obtain a bit-based pre-shared key of the appropriate length and enter it according to the instructions in the operational guidance. The evaluator shall then demonstrate that a successful protocol negotiation can be performed with the key.
  • Test FIA_PSK_EXT.1:4: [conditional]: If the TOE does generate bit-based pre-shared keys, the evaluator shall generate a bit-based pre-shared key of the appropriate length and use it according to the instructions in the operational guidance. The evaluator shall then demonstrate that a successful protocol negotiation can be performed with the key.

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 9: Extended Component Definitions
Functional ClassFunctional Components
Class FCS: Cryptographic SupportFCS_RADSEC_EXT RadSec
Class FIA: Identification and AuthenticationFIA_8021X_EXT 802.1X Port Access Entity (Authenticator) Authentication
FIA_PSK_EXT Pre-Shared Key Composition
Class FMT: Security ManagementFMT_SMR_EXT Security Management Restrictions

C.2 Extended Component Definitions

C.2.1 Class FCS: Cryptographic Support

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

C.2.1.1 FCS_RADSEC_EXT RadSec

Family Behavior

Components in this family describe requirements for implementation of the RadSec (RADIUS over TLS) protocol.

Component Leveling

FCS_RADSEC_EXT123

FCS_RADSEC_EXT.1, RadSec, requires the TSF to implement RadSec using a specified peer authentication method.

FCS_RADSEC_EXT.2, RadSec using Pre-Shared Keys, requires the TSF to implement RadSec using pre-shared key authentication in a manner that conforms to relevant TLS specifications.

FCS_RADSEC_EXT.3, RadSec using Pre-Shared Keys and RSA, requires the TSF to validate the external entity used for trusted communications.

Management: FCS_RADSEC_EXT.1

No specific management functions are identified.

Audit: FCS_RADSEC_EXT.1

There are no auditable events foreseen.

FCS_RADSEC_EXT.1 RadSec

Hierarchical to:No other components.
Dependencies to: FCS_TLSC_EXT.1 TLS Client Protocol and
[FIA_PSK_EXT.1 Pre-Shared Key Composition
or FIA_X509_EXT.1 X.509v3 Certificate Validation]

FCS_RADSEC_EXT.1.1

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

FCS_RADSEC_EXT.1.2

The TSF shall perform peer authentication using [assignment: some authentication method].

Management: FCS_RADSEC_EXT.2

No specific management functions are identified.

Audit: FCS_RADSEC_EXT.2

There are no auditable events foreseen.

FCS_RADSEC_EXT.2 RadSec using Pre-Shared Keys

Hierarchical to:No other components.
Dependencies to: FCS_CKM.1 Cryptographic Key Generation
FCS_COP.1 Cryptographic Operation
FCS_RADSEC_EXT.1 RadSec
FCS_RBG.1 Random Bit Generation

FCS_RADSEC_EXT.2.1

The TSF shall implement [assignment: list of allowed TLS versions] when acting as a RADIUS over TLS client that supports the following ciphersuites: [assignment: list of supported ciphersuites].

FCS_RADSEC_EXT.2.2

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

Management: FCS_RADSEC_EXT.3

No specific management functions are identified.

Audit: FCS_RADSEC_EXT.3

There are no auditable events foreseen.

FCS_RADSEC_EXT.3 RadSec using Pre-Shared Keys and RSA

Hierarchical to:No other components.
Dependencies to: FCS_RADSEC_EXT.2 RadSec using Pre-Shared Keys
FIA_X509_EXT.1 X.509v3 Certificate Validation

FCS_RADSEC_EXT.3.1

When the TSF negotiates a TLS_RSA_PSK cipher suite, the TSF shall verify that the presented identifier matches the reference identifier per RFC 6125 section 6.

FCS_RADSEC_EXT.3.2

When the TSF negotiates a TLS_RSA_PSK cipher suite, the TSF shall [selection: not establish the connection, request authorization to establish the connection, [assignment: other action]] if the presented server certificate is deemed invalid.

C.2.2 Class FIA: Identification and Authentication

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

C.2.2.1 FIA_8021X_EXT 802.1X Port Access Entity (Authenticator) Authentication

Family Behavior

Components in this family describe requirements for implementation of 802.1X port-based network access control.

Component Leveling

FIA_8021X_EXT1

FIA_8021X_EXT.1, 802.1X Port Access Entity (Authenticator) Authentication, requires the TSF to securely implement IEEE 802.1X as an authenticator.

Management: FIA_8021X_EXT.1

No specific management functions are identified.

Audit: FIA_8021X_EXT.1

The following actions should be auditable if FAU_GEN Security Audit Data Generation is included in the ST:

  • Attempts to access the 802.1X controlled port prior to successful completion of the authentication exchange

FIA_8021X_EXT.1 802.1X Port Access Entity (Authenticator) Authentication

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

FIA_8021X_EXT.1.1

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

FIA_8021X_EXT.1.2

The TSF shall support communications to a RADIUS authentication server conforming to RFCs 2865 and 3579.

FIA_8021X_EXT.1.3

The TSF shall ensure that no access to its 802.1X controlled port is given to the wireless client prior to successful completion of this authentication exchange.

C.2.2.2 FIA_PSK_EXT Pre-Shared Key Composition

Family Behavior

Components in this family describe requirements for the creation and composition of pre-shared keys used to establish trusted communications channels.

Component Leveling

FIA_PSK_EXT1

FIA_PSK_EXT.1, Pre-Shared Key Composition, requires the TSF to support pre-shared keys that meet various characteristics for specific communications usage.

Management: FIA_PSK_EXT.1

No specific management functions are identified.

Audit: FIA_PSK_EXT.1

There are no auditable events foreseen.

FIA_PSK_EXT.1 Pre-Shared Key Composition

Hierarchical to:No other components.
Dependencies to:FCS_RBG.1 Random Bit Generation

FIA_PSK_EXT.1.1

The TSF shall be able to use pre-shared keys for [assignment: pre-shared key protocols].

FIA_PSK_EXT.1.2

The TSF shall be able to accept text-based pre-shared keys that:
  • are 22 characters and [selection: [assignment: other supported lengths], no other lengths];
  • are composed of any combination of upper and lower case letters, numbers, and special characters (that include: “!”, “@”, “#”, “$”, “%”, “^”, “&”, “*”, “(“, and “)”).

FIA_PSK_EXT.1.3

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

C.2.3 Class FMT: Security Management

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

C.2.3.1 FMT_SMR_EXT Security Management Restrictions

Family Behavior

Components in this family describe architectural restrictions on security administration that are not defined in CC Part 2.

Component Leveling

FMT_SMR_EXT1

FMT_SMR_EXT.1, No Administration from Client, requires the TSF to reject remote administration from a wireless client by default.

Management: FMT_SMR_EXT.1

No specific management functions are identified.

Audit: FMT_SMR_EXT.1

There are no auditable events foreseen.

FMT_SMR_EXT.1 No Administration from Client

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

FMT_SMR_EXT.1.1

The TSF shall ensure that the ability to remotely administer the TOE from a wireless client shall be disabled by default.

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 or inherited from the Base-PP.

Appendix E - Allocation of Requirements in Distributed TOEs

For a distributed TOE, the security functional requirements in this PP-Module need to be met by the TOE as a whole, but not all SFRs will necessarily be implemented by all components. The following categories are defined in order to specify when each SFR must be implemented by a component: The table below specifies how each of the SFRs in this PP-Module must be met, using the categories above.
Requirement Description Distributed TOE SFR Allocation
FAU_GEN.1/WLAN Audit Data Generation All
FCS_CKM.1/WPA Cryptographic Key Generation (Symmetric Keys for WPA2 Connections) One
FCS_CKM.2/GTK Cryptographic Key Distribution (GTK) Feature Dependent
FCS_CKM.2/PMK Cryptographic Key Distribution (PMK) Feature Dependent
FIA_8021X_EXT.1 802.1X Port Access Entity (Authenticator) Authentication One
FIA_UAU.6 Re-Authenticating Feature Dependent
FMT_SMF.1/AccessSystem Specification of Management Functions Feature Dependent
FMT_SMR_EXT.1 No Administration from Client All
FTA_TSE.1 TOE Session Establishment All
FTP_ITC.1/Client Inter-TSF Trusted Channel (WLAN Client Communications) All
FCS_CKM.2/DISTRIB Cryptographic Key Distribution (802.11 Keys) Feature Dependent
FCS_RADSEC_EXT.1 RadSec Feature Dependent
FCS_RADSEC_EXT.2 RadSec using Pre-Shared Keys Feature Dependent
FCS_RADSEC_EXT.3 RadSec using Pre-Shared Keys and RSA Feature Dependent
FIA_PSK_EXT.1 Pre-Shared Key Composition Feature Dependent

Appendix F - 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-PP.

Appendix G - Acronyms

Table 10: Acronyms
AcronymMeaning
AESAdvanced Encryption Standard
APAccess Point
ASAccess System
Base-PPBase Protection Profile
CBCCipher Block Chaining
CCCommon Criteria
CCMCounter Mode with CBC-Message Authentication Code
CCMPCCM mode Protocol
CEMCommon Evaluation Methodology
cPPCollaborative Protection Profile
CTRCounter (encryption mode)
EAPExtensible Authentication Protocol
GCMGalois-Counter Mode
GTKGroup Temporal Key
IPsecInternet Protocol Security
MACMedia Access Control
NDcPPNetwork Device collaborative Protection Profile
OEOperational Environment
PAEPort Access Entity
PMKPairwise Master Key
PPProtection Profile
PP-ConfigurationProtection Profile Configuration
PP-ModuleProtection Profile Module
PTKPairwise Transient Key
RADIUSRemote Authentication Dial In User Service
RBGRandom Bit Generator
SARSecurity Assurance Requirement
SFRSecurity Functional Requirement
SSIDService Set Identifier
STSecurity Target
TLSTransport Layer Security
TOETarget of Evaluation
TSFTOE Security Functionality
TSFITSF Interface
TSSTOE Summary Specification
WLANWireless Local Area Network
WPAWi-Fi Protected Access

Appendix H - Bibliography

Table 11: Bibliography
IdentifierTitle
[CC]Common Criteria for Information Technology Security Evaluation -
[CEM]Common Methodology for Information Technology Security Evaluation -
[NDcPP] collaborative Protection Profile for Network Devices, Version 4.0, December 22, 2025