The scope of the LiFi Access System PP-Module is to describe the security functionality of a LiFi access system product in terms of [CC]
and to define functional and assurance requirements for such products. This PP-Module is intended for use with the following Base-PPs:
collaborative Protection Profile for Network Devices, Version 3.0e
A conformant TOE will claim conformance to a PP-Configuration that includes the Base-PP identified above, this PP-Module, and any of the PP-Modules or packages identified in Section 2.
This Base-PP is valid because a LiFi Access System is a specific function for a purpose-built network device.
Tech terms section below is placeholder/template, will need to be updated later for terms specific to this module
1.2 Terms
The following sections list Common Criteria and technology terms used in this document.
1.2.1 Common Criteria Terms
Assurance
Grounds for confidence that a TOE meets the SFRs [CC].
Base Protection Profile (Base-PP)
Protection Profile used as a basis to build a PP-Configuration.
Collaborative Protection Profile (cPP)
A Protection Profile developed by
international technical communities and approved by multiple schemes.
Common Criteria (CC)
Common Criteria for Information Technology Security Evaluation (International Standard ISO/IEC 15408).
Common Criteria Testing Laboratory
Within the context of the Common Criteria Evaluation and Validation Scheme (CCEVS), an IT security evaluation facility
accredited by the National Voluntary Laboratory Accreditation Program (NVLAP) and approved by the NIAP Validation Body to conduct Common Criteria-based evaluations.
Common Evaluation Methodology (CEM)
Common Evaluation Methodology for Information Technology Security Evaluation.
Distributed TOE
A TOE composed of multiple components operating as a logical whole.
Extended Package (EP)
A deprecated document form for collecting SFRs that implement a particular protocol, technology,
or functionality. See Functional Packages.
Functional Package (FP)
A document that collects SFRs for a particular protocol, technology,
or functionality.
Operational Environment (OE)
Hardware and software that are outside the TOE boundary that support the TOE functionality and security policy.
Protection Profile (PP)
An implementation-independent set of security requirements for a category of products.
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
Address Space Layout Randomization (ASLR)
An anti-exploitation feature which loads memory mappings into unpredictable
locations. ASLR makes it more difficult for an attacker to redirect control to code
that they have introduced into the address space of a process.
Administrator
An individual, user, or group that is responsible for management activities, including setting policies that are
applied by the enterprise on the operating system.
This administrator could be acting remotely through a management server, from which the system
receives configuration policies.
An administrator can enforce settings on the system which cannot be overridden by non-administrator users.
Application (app)
Software that runs on a platform and performs tasks on behalf of the user
or owner of the platform, as well as its supporting documentation.
Application Programming Interface (API)
A specification of routines, data structures, object classes, and variables
that allows an application to make use of services provided by another software
component, such as a library. APIs are often provided for a set of libraries included
with the platform.
Credential
Data that establishes the identity of a user, e.g. a cryptographic key or
password.
Critical Security Parameters (CSP)
Information that is either user or system defined and
is used to operate a cryptographic module in processing encryption functions including
cryptographic keys and authentication data, such as passwords, the disclosure or modification
of which can compromise the security of a cryptographic module or the security of the
information protected by the module.
DAR Protection
Countermeasures that prevent attackers, even those with physical access,
from extracting data from non-volatile storage.
Common techniques include data encryption and wiping.
Data Execution Prevention (DEP)
An anti-exploitation feature of modern operating systems executing on
modern computer hardware, which enforces a non-execute permission on pages of memory.
DEP prevents pages of memory from containing both data and instructions, which makes
it more difficult for an attacker to introduce and execute code.
Developer
An entity that writes OS software. For the purposes of this document,
vendors and developers are the same.
General Purpose Operating System
A class of OSes designed to support a wide-variety of workloads consisting of many concurrent applications or services.
Typical characteristics for OSes in this class include support for third-party applications,
support for multiple users, and security separation between users and their respective resources.
General Purpose Operating Systems also lack the real-time constraint that defines Real Time Operating Systems (RTOS).
RTOSes typically power routers, switches, and embedded devices.
Host-based Firewall
A software-based firewall implementation running on the OS for filtering inbound and
outbound network traffic to and from processes running on the OS.
Operating System (OS)
Software that manages physical and logical resources and provides services
for applications. The terms TOE and OS are interchangeable in this
document.
Personally Identifiable Information (PII)
Any information about an individual maintained by an agency, including, but
not limited to, education, financial transactions, medical history, and criminal or
employment history and information which can be used to distinguish or trace an
individual's identity, such as their name, social security number, date and place of
birth, mother's maiden name, biometric records, etc., including any other personal
information which is linked or linkable to an individual.
Sensitive Data
Sensitive data may include all user or enterprise data or may be specific
application data such as PII, emails, messaging, documents, calendar items, and contacts.
Sensitive data must minimally include credentials and keys. Sensitive data shall
be identified in the OS's TSS by the ST author.
User
An entity operating the TOE that is subject to configuration policies applied
to the operating system by administrators. On some systems under certain
configurations, a normal user can temporarily elevate privileges to that of an administrator.
At that time, such a user should be considered an administrator.
peer
An IT entity that is external to the TOE that interfaces with the TOE via an over-the-air connection for the purpose of accessing the network on which the TOE exists as a boundary device.
1.3 Compliant Targets of Evaluation
This PP-Module specifically addresses LiFi (IEEE 802.11bb, ITU G.9991) access systems (AS). A compliant LiFi 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 LiFi AS establishes a secure wireless (IEEE 802.11, IEEE802.1x, IEEE 802.1AE) 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.
The TOE encompasses the OS kernel drivers, shared software libraries, and some application software included with the OS. The applications considered within the TOE are those that provide essential LiFi services that make up the LiFi link and security. Examples are management services that implement configuration functions specified in this PP-Module, host services that manage client authentication to the access point, and the libraries and modules that provide security implementation of the LiFi link. This applies to each separate TOE component that are being used to meet the security requirements proposed.
1.3.1 TOE Boundary
The physical boundary for a TOE that conforms to this PP-Module is one or more physical network appliances (in a standalone or distributed configuration) that provides generalized network device functionality such as auditing, identification and authentication, and cryptographic services for network communications, as well as specialized functionality for facilitating remote network access via LiFi communications. The TOE's logical boundary includes all functionality required by the claimed Base-PP, this PP-Module, and any other PP-Modules which may be claimed by the ST author as a part of a PP-Configuration that includes this PP-Module. Product functionality for which no PP-Module exists, or for which no SFR within a relevant PP-Module exists to capture, are considered to be non-interfering with respect to the TSF. In other words, they may be present or enabled in the evaluated configuration of the TOE but their presence must not degrade or interrupt the enforcement of functions within the TOE's logical boundary.
Note that while the Base-PP permits the TOE either to be a physical or virtual network appliance, LiFi devices require the use of specialized hardware that will not be present on commodity servers, and it is therefore expected that any TOE that conforms to this PP-Module will be one or more dedicated physical devices.
The TOE is a standalone network device that serves as a single network endpoint that provides connectivity to LiFi clients.
[USE CASE 2] Distributed System
The TOE is a distributed system consisting of multiple network devices that collectively serve as the LiFi 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 SFRFCS_CKM.2/DISTRIB to describe the key distribution method between distributed TOE components.
1.5 Implementation-Based Features
A conformant TOE may implement either 802.11bb or G.vlc. Depending on which is supported, different requirements will apply to the TOE as they each implement different methods of protection of data in transit.
1.5.1 802.11bb Support
The TOE implements LiFi using IEEE 802.11bb. Data in transit is protected using either IPsec or RadSec (RADIUS over TLS).
If this feature is implemented by the TOE, the following requirements must be claimed in the ST:
The TSF implements LiFi using ITU-T G.9991 (aka G.vlc). Data in transit is protected using MACsec. When the TOE implements this feature, it must also claim conformance to the PP-Module for MACsec Ethernet Encryption.
If this feature is implemented by the TOE, the following requirements must be claimed in the ST:
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.
collaborative Protection Profile for Network Devices, Version 3.0e
PP-Module for MACsec Ethernet Encryption, version 1.0
Package Claim
This PP-Module is
Functional Package for Transport Layer Security Version 2.1 conformant.
This PP-Module is
Functional Package for X.509 Version 1.0 conformant.
This PP-Module is
Assurance Package for Flaw Remediation Version 1.0 conformant.
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 where a distributed network device facilitates end user access to a network via LiFi. The threats are similar to those that are typical of network devices as a whole, but may be exploited differently because of the mechanisms that are unique to this particular type of product.
3.1 Threats
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.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 data encryption that exposes the 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 pat into the protected network.
T.NETWORK_ATTACK
An attacker is positioned on a communications channel or elsewhere on the network infrastructure. Attackers may engage in communications with applications and services running on or part of the TOE with the intent of compromise. Engagement may consist of altering existing legitimate communications.
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 trans versing throughout the wireless network and send the packets later, 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.
A.NON_SECURITY_FUNCTIONS
The product implements some security-relevant functionality that does not require evaluation (e.g., network time synchronization, process scheduling, and virtual memory management including process separation).
A.MANAGED_CONFIG
Depending on configuration and capability, the product may or may not be configuration-managed by the enterprise or bound to directory services to support multi-user login.
A.THIRD_PARTY_SOFTWARE
The product runs application software developed by a third party. The applications are not intentionally developed to be malicious, but can contain inadvertent coding errors. These errors introduce risk that control of an application may be seized by a malicious entity. The product shall confine these applications within the originally designated operating environment.
A.NETWORK_CONNECTIVITY
The platform is connected to a network. For purposes of sending/receiving data, to include software updates, the platform is connected to other entities. Other entities on the network are not inherently trustable.
A.PROPER_USER
Users are not malicious in nature, though they may inadvertently or intentionally engage in risky behavior.
3.3 Organizational Security Policies
This document does not define any additional OSPs.
4 Security Objectives
4.1 Security Objectives for the Operational Environment
The OE of the TOE implements technical and procedural measures to assist the TOE in correctly providing its security functionality (which is defined by the security objectives for the TOE).
The security objectives for the OE consist of a set of statements describing the goals that the OE should achieve.
This section defines the security objectives that are to be addressed by the IT domain or by non-technical or procedural means.
The assumptions identified in Section 3 are incorporated as security objectives for the environment.
OE.NON_SECURITY_FUNCTIONS
The product has functionality outside of its logical security boundary to satisfy organizational requirements that are unrelated to what this PP-Module defines.
OE.MANAGED_CONFIG
The product is compatible with enterprise architecture that allows for managed configuration, subject authorization via directory services, or both.
OE.THIRD_PARTY_SOFTWARE
The operational environment permits the use of third-party software on organization-owned hardware to enforce necessary functions.
OE.NETWORK_CONNECTIVITY
The operational environment facilitates the use of network connectivity by authorized subjects.
OE.PROPER_USER
Users of the system are adequately vetted to ensure that they are non-malicious.
4.2 Security Objectives Rationale
This section describes how the assumptions and organizational
security policies map to operational environment security objectives.
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:
Refinement operation (denoted by bold text or strikethrough
text): Is used to add details to a requirement or to remove part of the requirement that is made irrelevant
through the completion of another operation, and thus further restricts a requirement.
Selection (denoted by italicized text): Is used to select one or more options
provided by the [CC] in stating a requirement.
Assignment operation (denoted by italicized text): Is used to assign a
specific value to an unspecified parameter, such as the length of a password. Showing the
value in square brackets indicates assignment.
Iteration operation: Is indicated by appending the SFR name with a slash and unique identifier
suggesting the purpose of the operation, e.g. "/EXAMPLE1."
5.1 Collaborative
Protection Profile for Network Devices
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 Base-PP.
In this case, the following sections describe any modifications that the ST author must make to the SFRs
defined in the Base-PP 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 Protection of the TSF (FPT)
FPT_TST_EXT.1: TSF Testing
NOTE: for CC:2022 Part 2 conformance this SFR may be replaced in the next NDcPP release with FPT_TST.1. If so, then corresponding changes will need to be made here as well.
This SFR is functionally identical to what is defined in the NDcPP except that
the specific self-test of verifying the integrity of TSF executable code has been mandated as a minimum baseline for the requirement. Other self-tests may still be claimed at the ST author's discretion.
The text of the requirement is replaced with:
The TSF shall run a suite of the following self-tests during initial start-up (on power on) and [selection:
periodically during normal operation,
at the request of the authorized user,
at the conditions [assignment: conditions under which self-tests should occur],
in no other circumstances]
to demonstrate the correct operation of the TSF: integrity verification of stored TSF executable code when it is loaded for execution
through the use of the TSF-provided cryptographic service specified in FCS_COP.1/SigGen, [selection:
[assignment: list of additional self-tests run by the TSF],
no other self-tests].
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
For the sake of simplicity this has been defined as one single iteration rather than being split as in the proposed SFRs because of the amount of overlap between them. I think it is reasonable to say "whatever gets claimed gets audited" in one requirement.
The TSF shall be able to generate an audit record of the following
auditable events:
Start-up and shutdown of the audit functions
All auditable events for the [not specified] level of audit; and
A TOE that conforms to a Protection Profile Configuration (PP-Configuration) containing this PP-Module either can be a standalone or distributed TOE as defined in the NDcPP. For distributed TOEs, the expectation for this PP-Module is that a LiFi AS is composed of a single controller and one or more access points (APs). If the TOE is a distributed system across multiple components then they must be capable of sending audit data to the controller. If the TOE is a standalone system, audit data should be stored on the component that generates it.
The auditable events defined in Table t-audit-mandatory, Table t-audit-sel-based, and Table t-audit-impl-dep are for the SFRs that are explicitly defined in this PP-Module and are intended to extend FAU_GEN.1 in the Base-PP. The events in the Auditable Events table should be combined with those of the NDcPP in the context of a conforming Security Target. This table includes rows for all SFRs in the PP-Module. For any SFRs the ST claims, the corresponding audit events must also be claimed in the table. If the ST does not claim a particular SFR, then there is likewise no expectation that the auditable events for that SFR are required.
Per FAU_STG_EXT.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 each audit record at least the following
information:
Date and time of the event, type of event, subject identity (if
applicable), and the outcome (success or failure) of the event; and
For each audit event type, based on the auditable event
definitions of the functional components included in the PP/ST,
[additional information defined in Table atref-mandatory table for each auditable event, where applicable].
5.2.3 Cryptographic Support (FCS)
FCS_COP.1/LiFiDataEncryption Cryptographic Operation (Data Encryption and Decryption for LiFi
The TSF shall perform encryption/decryption in accordance with a specified cryptographic algorithm [AES-GCMP and [[selection: Cipher Block Chaining (CBC), CCMP, Counter (encryption mode) (CTR), Galois-Counter Mode (GCM), no other]] modes and cryptographic key sizes [256 bits] that meet the following: [AES as specified in ISO 18033-3, GCM as specified in ISO 19772, GCMP as specified in NIST SP 800-38D and IEEE 802.11ax-2021
[selection: CBC as specified in ISO 10116, CCMP as specified in NIST SP 800-38C and IEEE 802.11-2020, CTR as specified in ISO 10116, no other standards].
Application
Note:
Application Note: This requirement is iterated from its definition in the NDcPP by mandating the selection of CBC mode and 256 bit key sizes while also defining additional AES mode and key size selections not present in the original definition. This requirement mandates AES-GCMP (which uses AES in Galois-Counter Mode (GCM) to comply with IEEE 802.11-2020. For the first selection of FCS_COP.1.1/LiFiDataEncryption, the ST author should choose the additional mode or modes in which AES operates. For the second selection, the ST author should choose the key sizes that are supported by this functionality. 256-bit GCMP is required in order to comply with FCS_CKM.1/WPA. AES-CCMP, if claimed, is required to use 256-bit keys for IEEE 802.11ax-2021 connections. CTR mode is not used for LiFi AS capabilities but remains selectable since it may be required by another part of the TSF.
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 Extensible Authentication Protocol (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.
The TSF shall re-authenticate the user under the conditions [when the user changes their password,
[selection: following TSF-initiated session locking, [assignment:
other conditions], no other conditions]].
5.2.5 Security Management (FMT)
FMT_SMF.1/LiFi Specification of Management Functions
The TSF shall always randomize process address space memory locations with
[selection: 8, [assignment:
number greater than 8]]
bits of entropy except for
[assignment:
list of explicit exceptions].
The TSF shall [selection: employ stack-based buffer overflow protections, not store parameters or variables in the same data structures as control flow values].
Application
Note:
Many OSes store control flow values (i.e. return addresses) in stack data structures that also contain parameters and variables.
For these OSes, it is expected that most of the OS, to include the kernel, libraries, and application software from the OS vendor be compiled with stack-based buffer overflow protection enabled.
OSes that store parameters and variables separately from control flow values do not need additional stack protections.
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 LiFi
client is connecting to (e.g. specific LiFi 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.
For now this is added as a separate iteration of FTP_ITC.1 just for 802.1X rather than reaching back to the NDcPP as a modified SFR. This will disambiguate the protocols that apply to individual external interfaces but can be moved up to Modified SFRs instead if desired.
The TSF shall provide a communication channel using IEEE 802.1X and [selection: IPsec, RADIUS over TLS]
between itself and an 802.1X authentication server 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.
Application
Note:
This requirement has been iterated from its definition in the NDcPP to
mandate the communications protocols and environmental components that
a LiFI AS must use for 802.1X.
IPsec or RADIUS over TLS (commonly known as "RadSec") is required at least for communications with the 802.1X authentication server.
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" as specified in FTP_ITC.1 in the NDcPP
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.
This PP-Module identifies several SFRs from the
NDcPP that are needed to support
LiFi Access System functionality.
This is considered to be consistent because the functionality provided by the
NDcPP is being used for its intended purpose.
The rationale for why this does not conflict with the claims
defined by the
NDcPP are as follows:
This PP-Module modifies the Base-PP's definition of the SFR by defining a minimum baseline for what self-tests must be run. Additional self-tests
may still be specified by the ST author.
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 384 bits.
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.
FCS_CKM.2/DISTRIB Cryptographic Key Distribution (802.11 Keys)
This component must be included in the ST if the TOE implements any of the following features:
This is listed as optional in the WLAN AS module but not flagged as such in the LiFi requirements. If it should still be optional, this should be moved.
The TSF shall distribute the IEEE 802.11 keys in accordance with a
specified 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.
FCS_CKM.2/GTK Cryptographic Key Distribution (GTK)
This component must be included in the ST if the TOE implements any of the following features:
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.
FCS_CKM.2/PMK Cryptographic Key Distribution (PMK)
This component must be included in the ST if the TOE implements any of the following features:
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 LiFi AS product 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.
FIA_PSK_EXT.1 Pre-Shared Key Composition
This component must be included in the ST if any of the following SFRs are included:
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") as well.
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.
Do we need something similar for G.vlc? There was no equivalent to this in the Word doc requirements. Just checking as to whether anything is missing.
The TSF shall provide a communication channel using
WPA3-Enterprise, WPA2-Enterprise, and [selection: WPA3-SAE, WPA3-SAE-PK, WPA2-PSK, no other mode] as defined by IEEE 802.11-2020 to provide a trusted channel
between itself and LiFi 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.
Application
Note:
This requirement has been iterated from its definition in the NDcPP to
mandate support for 802.11 specifically for LiFi client access.
The TSF shall provide a communication channel for G.vlc using MACsec to provide a trusted channel
between itself and a MACsec peer 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.
Application
Note:
This requirement has been iterated from its definition in the NDcPP to
mandate support for MACsec.
Updated to remove 128-bit ciphers and TLS 1.1. Does TLS 1.3 need to be selectable here and do the ciphers need to change further?
The TSF shall implement TLS 1.2 and no earlier TLS versions when acting as a RADIUS over TLS client that supports the following ciphersuites:
[selection:
TLS_PSK_WITH_AES_256_CBC_SHA
TLS_DHE_PSK_WITH_AES_256_CBC_SHA
TLS_RSA_PSK_WITH_AES_256_CBC_SHA
TLS_PSK_WITH_AES_256_GCM_SHA384
TLS_DHE_PSK_WITH_AES_256_GCM_SHA384
TLS_RSA_PSK_WITH_AES_256_GCM_SHA384
].
Application
Note:
If any of the TLS_RSA_PSK ciphersuites are selected by the ST author,
it is necessary to claim the selection-based requirement FCS_RADSEC_EXT.3.
The above ciphersuites are only for use when the TSF is acting as a RADIUS over TLS client,
not for other uses of the TLS protocol.
The ciphersuites to be tested in the evaluated configuration are limited by this requirement.
The ST author should select the ciphersuites that are supported.
If "X.509v3 certificates" is selected in FCS_RADSEC_EXT.1.2,
the ciphersuites selected in (and tested by) FCS_TLSC_EXT.1.1 in the Functional Package for TLS are also supported for
RADIUS over TLS client use.
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.
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 Class
Functional Components
Cryptographic Support (FCS)
FCS_RADSEC_EXT RadSec
Identification and Authentication (FIA)
FIA_8021X_EXT 802.1X Port Access Entity (Authenticator) Authentication
This PP-Module defines the following extended components as part of the
FCS class originally defined by CC Part 2:
C.2.1.1 FCS_RADSEC_EXT RadSec
Family Behavior
Components in this family describe requirements for implementation of the RadSec (RADIUS over TLS) protocol.
Component Leveling
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.
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] and reject all other TLS and SSL versions.
The TLS implementation shall support the following ciphersuites for use when acting as a RADIUS over TLS client: [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 Identification and Authentication (FIA)
This PP-Module defines the following extended components as part of the
FIA class originally defined by CC Part 2:
C.2.2.1 FIA_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_EXT.1,
802.1X 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 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.3 Protection of the TSF (FPT)
This PP-Module defines the following extended components as part of the
FPT class originally defined by CC Part 2:
C.2.3.1 FPT_ASLR_EXT Address Space Layout Randomization
Family Behavior
This family defines the ability of the TOE to implement address space layout randomization (ASLR). This
is a new family defined for the FPT class.
Component Leveling
FPT_ASLR_EXT.1,
Address Space Layout Randomization,
defines the ability of the TOE to use ASLR as
well as the objects that ASLR is applied to.
Management: FPT_ASLR_EXT.1
There are no management functions foreseen.
Audit: FPT_ASLR_EXT.1
There are no auditable events foreseen.
FPT_ASLR_EXT.1 Address Space Layout Randomization
Hierarchical to:
No other components.
Dependencies to:
No dependencies.
FPT_ASLR_EXT.1.1
The TSF shall always randomize process address space memory locations with
[selection: 8, [assignment:
number greater than 8]]
bits of entropy except for
[assignment:
list of explicit exceptions].
C.2.4 Security Management (FMT)
This PP-Module defines the following extended components as part of the
FMT class originally defined by CC Part 2:
