Version: 4.0
2025-11-25
National Information Assurance Partnership
| Version | Date | Comment |
|---|---|---|
| 0.1 | 2014-09-05 | Draft published for Public review |
| 0.2 | 2014-10-13 | Internal draft in response to public review comments, for iTC review |
| 0.3 | 2014-10-17 | Draft version released to accompany CCDB review of Supporting Document. |
| 0.4 | 2015-01-26 | Incorporated comments received from the CCDB review |
| 1.0 | 2015-02-27 | Released for use |
| 1.1 | 2016-07-21 | Updated draft published for public review |
| 2.0 | 2017-05-05 | Released for use |
| 2.1 | 2018-09-24 | Released for use |
| 2.2 | 2019-12-20 | Released for use |
| 2.2e | 2020-03-23 | Released for use |
| 3 | 2023-04-06 | Incorporated comments received. Released for use |
| 2023-12-06 | Released for use | |
| 4 | 2025-11-25 | Released for use |
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. |
Direct Rationale | A type of Protection Profile, PP-Module, or Security Target in which the security problem definition (SPD) elements are mapped directly to the SFRs and possibly to the security objectives for the operational environment. There are no security objectives for the TOE. |
Distributed TOE | A TOE composed of multiple components operating as a logical whole. |
Extended Package (EP) | A deprecated document form for collecting SFRs that implement a particular protocol, technology, or functionality. See Functional Packages. |
Functional Package (FP) | A document that collects SFRs for a particular protocol, technology, or functionality. |
Operational Environment (OE) | Hardware and software that are outside the TOE boundary that support the TOE functionality and security policy. |
Protection Profile (PP) | An implementation-independent set of security requirements for a category of products. |
Protection Profile Configuration (PP-Configuration) | A comprehensive set of security requirements for a product type that consists of at least one Base-PP and at least one PP-Module. |
Protection Profile Module (PP-Module) | An implementation-independent statement of security needs for a TOE type complementary to one or more Base-PPs. |
Security Assurance Requirement (SAR) | A requirement to assure the security of the TOE. |
Security Functional Requirement (SFR) | A requirement for security enforcement by the TOE. |
Security Target (ST) | A set of implementation-dependent security requirements for a specific product. |
Target of Evaluation (TOE) | The product under evaluation. |
TOE Security Functionality (TSF) | The security functionality of the product under evaluation. |
TOE Summary Specification (TSS) | A description of how a TOE satisfies the SFRs in an ST. |
If this feature is implemented by the TOE, the following requirements must be claimed in the ST:
If this feature is implemented by the TOE, the following requirements must be claimed in the ST:
If this feature is implemented by the TOE, the following requirements must be claimed in the ST:
If this feature is implemented by the TOE, the following requirements must be claimed in the ST:
If this feature is implemented by the TOE, the following requirements must be claimed in the ST:
If this feature is implemented by the TOE, the following requirements must be claimed in the ST:
If this feature is implemented by the TOE, the following requirements must be claimed in the ST:
A Network Device has a network infrastructure role that it is designed to provide. In doing so, the Network Device communicates with other Network Devices and other network entities (i.e. entities not defined as Network Devices because they do not have an infrastructure role) over the network. At the same time, it must provide a minimal set of common security functionality expected by all Network Devices. The security problem to be addressed by a compliant Network Device is defined as this set of common security functionality that addresses the threats that are common to Network Devices, as opposed to those that might be targeting the specific functionality of a specific type of Network Device. The set of common security functionality addresses communication with the Network Device, both authorized and unauthorized, the ability to perform valid and secure updates, the ability to audit device activity, the ability to securely store and utilize device and Administrator credentials and data, and the ability to self-test critical device components for failures.
The threats for the Network Device are grouped according to functional areas of the device in the sections below. The description of each threat is then followed by a rationale describing how it is addressed by the SFRs in Section 6, Annex A, and Annex B.
Threat agents may compromise credentials and device data enabling continued access to the Network Device and its critical data. The compromise of credentials includes replacing existing credentials with an attacker’s credentials, modifying existing credentials, or obtaining the Administrator or device credentials for use by the attacker. Threat agents may also be able to take advantage of weak administrative passwords to gain privileged access to the device.
An external, unauthorised entity could make use of failed or compromised security functionality and might therefore subsequently use or abuse security functions without prior authentication to access, change or modify device data, critical network traffic or security functionality of the device.
Threat agents may attempt to gain Administrator access to the Network Device by nefarious means such as masquerading as an Administrator to the device, masquerading as the device to an Administrator, replaying an administrative session (in its entirety, or selected portions), or performing man-in-the-middle attacks, which would provide access to the administrative session, or sessions between Network Devices. Successfully gaining Administrator access allows malicious actions that compromise the security functionality of the device and the network on which it resides.
Threat agents may attempt to access, change, and/or modify the security functionality of the Network Device without Administrator awareness. This could result in the attacker finding an avenue (e.g., misconfiguration, flaw in the product) to compromise the device and the Administrator would have no knowledge that the device has been compromised.
Threat agents may attempt to target Network Devices that do not use standardized secure tunnelling protocols to protect the critical network traffic. Attackers may take advantage of poorly designed protocols or poor key management to successfully perform man-in-the-middle attacks, replay attacks, etc. Successful attacks will result in loss of confidentiality and integrity of the critical network traffic and potentially could lead to a compromise of the Network Device itself.
Threat agents may attempt to provide a compromised update of the software or firmware which undermines the security functionality of the device. Non-validated updates or updates validated using non-secure or weak cryptography leave the update firmware vulnerable to surreptitious alteration.
Threat agents may take advantage of secure protocols that use weak methods to authenticate the endpoints, e.g., a shared password that is guessable or transported as plaintext. The consequences are the same as a poorly designed protocol, the attacker could masquerade as the Administrator or another device, and the attacker could insert themselves into the network stream and perform a man-in-the-middle attack. The result is the critical network traffic is exposed and there could be a loss of confidentiality and integrity, and potentially the Network Device itself could be compromised.
Threat agents may exploit weak cryptographic algorithms or perform an exhaustive search against a weak cryptographic key to gain access to critical security parameters or manipulate TSF data. Flawed or deprecated cryptographic algorithms, insecure modes of operation, predictable pseudorandom numbers, and too-small key sizes might allow attackers to compromise secure communications, gain unauthorised access, or allow to intercept and decrypt sensitive data.
This section describes the assumptions made in identification of the threats and security requirements for Network Devices. The Network Device is not expected to provide assurance in any of these areas, and as a result, requirements are not included to mitigate the threats associated.
The Administrator’s credentials (private keys) used to access the Network Device are protected by the platform on which they reside.
For distributed TOEs, it is assumed that the availability of all TOE components is checked as appropriate to reduce the risk of an undetected attack on (or failure of) one or more TOE components. It is also assumed that in addition to the availability of all components it is also checked as appropriate that the audit functionality is running properly on all TOE components.
The device is assumed to provide networking functionality as its core function. TOE administrators are assumed to treat the TOE as not being a general-purpose computing platform and will not attempt to install or execute any non-TOE software or enable functionality unrelated to the TOE’s networking purpose, regardless of whether the platform provides an interface that could technically permit such actions.
Note: For a virtual TOE evaluated as a pND, following Case 2 vNDs as specified in Section 1.2, the VS is considered part of the TOE with only one vND instance for each physical hardware platform. The exception being where components of a distributed TOE run inside more than one virtual machine (VM) on a single VS. In Case 2 vND, no non-TOE guest VMs are allowed on the platform.
A standard/generic Network Device does not provide any assurance regarding the protection of traffic that traverses it. The intent is for the Network Device to protect data that originates on or is destined to the device itself, to include administrative data and audit data.
Note: Traffic that is traversing the Network Device, destined for another network entity, is not covered by the ND cPP. Additional protection will be covered by cPPs and PP-Modules for particular types of Network Devices (e.g., firewall).
The Network Device is assumed to be physically protected in its operational environment and not subject to physical attacks that compromise the security or interfere with the device’s physical interconnections and correct operation. This protection is assumed to be sufficient to protect the device and the data it contains. As a result, the cPP does not include any requirements on physical tamper protection or other physical attack mitigations. The cPP does not expect the product to defend against physical access to the device that allows unauthorised entities to extract data, bypass other controls, or otherwise manipulate the device. For vNDs, this assumption applies to the physical platform on which the VM runs.
The Network Device firmware and software is assumed to be updated by an Administrator on a regular basis in response to the release of product updates due to known vulnerabilities.
The Administrator must ensure that there is no unauthorised access possible for sensitive residual information (e.g., cryptographic keys, keying material, PINs, passwords etc.) on networking equipment when the equipment is discarded or removed from its operational environment.
The Security Administrator(s) for the Network Device are assumed to be trusted and to act in the best interest of security for the organization. This includes appropriate training, following policy, and adhering to guidance documentation. Administrators are trusted to ensure passwords/credentials have sufficient strength and entropy and to lack malicious intent when administering the device. The Network Device is not expected to be capable of defending against a malicious Administrator that actively works to bypass or compromise the security of the device.
For TOEs supporting X.509v3 certificate-based authentication, the Security Administrator(s) are expected to fully validate (e.g., offline verification) any CA certificate (root CA certificate or intermediate CA certificate) loaded into the TOE’s trust store (aka 'root store', ' trusted CA Key Store', or similar) as a trust anchor prior to use (e.g., offline verification).
For vNDs, it is assumed that the VS and VMs are correctly configured to support ND functionality implemented in VMs.
For vNDs, it is assumed that the VS implements and is configured to provide the necessary mechanisms to isolate resources of all VMs running on the same platform. Both virtual and physical resources require access control. It is assumed the VS enforces access control to all physical and virtual resources in support of isolation. In particular, it is assumed the VS implements mechanisms to isolate all resources associated with virtual networks and to limit a VM’s access to only those virtual networks for which it has been configured. Furthermore, it is assumed that the VS adequately protects itself from software running inside VMs on the same platform.
The VS software is assumed to be updated by the VS Administrator on a regular basis in response to the release of product updates due to known vulnerabilities.
The Security Administrators for the VS are assumed to be trusted and to act in the best interest of security for the organization. This includes not interfering with the correct operation of the device. The Network Device is not expected to be capable of defending against a malicious VS Administrator that actively works to bypass or compromise the security of the device.
The Administrator’s credentials (private keys) used to access the TOE must be protected on any other platform on which they reside.
For distributed TOEs, the Security Administrator ensures that the availability of every TOE component is checked as appropriate to reduce the risk of an undetected attack on (or failure of) one or more TOE components. The Security Administrator also ensures that it is checked as appropriate for every TOE component that the audit functionality is running properly.
There are no general-purpose computing capabilities (e.g., compilers or user applications) available on the TOE, other than those services necessary for the operation, administration and support of the TOE. Note: For vNDs the TOE includes only the contents of its own VM, and does not include other VMs or the VS.
The TOE does not provide any protection of traffic that traverses it. It is assumed that protection of this traffic will be covered by other security and assurance measures in the operational environment.
Physical security, commensurate with the value of the TOE and the data it contains, is provided by the environment.
The Security Administrator ensures that there is no unauthorised access possible for sensitive residual information (e.g., cryptographic keys, keying material, PINs, passwords etc.) on networking equipment when the equipment is discarded or removed from its operational environment. For vNDs, this applies when the physical platform on which the VM runs is removed from its operational environment.
Security Administrators are trusted to follow and apply all guidance documentation in a trusted manner. For vNDs, this includes the VS Administrator responsible for configuring the VMs that implement ND functionality.
For TOEs supporting X.509v3 certificate-based authentication, the Security Administrator is assumed to monitor the revocation status of all certificates in the TOE’s trust store and to remove any certificate from the TOE’s trust store in case such certificate can no longer be trusted.
The TOE firmware and software are updated by an Administrator on a regular basis in response to the release of product updates due to known vulnerabilities.
For vNDs, the Security Administrator ensures that the VS and VMs are configured to
reduce the attack surface of VMs as much as possible while supporting ND functionality (e.g., remove unnecessary virtual hardware, turn off unused interVM communications mechanisms), and
correctly implement ND functionality (e.g., ensure virtual networking is properly configured to support network traffic, management channels, and audit reporting).
The VS should be operated in a manner that reduces the likelihood that vND operations are adversely affected by virtualization features such as cloning, save/restore, suspend/resume, and live migration.
If possible, the VS should be configured to make use of features that leverage the VS’s privileged position to provide additional security functionality. Such features could include malware detection through VM introspection, measured VM boot, or VM snapshot for forensic analysis.
| Assumption or OSP | Security Objectives | Rationale |
| A.ADMIN_CREDENTIALS_SECURE | OE.ADMIN_CREDENTIALS_SECURE | |
| A.COMPONENTS_RUNNING (applies to distributed TOEs only) | OE.COMPONENTS_RUNNING (applies to distributed TOEs only) | |
| A.LIMITED_FUNCTIONALITY | OE.NO_GENERAL_PURPOSE | |
| A.NO_THRU_TRAFFIC_PROTECTION | OE.NO_THRU_TRAFFIC_PROTECTION | |
| A.PHYSICAL_PROTECTION | OE.PHYSICAL | |
| A.REGULAR_UPDATES | OE.UPDATES | |
| A.RESIDUAL_INFORMATION | OE.RESIDUAL_INFORMATION | |
| A.TRUSTED_ADMINISTRATOR | OE.TRUSTED_ADMIN | |
| A.VS_CORRECT_CONFIGURATION (applies to vNDs only) | OE.VM_CONFIGURATION (applies to vNDs only) | |
| A.VS_ISOLATION (applies to vNDs only) | OE.VM_CONFIGURATION (applies to vNDs only) | |
| A.VS_REGULAR_UPDATES (applies to vNDs only) | OE.UPDATES | |
| A.VS_TRUSTED_ADMINISTRATOR (applies to vNDs only) | OE.TRUSTED_ADMIN |
| Requirement | Auditable Events | Additional Audit Record Contents |
|---|---|---|
| FAU_GEN.1 | ||
| No events specified | N/A | |
| FAU_GEN.2 | ||
| No events specified | N/A | |
| FAU_STG_EXT.1 | ||
| Configuration of local audit settings. | Identity of account making changes to the audit configuration. | |
| FCS_CKM.1/AKG | ||
| No events specified | N/A | |
| FCS_CKM.6 | ||
| No events specified | N/A | |
| FCS_CKM_EXT.7 | ||
| No events specified | N/A | |
| FCS_COP.1/DataEncryption | ||
| No events specified | N/A | |
| FCS_COP.1/Hash | ||
| No events specified | N/A | |
| FCS_COP.1/KeyedHash | ||
| No events specified | N/A | |
| FCS_COP.1/SigGen | ||
| No events specified | N/A | |
| FCS_RBG.1 | ||
| No events specified | N/A | |
| FIA_UIA_EXT.1 | ||
| All use of identification and authentication mechanisms. | Origin of the attempt (e.g., IP address). | |
| FMT_MOF.1/ManualUpdate | ||
| Any attempt to initiate a manual update. | No additional information | |
| FMT_MTD.1/CoreData | ||
| No events specified | N/A | |
| FMT_SMF.1 | ||
| All management activities of TSF data. | No additional information | |
| FMT_SMR.2 | ||
| No events specified | N/A | |
| FPT_SKP_EXT.1 | ||
| No events specified | N/A | |
| FPT_STM_EXT.1 | ||
| Discontinuous changes to time - either Administrator actuated or changed via an automated process. (Note: No continuous changes to time need to be logged. See also application note on FPT_STM_EXT.1) | For discontinuous changes to time: The old and new values for the time. Origin of the attempt to change time for success and failure (e.g., IP address). | |
| FPT_TST_EXT.1 | ||
| No events specified | N/A | |
| FPT_TUD_EXT.1 | ||
| Initiation of update; result of the update attempt (success or failure). | No additional information | |
| FTA_SSL.3 | ||
| The termination of a remote session by the session locking mechanism. | No additional information | |
| FTA_SSL.4 | ||
| The termination of an interactive session. | No additional information | |
| FTA_TAB.1 | ||
| No events specified | N/A | |
| FTP_ITC.1 | ||
| Initiation of the trusted channel. | No additional information | |
| Termination of the trusted channel. | No additional information | |
| Failure of the trusted channel functions. | Reason for failure | |
| FTP_TRP.1/Admin | ||
| Initiation of the trusted path. | No additional information | |
| Termination of the trusted path. | No additional information | |
| Failure of the trusted path functions. | Reason for failure. |
Start-up and shut-down of the audit functions;
All auditable events for the not specified level of audit; and
All administrative actions comprising:
Administrative login and logout (name of Administrator account shall be logged if individual accounts are required for Administrators).
Changes to TSF data related to configuration changes (in addition to the information that a change occurred it shall be logged what has been changed).
Generating/import of, changing, or deleting of cryptographic keys (in addition to the action itself a unique key name or key reference shall be logged).
;
Specifically defined auditable events listed in Table 2.
Application Note 1
If the list of ‘administrative actions’ appears to be incomplete, the assignment in the selection should be used to list additional administrative actions which are audited.
The requirement to audit the "Generating/import of, changing, or deleting of cryptographic keys" refers to all types of cryptographic keys which are intended to be used longer than for just one session (i.e., it does not refer to ephemeral keys/session keys). The requirement applies to all named changes independently from how they are invoked. A cryptographic key could be generated automatically during initial start-up without administrator intervention or through administrator intervention. This requirement also applies to the management of cryptographic keys by adding, replacing or removing trust anchors in the TOE’s trust store. In all related cases the changes to cryptographic keys need to be audited together with a unique key name, key reference or unique identifier for the corresponding certificate.
The ST author replaces the cross-reference to the table of audit events with an appropriate cross-reference for the ST.
For distributed TOEs, each component must generate an audit record for each of the SFRs that it implements. If more than one TOE component is involved when an audit event is triggered, the event has to be audited on each component (e.g., rejection of a connection by one component while attempting to establish a secure communication channel between two components should result in an audit event being generated by both components). This is not limited to error cases but also includes events about successful actions like successful build up/tear down of a secure communication channel between TOE components.
Application Note 2
The ST author can include other auditable events directly in the table; they are not limited to the list presented.
The audit events that correspond to defined management functions are highly dependent on the FMT_SMF.1 selections. Therefore, there is only a generic requirement specified in Table 2 for FMT_SMF.1 ('All management activities of TSF data.') that is intended to cover all mandatory and selection-based management functions. If, for example, the ‘Ability to enable or disable automatic checking for updates or automatic updates’ is selected as part of FMT_SMF.1, all actions of enabling or disabling automatic checking for updates or automatic updates should be audited. Audit of management functions is intended to record both the issuing and the result of the command/administrative action. The corresponding audit event can be recorded as either a single audit record or multiple audit records. In cases where a management function could conceivably fail, such as updating the TOE, there must exist an audit record indicating the outcome, such as the successful completion of the update process.
With respect to FAU_GEN.1.1, FMT_SMF.1 and FMT_MOF.1/Services the term ‘services’ refers to trusted path and trusted channel communications, on demand self-tests, trusted update and Administrator sessions (that exist under the trusted path) (e.g., netconf).
The TSF shall record within the audit data at least the following information:
Date and time of the auditable event, type of event, subject identity (if applicable), and the outcome (success or failure) of the event; and
For each auditable event type, based on the auditable event definitions of the functional components included in the cPP, PP-Module, functional package or ST, information specified in column three of Table 2.
Application Note 3
The ST author replaces the cross-reference to the table of audit events with an appropriate cross-reference for the ST. If the TOE does not implement functionality that enables the administrator to configure local audit settings, then item FAU_STG_EXT.1 in Table 2 should be considered ‘trivially satisfied’ and the ST author should include an explanation that the local audit is not configurable in the TSS.
The date and time information for any audit event should be recorded as part of each audit record to ensure the timing of the event can be unambiguously determined from the data contained in the audit record. The representation of date and time information recorded for each event needs to allow unambiguous determination of at least day, month and year information for the date and hours, minutes and second information for the time.
Application Note 4
Additional audit events will apply to the TOE depending on the optional and selection-based requirements adopted from Annex A, Annex B, PP-Module(s), and functional package(s). For all SFRs included in the ST, the ST must include the relevant additional auditable events specified in Table 10 for optional SFRs, Table 11 for selection-based SFRs, the claimed PP-Module(s), and the claimed functional package(s). All audit events defined in Table 2 have to be included in the ST as they are mandatory.
Application Note 6
For selecting the option of transmission of generated audit data to an external IT entity the TOE relies on a non-TOE audit server for storage and review of audit records. The storage of these audit records and the ability to allow the Administrator to review these audit records is provided by the operational environment in that case. Since the external audit server is not part of the TOE, there are no requirements on it except the capabilities for FTP_ITC.1 transport for audit data. No requirements are placed upon the format or underlying protocol of the audit data being transferred. The TOE must be capable of being configured to transfer audit data to an external IT entity without Administrator intervention. Manual transfer would not meet the requirements. Transmission could be done in real-time or periodically. If the transmission is not done in real-time then the TSS describes what event stimulates the transmission to be made and what range of frequencies the TOE supports for making transfers of audit data to the audit server, the TSS also suggests typical acceptable frequencies for the transfer.
For distributed TOEs, each component must be able to export audit data across a protected channel external (FTP_ITC.1) or intercomponent (FPT_ITT.1 or FTP_ITC.1) as appropriate. At least one component of the TOE must be able to export audit records via FTP_ITC.1 such that all TOE audit records can be exported to an external IT entity.
An ‘external IT entity’ (physical or virtualized) is another device or computer on the network in which the TOE no longer has access to the audit records. This can be a physical or virtualized entity.
The TSF shall be able to store generated audit data on the TOE itself. In addition
[selection: The TOE shall consist of a single standalone component that stores audit data locally, The TOE shall be a distributed TOE that stores audit data on the following TOE components: [assignment: identification of TOE components], The TOE shall be a distributed TOE with storage of audit data provided externally for the following TOE components: [assignment: list of TOE components that do not store audit data locally and the other TOE components to which they transmit their generated audit data]]Application Note 7
If the TOE is a standalone TOE (i.e., not a distributed TOE) the option 'The TOE should consist of a single standalone component that stores audit data locally' must be selected.
If the TOE is a distributed TOE, the option 'The TOE should be a distributed TOE that stores audit data on the following TOE components: [assignment: identification of TOE components]' must be selected and the TOE components which store audit data locally must be listed in the assignment. Since all TOEs are required to provide functions to store audit data locally this option needs to be selected for all distributed TOEs. In addition, FAU_GEN_EXT.1 and FAU_STG_EXT.4 must be claimed in the ST. If the distributed TOE consists only of components which are storing audit data locally, it is sufficient to select only the option 'The TOE should be a distributed TOE that stores audit data on the following TOE components: [assignment: identification of TOE components]' and add FAU_GEN_EXT.1 and FAU_STG_EXT.4.
If the TOE is a distributed TOE and some TOE components are not storing audit data locally, the option 'The TOE should be a distributed TOE with storage of audit data provided externally for the following TOE components: [assignment: list of TOE components that do not store audit data locally and the other TOE components to which they transmit their generated audit data]' must be selected in addition to the option 'The TOE should be a distributed TOE that stores audit data on the following TOE components: [assignment: identification of TOE components]'. In that case FAU_STG_EXT.5 must be claimed in the ST in addition to FAU_GEN_EXT.1 and FAU_STG_EXT.4. For the option 'The TOE should be a distributed TOE with storage of audit data provided externally for the following TOE components: [assignment: list of TOE components that do not store audit data locally and the other TOE components to which they transmit their generated audit data]' the TOE components that do not store audit data locally should be mapped to the TOE components to which they transmit their generated audit data.
For distributed TOEs, this SFR can be fulfilled either by every TOE component storing its own security audit data locally or by one or more TOE components storing audit data locally and other TOE components which are not storing audit information locally sending security audit data to other TOE components for local storage. For the transfer of security audit data between TOE components a protected channel according to FTP_ITC.1 or FPT_ITT.1 must be used. The TSS describes which TOE components store security audit data locally and which TOE components do not store security audit data locally. For the latter, the TSS describes which other TOE component the audit data is stored locally.
For pNDs, ‘on the TOE itself’ or ‘locally’ means on storage inside or directly attached to the ND chassis and accessible by the networking functionality.
For vNDs, local storage is any storage accessible by TOE software. In a virtualized environment, ‘local’ storage is under the control of the VS and may be physically located on the local host, but it could also be located on a network drive or storage array.
Application Note 8
Persistent logging is defined as any record(s) that is retained through power off, power failure, or reboot. This requirement allows for the TSF to implement logging either persistent log records or non-persistent log records that may be cleared on reboot of the TOE.
Application Note 9
The ST author may use the "other action" assignment to describe other measurable behaviour (e.g., frequency of log file rotation based on size and/or age of log files).
For distributed TOEs, each component is not required to store generated audit data locally, but the overall TOE needs to be able to store audit data locally. Each component must at least provide the ability to temporarily buffer audit information locally to ensure that audit records are preserved in case of network connectivity issues. Buffering audit information locally, does not necessarily involve non-volatile memory: audit information could be buffered in volatile memory. However, the local storage of audit information in the sense of FAU_STG_EXT.1.5 needs to be done in non-volatile memory. For every component which performs local storage of audit information, the behaviour when local storage is exhausted needs to be described. For every component which is buffering audit information instead of storing audit information locally itself, it needs to be described what happens in case the buffer space is exhausted.
Application Note 10
If "ability to view locally" is selected in FAU_STG_EXT.1.6, then FAU_SAR.1 from Annex B must be included in the ST.
The TSF shall generate asymmetric cryptographic keys in accordance with a specified cryptographic key generation algorithm:
[selection: Cryptographic Key Generation Algorithm] and specified cryptographic algorithm parameters [selection: Cryptographic Algorithm Parameters] that meet the following: [selection: List of Standards] . The following table provides the allowed choices for completion of the selection operations of FCS_CKM.1.1/AKG.| Identifier | Cryptographic Key Generation Algorithm | Cryptographic Algorithm Parameters | List of Standards |
|---|---|---|---|
| RSA | RSA | Modulus of size [selection: 2048, 3072, 4096, 6144, 8192] bits | NIST FIPS PUB 186-5 (Section A.1.1) |
| ECC-ERB | ECC-ERB - Extra Random Bits | Elliptic Curve [selection: P-256, P-384, P-521] | NIST FIPS PUB 186-5 (Section A.2.1), NIST SP 800-186 (Section 3) [NIST Curves] |
| ECC-RS | ECC-RS - Rejection Sampling | Elliptic Curve [selection: P-256, P-384, P-521] | NIST FIPS PUB 186-5 (Section A.2.2), NIST SP 800-186 (Section 3) [NIST Curves] |
| FFC-ERB | FFC-ERB - Extra Random Bits | Static domain parameters approved for [selection:
| NIST SP 800-56A Revision 3 (Section 5.6.1.1.3), [selection: RFC 3526 [IKE groups], RFC 7919 [TLS groups]] |
| FCC-RS | FCC-RS - Extra Random Bits | Static domain parameters approved for [selection:
| NIST SP 800-56A Revision 3 (Section 5.6.1.1.3), [selection: RFC 3526 [IKE groups], RFC 7919 [TLS groups]] |
| LMS | LMS | private key size [selection: ] Winternitz parameter = [selection: 1, 2, 4, 8],Tree height = [selection: 5, 10, 15, 20, 25] | RFC 8554 [LMS], NIST SP 800-208 [parameters] |
| XMSS | XMSS | private key size [selection: ] Tree height = [selection: 10, 16, 20] | RFC 8391 [XMSS], NIST SP 800-208 [parameters] |
| ML-KEM | ML-KEM | Parameter set = ML-KEM-1024 | NIST FIPS PUB 203 |
| ML-DSA | ML-DSA | Parameter set = ML-DSA-87 | NIST FIPS PUB 204 |
Application Note 11
The ST author selects all key generation algorithms used for key agreement (including generation of ephemeral keys) and device authentication.
For RSA the choice of the modulus implies the resulting key sizes of the public and private keys generated using the specified standard methods.
When generating ECC keys pairs for key agreement and if “ECDH” is claimed in FCS_CKM_EXT.7, then “ECC–ERB” or “ECC–RS” must be claimed. The sizes of the private key, which is a scalar, and the public key, which is a point on the elliptic curve, are determined by the choice of the curve.
For Finite Field Cryptography (FFC), “FFC-ERB” or “FFC–RS” may be claimed only for generating private and public keys when “DH” is claimed in FCS_CKM_EXT.7.
The MODP Diffie-Hellman groups do not necessarily adhere to the protocol restrictions specified as IKE groups. MODP Diffie-Hellman groups may also be used in other protocols such as TLS 1.2.
When generating ECC key pairs for digital signature generation and if “ECDSA” is claimed in FCS_COP.1/SigGen, then “ECC–ERB” or “ECC–RS” must be claimed. The sizes of the private key, which is a scalar, and the public key, which is a point on the elliptic curve, are determined by the choice of the curve.
When key generation is used for device authentication, other than non-X.509 SSH authentication algorithm, the public key is expected to be associated with an X.509v3 certificate.
Application Note 12
The TOE will have mechanisms to destroy keys, including intermediate keys and key material, by using an approved method as specified in FCS_CKM.6.2. Examples of keys include intermediate keys, leaf keys, encryption keys, and signing keys. Key material includes seeds, authentication secrets, passwords, PINs, and other secret values used to derive keys.
This SFR does not apply to the public component of asymmetric key pairs or to keys that are permitted to remain stored, such as device identification keys.
The TSF shall destroy plaintext cryptographic keys and keying material specified by FCS_CKM.6.1 in accordance with a specified cryptographic key destruction method
[selection:] that meets the following: [no standard].
In the case of volatile memory, the selection “removal of all references to the key directly followed by a request for garbage collection” is used in a situation where the TSF cannot address the specific physical memory locations holding the data to be erased and therefore relies on addressing logical addresses (which frees the relevant physical addresses holding the old data) and then requesting the platform to ensure that the data in the physical addresses is no longer available for reading (i.e., the “garbage collection” referred to in the SFR text).
In parts of the selections where keys are identified as being destroyed by “a part of the TSF”, the TSS identifies the relevant part and the interface involved. The interface referenced in the requirement could take different forms for different TOEs, the most likely of which is an application programming interface to an OS kernel. There may be various levels of abstraction visible. For instance, in a given implementation the application may have access to the file system details and may be able to logically address specific memory locations. In another implementation the application may simply have a handle to a resource and can only ask another part of the TSF such as the interpreter or OS to delete the resource.
Where different key destruction methods are used for different keys and/or different destruction situations then the different methods and the keys/situations they apply to are described in the TSS (and the ST may use separate iterations of the SFR to aid clarity). The TSS describes all relevant keys used in the implementation of SFRs, including cases where the keys are stored in a non-plaintext form. In the case of non-plaintext storage, the encryption method and relevant key-encrypting-key are identified in the TSS.
The selection for destruction of data in non-volatile memory includes block erase as an option, and this option applies only to flash memory. A block erase does not require a read verify, since the mappings of logical addresses to the erased memory locations are erased, as well as the data itself.
Some selections allow the assignment of “some value that does not contain any CSP.” This means that the TOE uses some specified data not drawn from an RBG meeting FCS_RBG requirements and not being any of the values listed as other selection options. The point of the phrase “does not contain any CSP” is to ensure that the overwritten data is carefully selected and not taken from a general pool that might contain data that itself requires confidentiality protection.
The TSF shall derive shared cryptographic keys with input from multiple parties in accordance with specified cryptographic key agreement algorithms
[selection: Cryptographic Key Generation Algorithm] and specified cryptographic parameters [selection: Cryptographic Algorithm Parameters] that meet the following: [selection: List of Standards] The following table provides the allowed choices for completion of the selection operations of FCS_CKM_EXT.7.1.| Identifier | Cryptographic Key Generation Algorithm | Cryptographic Algorithm Parameters | List of Standards |
|---|---|---|---|
| DH | Finite Field Cryptography Diffie-Hellman | Static domain parameters approved for [selection:
| NIST SP 800-56A Revision 3 (Section 5.7.1.1), [selection: RFC 3526 [IKE groups], RFC 7919 [TLS groups]] |
| ECDH | Elliptic Curve Diffie-Hellman | Elliptic Curve [selection: P-256, P-384, P-521] | NIST SP 800-56A Revision 3 (Section 5.7.1.2) [ECDH]NIST SP 800-186 (Section 3.2.1) [NIST Curves] |
Application Note 14
This requirement specifies key transport schemes. Key agreement schemes refer to cases in which two or more parties want to establish a single key between them, and all parties contribute to the entropy of the agreed-upon key.
The ST author selects all key agreement schemes used for the selected cryptographic protocols.
The elliptic curves used for the key agreement scheme correlate with the curves specified in FCS_CKM.1.1/AKG.
The static domain parameters approved for the finite field-based key agreement scheme are specified by the key generation according to FCS_CKM.1.1/AKG.
The TSF shall perform encryption/decryption in accordance with a specified cryptographic algorithm AES operating in
[selection: CBC mode as defined in FCS_COP.1/SKC, CTR mode as defined in FCS_COP.1/SKC, XTS mode as defined in FCS_COP.1/SKC, CCM mode as defined in FCS_COP.1/AEAD, GCM mode as defined in FCS_COP.1/AEAD].Application Note 15
The ST author selects the mode or modes in which AES operates. If CBC mode, CTR mode, or XTS mode is selected then FCS_COP.1/SKC from Annex B must be included. If CCM mode or GCM mode is selected, then FCS_COP.1/AEAD from Annex B must be included.
The TSF shall perform cryptographic hashing in accordance with a specified cryptographic algorithm
[selection: SHA-256, SHA-384, SHA-512, SHA3-256, SHA3-384, SHA3-512] that meets the following: [selection: ISO/IEC 10118-3:2018 [SHA, SHA3], FIPS PUB 180-4 [SHA], FIPS PUB 202 [SHA3]].Application Note 18
The hash function selection should have an output length that is the same or greater than the security strength of the algorithm used for signature generation. For example, the TOE should choose SHA-384 for 3072-bit RSA, 4096-bit RSA, or ECC with P-384; and SHA-512 for ECC with P-521. The ST author selects the standard based on the algorithms selected. For FCS_COP.1.1/Hash, SHA3 hashes may be used only for image signing or boot integrity verification.
| Keyed Hash Algorithm | Cryptographic key sizes | List of standards |
|---|---|---|
| HMAC-SHA-384 | [selection: 384 (ISO, FIPS), 256 (FIPS)] bits | [selection: ISO/IEC 9797-2:2021 (Section 7 "MAC Algorithm 2"), FIPS PUB 198-1] |
| HMAC-SHA-512 | [selection: 512 (ISO, FIPS), 384 (FIPS), 256 (FIPS)] bits | [selection: ISO/IEC 9797-2:2021 (Section 7 "MAC Algorithm 2"), FIPS PUB 198-1] |
| HMAC-SHA-256 | 256 bits | [selection: ISO/IEC 9797-2:2021 (Section 7 "MAC Algorithm 2"), FIPS PUB 198-1] |
Application Note 19
The HMAC minimum key sizes in the table are specified in ISO/IEC 9797-2:2021, which requires that the minimum key size be equal to the digest size. The FIPS standard specifies no minimum or maximum key sizes, so if FIPS PUB 198-1 is selected, larger or smaller key sizes may be used. This is indicted by the parenthesized annotations in the Cryptographic Key Sizes column. Select 'implicit' in cases where keyed-hash message authentication is done implicitly (e.g., SSH using AES in GCM mode).
| Identifier | Cryptographic algorithm | Cryptographic key sizes | List of standards |
|---|---|---|---|
| RSA-PKCS | RSASSA-PKCS1-v1_5 | Modulus of size [selection: 2048, 3072, 4096, 6144, 8192] bits and hash [selection: SHA-256, SHA-384, SHA-512] | RFC 8017 (Section 8.2) [PKCS #1 v2.2]FIPS PUB 186-5 (Section 5.4) [RSASSA-PKCS1-v1_5] |
| RSA-PSS | RSASSA-PSS | Modulus of size [selection: 2048, 3072, 4096, 6144, 8192] bits and hash [selection: SHA-256, SHA-384, SHA-512], Salt Length (sLen) such that [assignment: 0 ≤ sLen ≤ hLen (Hash Output Length)] and Mask Generation Function = MGF1 | RFC 8017 (Section 8.1) [PKCS#1 v2.2]FIPS PUB 186-5 (Section 5.4) [RSASSA-PSS] |
| ECDSA | ECDSA | Elliptic Curve [selection: P-256, P-384, P-521], per-message secret number generation [selection: extra random bits, rejection sampling, deterministic] and hash function using [selection: SHA-256, SHA-384, SHA-512] | [selection: ISO/IEC 14888-3:2018 (Subclause 6.6), FIPS PUB 186-5 (Sections 6.3.1, 6.4.1]] [ECDSA]NIST SP-800 186 (Section 4) [NIST Curves] |
| ML-DSA | ML-DSA Signature Generation | Parameter set = ML-DSA-87 | NIST FIPS 204 (Section 5.2) |
Application Note 16
The ST author should choose the cryptographic algorithms, parameters, and standards implemented to perform digital signature generation. For the algorithm chosen, the ST author should make the appropriate assignments/selections to specify the parameters that are implemented for that algorithm.
| Identifier | Cryptographic algorithm | Cryptographic key sizes | List of standards |
|---|---|---|---|
| RSA-PKCS | RSASSA-PKCS1-v1_5 | Modulus of size [selection: 2048, 3072, 4096, 6144, 8192] bits and hash [selection: SHA-256, SHA-384, SHA-512] | RFC 8017 (Section 8.2) [PKCS #1 v2.2]FIPS PUB 186-5 (Section 5.4) [RSASSA-PKCS1-v1_5] |
| RSA-PSS | RSASSA-PSS | Modulus of size [selection: 2048, 3072, 4096, 6144, 8192] bits and hash [selection: SHA-256, SHA-384, SHA-512] | RFC 8017 (Section 8.1) [PKCS#1 v2.2]FIPS PUB 186-5 (Section 5.4) [RSASSA-PSS] |
| ECDSA | ECDSA | Elliptic Curve [selection: P-256, P-384, P-521] using hash [selection: SHA-256, SHA-384, SHA-512] | [selection: ISO/IEC 14888-3:2018 (Subclause 6.6), FIPS PUB 186-5 (Section 6.4.2)] [ECDSA]NIST SP-800 186 (Section 4) [NIST Curves] |
| LMS | LMS | Private key size = [selection: ] Winternitz parameter = [selection: 1, 2, 4, 8] Tree height = [selection: 5, 10, 15, 20, 25] | RFC 8554 [LMS]NIST SP 800-208 [parameters] |
| XMSS | XMSS | Private key size = [selection: ] Tree height = [selection: 10, 16, 20] | RFC 8391 [XMSS]NIST SP 800-208 [parameters] |
| ML-DSA | ML-DSA Signature Verification | Parameter set = ML-DSA-87 | NIST FIPS 204 (Section 5.3) |
Application Note 17
The ST Author should choose the algorithm implemented to perform verification of digital signatures. For the algorithm chosen, the ST Author should make the appropriate assignments/selections to specify the parameters that are implemented for that algorithm. In particular, if ECDSA is selected as one of the signature algorithms, the key size specified must match the selection for the curve used in the algorithm.
If LMS or XMSS is selected, then FCS_COP.1/XOF from Annex B must be included.
| Identifier | DRBG Algorithm | List of Standards |
|---|---|---|
| HASH_DRBG | Hash_DRBG with [selection: SHA-256, SHA-384, SHA-512, SHA3-256, SHA3-384, SHA3-512] | [selection: ISO/IEC 18031: 2011 (Section C.2.2), NIST SP 800-90A Revision 1 Section 10.1.1] |
| HMAC_DRBG | HMAC_DRBG with [selection: SHA-256, SHA-384, SHA-512, SHA3-256, SHA3-384, SHA3-512] | [selection: ISO/IEC 18031: 2011 (Section C.2.3), NIST SP 800-90A Revision 1 Section 10.1.2] |
| CTR_DRBG | CTR_DRBG with [selection: AES-128, AES-192, AES-256] | [selection: ISO/IEC 18031: 2011 (Section C.3.2), NIST SP800-90A Revision 1 Section 10.2.1] |
Application Note 20
For the selection in this requirement, the ST author selects "TSF entropy source" if a single entropy source is used as input to the DRBG. The ST author selects "multiple TSF entropy sources" if a seed is formed from a combination of two or more entropy sources within the TOE boundary. If the TSF implements two or more separate DRBGs that are seeded in separate manners, this SFR should be iterated for each DRBG. If multiple distinct entropy sources exist such that each DRBG only uses one of them, then each iteration would select "TSF entropy source"; "multiple TSF entropy sources" is only selected if a single DRBG uses multiple entropy sources for its seed. The ST author selects "TSF interface for seeding" if entropy source data is generated outside the TOE boundary.
If "TSF entropy source" is selected in FCS_RBG.1.2, FCS_RBG.3 must be claimed from Annex B.
If "multiple TSF entropy sources" is selected in FCS_RBG.1.2, FCS_RBG.4 and FCS_RBG.5 must be claimed from Annex B.
If "TSF interface for seeding" is selected in FCS_RBG.1.2, FCS_RBG.2 must be claimed from Annex B.
Application Note 21
If a reseeding is selected in the first selection of FCS_RBG.1.2 and something other than “never” is selected in the third selection of FCS_RBG.1.3, but reseeding is not feasible, the TSF will uninstantiate RBGs, rather than produce output that is of insufficient quality. The listed standards should specify the reseed interval and procedure for uninstantiating and reseeding. The remaining selection allows the PP Author to require application-specific conditions for reseeding.
“Uninstantiate” means that the internal state of the DRBG is no longer available for use. In the second selection of FCS_RBG.1.3, “on demand” means that a TOE presents an interface to reseed as a TSFI (e.g., an API call). The interface causes the DRBG to reseed at the request of an authorised user, either with an internal source, an external source, or from input provided through the TSFI (e.g., the API call).
The list of standards selected in the last assignment should be consistent with the standards selected in FCS_RBG.1.1
The TSF shall allow the following actions prior to requiring the non-TOE entity to initiate the identification and authentication process:
Display the warning banner in accordance with FTA_TAB.1;
Application Note 22
This requirement applies to Administrators and external IT entities of services available from the TOE directly and not services available by connecting through the TOE. While it should be the case that few or no services are available to external entities prior to identification and authentication, if there are some available (perhaps ICMP echo) these should be listed in the assignment statement; if automated generation of cryptographic keys is supported without administrator authentication, the option "automated generation of cryptographic keys" should be selected; otherwise, the option “no other actions” should be selected.
Application Note 23
An authentication process consists of two basic steps: identification step (presenting the claimed attribute value (e.g., a user identifier) to the authentication subsystem); verification step (presenting or generating authentication information (e.g., a value signed with a private key) that acts as evidence to prove the binding between the attribute and that for which it is claimed).
Remote authentication is when a user associated with the Security Administrator role remotely communicates with the TOE for the purpose of security management over a cryptographic protocol specified in FTP_TRP.1/Admin. Local authentication mechanisms are defined as those that occur at a local administrative interface using a console. If no local authentication mechanism is supported by the TOE, the ST author should select "none" from the final selection. See Application Note 26 for examples of compliant local administrative interfaces.
Local administration is defined as administration using a dedicated physical interface that (from the TOE’s point of view) is directly connected to the device(s) the administrator interacts with and therefore falls under the physical protection (OE.PHYSICAL). Any administrator choice to extend a local console so it is remotely accessible (e.g., console server or remote KVM) is outside the scope of the NDcPP. The following are examples of compliant local administrative interfaces:
b. Peripherals (e.g., keyboard, monitor, mouse).
The TOE must support at least one authentication mechanism where the verification step is processed locally, as such “external authentication server” should not be the only available authentication method.
The ST author selects the authentication mechanisms necessary to support remote administration. If "Web GUI password" or "SSH password" is selected for remote authentication mechanism the ST author specifies an appropriate cryptographic protocol in FTP_TRP.1/Admin (e.g., "HTTPS" or "SSH") and includes FIA_AFL.1, FIA_PMG_EXT.1, FPT_APW_EXT.1 from Annex B.
If integration with an external X.500 Directory is supported and enabled, the "external authentication server" must be selected and an appropriate cryptographic protocol with each "authentication server" must be selected in FTP_ITC.1. Since the identity verification step is performed remotely, FIA_AFL.1, FIA_PMG_EXT.1, FPT_APW_EXT.1 requirements are not enforced by the TOE and therefore are not applicable to the “external authentication server” selection.
Application Note 24
According to the application note for FMT_SMR.2, for distributed TOEs at least one TOE component has to support the authentication of Security Administrators according to FIA_UIA_EXT.1.3 and FIA_UIA_EXT.1.4 but not necessarily all TOE components. In case not all TOE components support this way of authentication for Security Administrators the TSS must describe how Security Administrators are authenticated and identified.
The TSF shall restrict the ability to enable the functions to perform manual updates to Security Administrators.
Application Note 25
FMT_MOF.1/ManualUpdate restricts the initiation of manual updates to Security Administrators.
The TSF shall restrict the ability to manage the TSF data to Security Administrators.
Application Note 26
The word ‘manage’ includes but is not limited to create, initialize, view, change default, modify, delete, clear, and append. This SFR includes also the resetting of administrative passwords by the Security Administrator. The identifier ‘CoreData’ has been added here to separate this iteration of FMT_MTD.1 from the optional iteration of FMT_MTD.1 defined in Annex A.4.2.1 (FMT_MTD.1/CryptoKeys).
Ability to administer the TOE remotely;
Ability to configure the access banner;
Ability to configure the remote session inactivity time before session termination;
Ability to update the TOE, and to verify the updates using digital signature capability prior to installing those updates;
| # | Management Function | Status |
Application Note 27
|
FMT_SMF.1.1 Management Function |
Management Function Guidance |
|---|---|
|
Ability to administer the TOE remotely |
The TOE must provide functionality for remote administration. Local administration is optional. This cPP does not mandate a specific security management function to be available either through the local administration interface, the remote administration interface or both. Remote administrative sessions are specified in FTP_TRP.1/Admin. |
|
Ability to configure the access banner |
The TOE must provide functionality to configure the access banner for FTA_TAB.1 and the session inactivity time(s) for FTA_SSL.3 and (if included) FTA_SSL_EXT.1, though an access banner is only required for each interactive (human-computer) interface (HCI), not for any programmatic interface [application programming interface (API), e.g., REST API]. |
|
Ability to configure the remote session inactivity time before session termination |
The TOE must provide functionality to configure the access banner for FTA_TAB.1 and the session inactivity time(s) for FTA_SSL.3 and (if included) FTA_SSL_EXT.1, though an access banner is only required for each interactive (human-computer) interface (HCI), not for any programmatic interface [application programming interface (API), e.g., REST API]. |
|
Ability to update the TOE, and to verify the updates using digital signature capability prior to installing those updates |
The option “Ability to update the TOE, and to verify the updates using digital signature capability prior to installing those updates” includes the relevant management functions from FMT_MOF.1/ManualUpdate and FPT_TUD_EXT.1. Based on selections in FPT_TUD_EXT.1.2, FMT_MOF.1/AutoUpdate must be included if the option “Ability to enable or disable automatic checking for updates or automatic updates” is included in the ST. |
|
Ability to start and stop services |
The selection "Ability to start and stop services" should be included in the ST if the TOE supports starting and stopping services of the TOE. If this selection is included in the ST, FMT_MOF.1/Services must be claimed in the ST. |
|
Ability to configure local audit behaviour (e.g., changes to storage locations for audit; changes to behaviour when local audit storage space is full; changes to local audit storage size) |
The selection “Ability to configure local audit behaviour” includes the relevant management functions from FMT_MOF.1/Services and FMT_MOF.1/Functions, (for all of these SFRs that are included in the ST) and is intended to cover security relevant configuration options (if any) to the audit behaviour (like changes to the behaviour when the local audit storage space is full). The option "Ability to modify the behaviour of the transmission of audit data to an external IT entity" is intended to cover the management functionalities related to the transmission of local audit information to an external IT entity. |
|
Ability to modify the behaviour of the transmission of audit data to an external IT entity |
The option "Ability to modify the behaviour of the transmission of audit data to an external IT entity" is intended to cover the management functionalities related to the transmission of local audit information to an external IT entity. |
|
Ability to configure the list of TOE-provided services available before an entity is identified and authenticated, as specified in FIA_UIA_EXT.1 |
The selection "Ability to configure the list of TOEprovided services available before an entity is identified and authenticated, as specified in FIA_UIA_EXT.1" should be included in the ST if the TOE supports configuration of the list of TOE-provided services which are available before any entity is identified and authenticated. The term 'list' refers to the resulting list of available services as a result of the configuration activities. The configuration activity itself does not necessarily have to be modification of a list but could be any type of activation and deactivation procedure. |
|
Ability to manage the cryptographic keys |
The selection "Ability to manage the cryptographic keys" should be included in the ST if the TOE supports management of cryptographic keys (e.g., generation of cryptographic keys). If this selection is included in the ST, FMT_MTD.1/CryptoKeys must be claimed in the ST. |
|
Ability to configure the cryptographic functionality |
For distributed TOEs, that implement a registration channel (as described in FCO_CPC_EXT.1.2), the ST author uses the selection “Ability to configure the cryptographic functionality” in this SFR, and its corresponding mapping in the TSS, to describe the configuration of any cryptographic aspects of the registration channel that can be modified by the operational environment in order to improve the channel security (reference the description of the content of Preparative Procedures in [SD, 3.4.1]). |
|
Ability to configure thresholds for SSH rekeying |
The selection "Ability to configure thresholds for SSH rekeying" may only be selected if SSH is selected within FTP_ITC.1, FTP_TRP.1 or FPT_ITT.1. This only applies if the TOE claims conformance to the Functional Package for SSH and the rekey threshold is configurable. |
|
Ability to configure the lifetime for IPsec SAs |
The selection “Ability to configure lifetime for IPsec SAs” must be included in the ST if the TOE supports secure communication via IPsec and the FCS_IPSEC_EXT.1 requirements are included in the ST. The configuration of the lifetime for IPsec SAs needs to be in line with the selection in FCS_IPSEC_EXT.1.7. |
|
Ability to configure the list of supported (D)TLS ciphers |
The selection "Ability to configure the list of supported (D)TLS ciphers" must be included in the ST if the TOE implements TLS or DTLS and the supported ciphersuites are configurable. This only applies if the TOE claims conformance to the Functional Package for TLS, and only if such a configuration option exists. |
|
Ability to configure the interaction between TOE components |
For distributed TOEs, the interaction between TOE components will be configurable (see FCO_CPC_EXT.1). Therefore, the ST author includes the selection "Ability to configure the interaction between TOE components" for distributed TOEs. A simple example would be the change of communication protocol according to FPT_ITT.1. Another example would be changing the management of a TOE component from direct remote administration to remote administration through another TOE component. A more complex use case would be if the realization of an SFR is achieved through two or more TOE components and the responsibilities between the two or more components could be modified. |
|
Ability to enable or disable automatic checking for updates or automatic updates |
Based on selections in FPT_TUD_EXT.1.2, FMT_MOF.1/AutoUpdate must be included if the option “Ability to enable or disable automatic checking for updates or automatic updates” is included in the ST. |
|
Ability to re-enable an Administrator account |
If the TOE offers the ability for a remote Administrator account to be disabled in line with FIA_AFL.1, then the ST author must select the option “Ability to re-enable an Administrator account” to allow the account to be re-enabled by a local Administrator. |
|
Ability to set the time which is used for time-stamps |
The selection “Ability to set the time which is used for time-stamps” should be included in the ST if the TOE allows the Administrator to set the time of the device which is then used in time stamps. This option should not be selected if the TOE does not allow manual time setting but only relies on synchronization with external time sources like NTP servers. |
|
Ability to configure NTP |
The selection “Ability to configure NTP” should be included in the ST if the TOE uses NTP for timestamp configuration. If selected, FCS_NTP_EXT.1 must be included in the ST as well. |
|
Ability to configure the reference identifier for the peer |
The selection “Ability to configure the reference identifier for the peer” should be included in the ST if the TOE allows the Administrator to specify the expected identity of a remote peer when establishing secure communications using a protocol included in the ST. For TOEs that support only IP address and FQDN identifier types, configuration of the reference identifier may be the same as configuration of the peer’s name for the purposes of connection. |
|
Ability to manage the TOE’s trust store and designate X509.v3 certificates as trust anchors |
The selection “Ability to manage the TOE’s trust store and designate X509.v3 certificates as trust anchors" should be included in the ST if the TOE supports management and configuration of the TOE’s trust store. This means the TOE supports X.509v3 certificates for some security functions. This only applies if the TOE claims conformance to the Functional Package for X.509. |
|
Ability to generate Certificate Signing Request (CSR) and process CA certificate response |
The selection "Ability to generate Certificate Signing Request (CSR) and process CA certificate response" must be included in the ST if the TOE implements Certificate Request or Enrollment Request processes. This only applies if the TOE claims conformance to the Functional Package for X.509, and only when FIA_X509_EXT.3 from the functional package is claimed. |
|
Ability to administer the TOE locally |
The TOE must provide functionality for remote administration. Local administration is optional. This cPP does not mandate a specific security management function to be available either through the local administration interface, the remote administration interface or both. Remote administrative sessions are specified in FTP_TRP.1/Admin. |
|
Ability to configure the local session inactivity time before session termination or locking |
The TOE must provide functionality to configure the access banner for FTA_TAB.1 and the session inactivity time(s) for FTA_SSL.3 and (if included) FTA_SSL_EXT.1, though an access banner is only required for each interactive (human-computer) interface (HCI), not for any programmatic interface [application programming interface (API), e.g., REST API]. |
|
Ability to configure the authentication failure parameters for FIA_AFL.1 |
This management function enables administrators to configure parameters related to authentication failure, such as the threshold for unsuccessful login attempts and the actions the TOE takes when that threshold is reached (e.g., account lockout, notification, or timed delays). |
|
Ability to manage the trusted public keys database |
If the TOE offers ability for a remote authorised IT entities or authorised remote Administrators to connect via an interface secured with SSH, then the ST author must select the option “Ability to manage the trusted public keys database” to account for management of public key authentication. It is acceptable for this management function to be implemented as part of general TOE management functionality or as a standalone management function. |
|
Ability to manage the public key or certificate used to validate the digital update |
If the TOE offers the ability to modify the public key used to validate the digital update, then the ST author must select the option “Ability to manage the public key or certificate used to validate the digital update”. There is no requirement to implement this as a standalone management function, it is acceptable for this management function to be implemented as part of the trusted update (FPT_TUD_EXT.1) functionality. |
|
No other capabilities |
If the TOE offers the ability for the Security Administrator to configure the audit behaviour, configure the services available prior to identification or authentication, or if any of the cryptographic functionality on the TOE can be configured, or if the ST is describing a distributed TOE, then the ST author makes the appropriate choice or choices in the second selection, otherwise select the option "No other capabilities" (in the latter case the selection may alternatively be left blank in the ST). |
Table 9: FMT_SMF.1.1 Management Function Guidance
With respect to FAU_GEN.1.1, FMT_SMF.1 and FMT_MOF.1/Services the term ‘services’ refers to trusted path and trusted channel communications, on demand self-tests, trusted update and Administrator sessions (that exist under the trusted path) (e.g., netconf).
The Security Administrator role shall be able to administer the TOE remotely
Application Note 28
FMT_SMR.2.3 requires that a Security Administrator be able to administer the TOE through a remote mechanism. See Application Note 23 for the definition of remote administration.
For distributed TOEs, not every TOE component is required to implement its own user management to fulfil this SFR. At least one component has to support authentication and identification of Security Administrators according to FIA_UIA_EXT.1. For the other TOE components authentication as Security Administrator can be realized through the use of a trusted channel (either according to FTP_ITC.1 or FPT_ITT.1) from a component that supports the authentication of Security Administrators according to FIA_UIA_EXT.1. The identification of users according to FIA_UIA_EXT.1.2 and the association of users with roles according to FMT_SMR.2.2 is done through the components that support the authentication of Security Administrators according to FIA_UIA_EXT.1.4. TOE components that authenticate Security Administrators through the use of a trusted channel are not required to support local administration of the component.
A single user associated with the Security Administrator role does not necessarily have to be able to perform all security management functions defined in FMT_SMF.1 and does not necessarily have to able to perform local administration. All users associated with the Security Administrator role together need to be able to perform all security management functions defined in FMT_SMF.1 (mandatory and selected ones) and need to be able to perform remote administration.
This implies that a user that can perform only a single security management function defined in FMT_SMF.1 needs to be regarded as Security Administrator of the TOE.
The intent of this requirement is for the device to protect keys, key material, and authentication credentials from unauthorised disclosure. This data should only be accessed for the purposes of their assigned security functionality, and there is no need for them to be displayed/accessed at any other time. This requirement does not prevent the device from providing indication that these exist, are in use, or are still valid. It does, however, restrict the reading of the values outright.
Reliable time stamps are expected to be used with other TSF, e.g., for the generation of audit data that enables the Security Administrator to investigate incidents by checking the order of events and determining the actual local time when events occurred. The required level of accuracy is determined by the Administrator.
The TOE depends on time and date information that may be provided by a local real-time clock managed by the Security Administrator, obtained from one or more NTP servers, or received from the underlying virtualization system. The corresponding option(s) are selected in FPT_STM_EXT.1.2. Automatic synchronization with an NTP server is recommended but not required. When the TOE communicates with an NTP server, the inclusion of FCS_NTP_EXT.1 in the ST is expected. The ST author describes in the TSS how the TOE receives external time and date information and how this information is maintained. For a Case 1 vND, the virtualization system can act as an external time source. For a Case 2 vND, the virtualization system is part of the TOE, so the time is typically set by a Security Administrator or synchronized with an NTP server.
The term “reliable time stamps” refers to the strict use of the provided time and date information and to the logging of all discontinuous changes to the time settings, including information about the old and new time values. With this information, the real time for all audit data can be determined. All discontinuous time changes, whether initiated by an Administrator or an automated process, are expected to be audited. No audit is needed when time is changed through kernel or system facilities—such as daytime (3)—that do not introduce discontinuities.
For distributed TOEs, the Security Administrator is expected to maintain synchronization between the time settings of different TOE components. All components should either remain synchronized (for example, by internal synchronization or by using a common NTP source) or have a known and documented offset for each component pair, including those synchronized to different time zones.
During initial start-up (on power on) to verify the integrity of the TOE firmware and software;
Prior to providing any cryptographic service and
Application Note 31
For the third bullet point, the following restriction applies: If, and only if 'no other' is selected in the selection, 'none' may be used in the second assignment.
Non-distributed TOEs may internally consist of several components that contribute to enforcing SFRs. Self-testing should cover all components that contribute to enforcing SFRs and verification of integrity should cover all software that contributes to enforcing SFRs on all components.
For distributed TOEs, all TOE components have to perform self-tests. This does not necessarily mean that each TOE component has to carry out the same self-tests.
Application Note 32
For failed self-tests related to enforcing SFRs as defined in FPT_TST_EXT.1.1, the reaction of the TOE to each failure is described in the ST. FPT_TST_EXT.1.2 supports two modeling approaches. In the first, the TOE reacts in the same way to all self-test failures that enforce SFRs by selecting “all failures” in the first selection and identifying the corresponding reaction in the second selection. In the second approach, the TOE may define different reactions for specific self-test failures by listing the failures in the first selection and the associated reactions in the second. In this latter case, the ST should clearly identify which self-test failure corresponds to each defined TOE behaviour.
The TSF shall provide Security Administrators the ability to query the currently executing version of the TOE firmware/software and
[selection: the most recently installed version of the TOE firmware/software, no other TOE firmware/software version].Application Note 33
If a trusted update can be installed on the TOE with a delayed activation the version of both the currently executing image and the installed but inactive image must be provided. In this case the option “the most recently installed version of the TOE firmware/software” must be chosen from the selection in FPT_TUD_EXT.1.1. If all trusted updates become active as part of the installation process, only the currently executing version needs to be provided. In this case the option “no other TOE firmware/software version” should be chosen from the selection in FPT_TUD_EXT.1.1.
For a distributed TOE, the method of determining the installed versions on each component of the TOE is described in the operational guidance.
The TSF shall provide Security Administrators the ability to manually initiate updates to TOE firmware/software and
[selection: support automatic checking for updates, support automatic updates, no other update mechanism].Application Note 34
The selection in FPT_TUD_EXT.1.2 distinguishes the support of automatic checking for updates and support of automatic updates. The first option refers to a TOE that checks whether a new update is available, communicates this to the Administrator (e.g., through a message during an administrative session, through log files) but requires some action by the Administrator to actually perform the update. The second option refers to a TOE that checks for updates and automatically installs them upon availability. If the TOE checks and automatically installs the update, then FMT_MOF.1/AutoUpdate should be included.
The TSF shall provide means to authenticate firmware/software updates to the TOE using a
[selection: X.509 certificate, digital signature] prior to installing those udpates.Application Note 35
The ST author selects “X.509 certificate” when the TOE uses X.509 certificates in a manner compliant with the certificate validation requirements in the Functional Package for X.509. The digital signature algorithm must be one of the algorithms specified in FCS_COP.1/SigVer.
The ST author selects ‘digital signature’ for all other digital mechanisms (e.g., X.509 certificates that do not meet the certificate validation requirements in the Functional Package for X.509, GPG, raw public key). The digital algorithm must be one of the algorithms specified in FCS_COP.1/SigVer.
The TOE itself must perform the verification of the update signature, regardless of whether the update is authenticated using an X.509 certificate or another digital signature mechanism.
For distributed TOEs, all TOE components must support Trusted Update. The verification of the signature on the update should be done by each TOE component itself (signature verification).
Updating a distributed TOE might lead to the situation where different TOE components are running different software versions. Depending on the differences between the different software versions the impact of a mixture of different software versions might be no problem at all or critical to the proper functioning of the TOE. The TSS must detail the mechanisms that support the continuous proper functioning of the TOE during trusted update of distributed TOEs.
If “X.509 certificate” is selected, certificates are validated in accordance with the Functional Package for X.509. Additionally, FPT_TUD_EXT.2 must be included in the ST.
‘Update’ in the context of this SFR refers to the process of replacing a non-volatile (NV), system resident software component with another. The former is referred to as the NV image, and the latter is the update image. While the update image is typically newer than the NV image, this is not a requirement. There are legitimate cases where the system owner may want to rollback a component to an older version (e.g., when the component manufacturer releases a faulty update, or when the system relies on an undocumented feature no longer present in the update). Likewise, the owner may want to update with the same version as the NV image to recover from faulty storage.
All discrete firmware and software elements (e.g., applications, drivers, and kernel) of the TSF need to be protected, (i.e., they should be digitally signed by the corresponding manufacturer and subsequently verified by the mechanism performing the update).
The TSF shall terminate a remote interactive session after a Security Administrator-configurable time interval of session inactivity.
Application Note 36
An interactive session governed by this SFR is a session in which an authenticated state is achieved and then preserved across multiple commands. By contrast, if authentication accompanies each individual command (without preservation of the same authenticated state) then this is not considered an interactive session.
Before establishing an Administrative user session the TSF shall display a Security Administrator-specified advisory notice and consent warning regarding use of the TOE message.
Application Note 37
This requirement is intended to apply to interactive sessions between a human administrator and a TOE. IT entities establishing connections or programmatic connections (e.g., remote procedure calls over a network) are not required to be covered by this requirement.
The TSF shall be capable of using
[selection: IPsec, SSH as defined in the Functional Package for SSH, TLS as defined in the Functional Package for TLS, DTLS as defined in the Functional Package for TLS, HTTPS]to provide a trusted communication channel between itself and another trusted IT product authorised IT entities supporting the following capabilities: audit 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 and detection of modification of the channel data.
Application Note 38
The intent of the above requirement is to provide a means by which a cryptographic protocol may be used to protect external communications with authorised IT entities that the TOE interacts with to perform its functions. The TOE uses at least one of the listed protocols for communications with the server that collects the audit information. If it communicates with an authentication server (e.g., RADIUS), then the ST author chooses “authentication server” in FTP_ITC.1.1 and this connection must be capable of being protected by one of the listed protocols. If other authorised IT entities are protected, the ST author makes the appropriate assignments (for those entities) and selections (for the protocols that are used to protect those connections). The ST author selects the mechanism or mechanisms supported by the TOE, and then ensures that the detailed protocol requirements in Annex B corresponding to their selection are included in the ST.
While there are no requirements on the party initiating the communication, the ST author lists in the assignment for FTP_ITC.1.3 the services for which the TOE can initiate the communication with the authorised IT entity.
The requirement implies that not only are communications protected when they are initially established, but also on resumption after an outage. It may be the case that some part of the TOE setup involves manually setting up tunnels to protect other communication, and if after an outage the TOE attempts to re-establish the communication automatically with (the necessary) manual intervention, there may be a window created where an attacker might be able to gain critical information or compromise a connection.
Where X.509 certificates are used to authenticate remote endpoints in support of an FTP_ITC.1 channel, relevant SFR claims from the Functional Package for X.509 must be used. This requires support for attributes such as certificate revocation status and intermediate CAs.
If the TOE claims FCS_TLSS_EXT.2 (TLS Server Support for Mutual Authentication) from the Functional Package for TLS and the TOE passes presented identifiers of clients used for client authentication to a directory server for comparison, then the connection to the directory server used to verify presented identifiers of TLS clients needs to be protected by a trusted channel (i.e., FTP_ITC.1). If a trusted channel is used for the integrity protection for communication between the TOE and a directory server, then the directory server must be added to the assignment for other capabilities in FTP_ITC.1. Note: The directory server is only expected to handle the comparison of the presented identifier but not to perform full X.509 certificate validation on behalf of the TOE.
See Section B.4.1 for additional requirements.
If "TLS" or "DTLS" is selected, then the TSF is validated against the applicable requirements of the Functional Package for TLS.
If "SSH" is selected, then the TSF is validated against the applicable requirements of the Functional Package for SSH.
The TSF shall be capable of using
[selection: IPsec, SSH as defined in the Functional Package for SSH, TLS as defined in the Functional Package for TLS, DTLS as defined in the Functional Package for TSL, HTTPS]to provide a communication path between itself and authorised remote Administrators users that is logically distinct from other communication paths and provides assured identification of its endpoints and protection of the communicated data from disclosure and provides detection of modification of the channel data.
The TSF shall require the use of the trusted path for initial Administrator authentication and all remote administration actions.
Application Note 39
This requirement ensures that authorised remote Administrators initiate all communication with the TOE via a human-interactive trusted path, and that all communication with the TOE by remote Administrators is performed over this path. The data passed in this trusted communication channel is encrypted as defined by the protocol chosen in the first selection. The ST author selects the mechanism or mechanisms supported by the TOE, and then ensures that the detailed protocol requirements in Annex B corresponding to their selection, or the protocol requirements of the packages specified in Section 2.1 are included in the ST. Where X.509 certificates are used to authenticate authorised Administrators, FIA_X509_EXT.1 in the Functional Package for X.509 is to be used (which requires checking certificate revocation, implementing a trust store, and supporting a certificate chain).
See Section B.4.1 for additional requirements.
If "TLS" or "DTLS" is selected, then the TSF is validated against the applicable requirements of the Functional Package for TLS.
If "SSH" is selected, then the TSF is evaluated against the applicable requirements of the Functional Package for SSH.
The following rationale provides justification for each SFR for the TOE,
showing that the SFRs are suitable to address the specified threats:
| Threat | Addressed by | Rationale |
|---|---|---|
| T.SECURITY_FUNCTIONALITY_COMPROMISE | FCS_CKM.6 | |
| FIA_PMG_EXT.1 (Implementation-based) | ||
| FIA_UAU.7 (Implementation-based) | ||
| FMT_MTD.1/CryptoKeys (Implementation-based) | ||
| FMT_SMF.1 | ||
| FPT_APW_EXT.1 (Implementation-based) | ||
| FPT_SKP_EXT.1 | ||
| T.SECURITY_FUNCTIONALITY_FAILURE | FPT_TST_EXT.1 | |
| T.UNAUTHORISED_ADMINISTRATOR_ACCESS | FIA_AFL.1 (Implementation-based) | If the TOE provides remote administration using a password-based authentication mechanism, FIA_AFL.1 provides actions on reaching a threshold number of consecutive password failures |
| FIA_UIA_EXT.1 | ||
| FMT_MOF.1/Functions (Selection-based) | optional additional administration capabilities are offered in FMT_MOF.1/Functions | |
| FMT_MOF.1/Services (Selection-based) | optional additional administration capabilities are offered in FMT_MOF.1/Servicesoptional additional administration capabilities in FMT_MOF.1/Services and FMT_MOF.1/Functions | |
| FMT_MTD.1/CoreData | The relevant administration capabilities are defined in FMT_MTD.1/CoreData | |
| FMT_SMF.1 | The relevant administration capabilities are defined in FMT_SMF.1 The relevant administration capabilities are defined in FMT_SMF.1 The relevant administration capabilities are defined in FMT_SMF.1 | |
| FMT_SMR.2 | The Administrator role is defined in FMT_SMR.2 | |
| FTA_SSL_EXT.1 (Implementation-based) | ||
| FTA_SSL.3 | ||
| FTA_SSL.4 | ||
| FTA_TAB.1 | ||
| FTP_TRP.1/Admin | The secure channel used for remote Administrator connections is specified in FTP_TRP.1/AdminThe secure channel used for remote Administrator connections is specified in FTP_TRP.1/Admin | |
| T.UNDETECTED_ACTIVITY | FAU_GEN.1 | |
| FAU_GEN.2 | ||
| FAU_SAR.1 (Selection-based) | ||
| FAU_STG_EXT.1 | ||
| FAU_STG_EXT.4 (Selection-based) | ||
| FAU_STG.2 (Optional) | ||
| FCS_NTP_EXT.1 (Selection-based) | ||
| FMT_MOF.1/Functions (Selection-based) | ||
| FMT_SMF.1 | ||
| FPT_STM_EXT.1 | ||
| T.UNTRUSTED_COMMUNICATIONS_CHANNELS | FCS_IPSEC_EXT.1 (Selection-based) | |
| FPT_ITT.1 (Optional) | ||
| FTP_ITC.1 | ||
| FTP_TRP.1/Admin | ||
| T.UPDATE_COMPROMISE | FMT_MOF.1/AutoUpdate (Selection-based) | |
| FMT_MOF.1/ManualUpdate | ||
| FMT_SMF.1 | ||
| FPT_TUD_EXT.1 | ||
| FPT_TUD_EXT.2 (Selection-based) | ||
| T.WEAK_AUTHENTICATION_ENDPOINTS | FCO_CPC_EXT.1 (Optional) | |
| FPT_ITT.1 (Optional) | ||
| FTP_ITC.1 | ||
| FTP_TRP.1/Admin | ||
| FTP_TRP.1/Join (Optional) | ||
| T.WEAK_CRYPTOGRAPHY | FCS_CKM_EXT.7 | |
| FCS_CKM.1/AKG | ||
| FCS_COP.1/CMAC (Selection-based) | ||
| FCS_COP.1/DataEncryption | ||
| FCS_COP.1/Hash | ||
| FCS_COP.1/KeyedHash | ||
| FCS_COP.1/SigGen | ||
| FCS_COP.1/SigVer | ||
| FCS_RBG.1 | ||
| FMT_SMF.1 |
Application Note 41
This option should be chosen if the TOE supports this functionality.
In case the local storage for audit records is cleared by the Administrator, the counters associated with the selection in the SFR should be reset to their initial value (most likely to 0). The guidance documentation should contain a warning for the Administrator about the loss of audit data when he clears the local storage for audit records.
For distributed TOEs, each component that implements counting of lost audit data has to provide a mechanism for Administrator access to, and management of, this information.
If FAU_STG_EXT.2 is added to the ST, the ST has to make clear any situations in which lost audit data is not counted.
Application Note 42
This option should be chosen if the TOE generates a warning to inform the Administrator before the local storage space for audit data is used up. This SFR only applies to local storage of audit information.
It has to be ensured that the warning message required by FAU_STG_EXT.3.1 can be communicated to the Administrator. The communication should be done via the audit log itself because it cannot be guaranteed that an administrative session is active at the time the event occurs.
The warning should inform the Administrator when the local space to store audit data is used up and/or the TOE will lose audit data due to insufficient local space.
For distributed TOEs, that implement displaying a warning when local storage space for audit data is exhausted, it has to be described which TOE components support this feature (not necessarily all TOE components have to support this feature if selected for the overall TOE). Each component that supports this feature must either generate a warning itself or through another component.
If FAU_STG_EXT.3 is added to the ST, the ST has to make clear any situations in which audit records might be “invisibly lost”.
Application Note 46
This SFR is only applicable if the TOE is distributed and therefore has multiple components that need to communicate via an internal TSF channel. When creating the TSF from the initial pair of components, either of these components may be identified as the TSF for the purposes of satisfying the meaning of ‘TSF’ in this SFR.
The intention of this requirement is to ensure that there is a registration process that includes a positive enablement step by an Administrator before components joining a distributed TOE can communicate with the other components of the TOE and before the new component can act as part of the TSF. The registration process may itself involve communication with the joining component: many Network Devices use a bespoke process for this, and the security requirements for the ‘registration communication’ are then defined in FCO_CPC_EXT.1.2. Use of this ‘registration communication’ channel is not deemed inconsistent with the requirement of FCO_CPC_EXT.1.1 (i.e., the registration channel can be used before the enablement step, but only in order to complete the registration process).
The channel selection (for the registration channel) in FCO_CPC_EXT.1.2 is essentially a choice between the use of a normal secure channel that is equivalent to a channel used to communicate with external IT entities (FTP_ITC.1) or existing TOE components (FPT_ITT.1), or else a separate type of channel that is specific to registration (FTP_TRP.1/Join). If the TOE does not require a communications channel for registration (e.g., because the registration is achieved entirely by configuration actions by an Administrator at each of the components) then the main selection in FCO_CPC_EXT.1.2 is completed with the ‘No channel’ option.
If the ST author selects the FTP_ITC.1/FPT_ITT.1 channel type in the main selection in FCO_CPC_EXT.1.2 then the TSS identifies the relevant SFR iteration that specifies the channel used. If the ST author selects the FTP_TRP.1/Join channel type, then the TOE Summary Specification (possibly with support from the operational guidance) describes details of the channel and the mechanisms that it uses (and describes how the registration process ensures that the channel can only be used by the intended joiner and gatekeeper). Note: The FTP_TRP.1/Join channel type may require support from security measures in the operational environment (see the definition of FTP_TRP.1/Join for details).
If the ST author selects the FTP_ITC.1/FPT_ITT.1 channel type in the main selection in FCO_CPC_EXT.1.2 then the ST identifies the registration channel as a separate iteration of FTP_ITC.1 or FPT_ITT.1 and gives the iteration identifier (e.g., “FPT_ITT.1/Join”) in an ST Application Note for FCO_CPC_EXT.1.
Note: The channel set up and used for registration may be adopted as a continuing internal communication channel (i.e., between different TOE components) provided that the channel meets the requirements of FTP_ITC.1 or FPT_ITT.1. Otherwise, the registration channel is closed after use, and a separate channel is used for the internal communications.
Specific requirements for Preparative Procedures relating to FCO_CPC_EXT.1 are defined in the Evaluation Activities in [SD].
The TSF shall perform cryptographic key establishment in accordance with a specified cryptographic key establishment method:
[selection: key encapsulation, key wrapping, encrypted channels] that meets the following: none.Application Note 43
This requirement specifies key transport schemes. For key agreement see FCS_CKM_EXT.7. Key transport schemes refer to cases in which one party has a key to share with another party. Key encapsulation is used when ML-KEM is used as the method of key establishment. Key wrapping and encrypted channels are used in support of wireless LAN communications. Key wrapping is also used in support of MACsec.
If “key encapsulation” is selected, FCS_COP.1/KeyEncap from Annex B must be claimed, which specifies the relevant list of standards.
If “key wrapping” is selected, FCS_COP.1/KeyWrap from Annex B must be claimed, which specifies the relevant list of standards.
The TSF shall protect TSF data from disclosure and detect its modification when it is transmitted between separate parts of the TOE through the use of
[selection: IPsec, SSH as defined in the Functional Package for SSH, TLS as defined in the Functional Package for TLS, DTLS as defined in the Functional Package for TLS, HTTPS].Application Note 44
This requirement is only applicable to distributed TOEs and ensures that all communications between components of the distributed TOE are protected through the use of an encrypted communications channel. The data passed in this trusted communication channel are encrypted as defined by the protocol chosen in the selection. The ST author should identify the channels and protocols used by each pair of communicating components in a distributed TOE, iterating this SFR as appropriate.
This channel may also be used as the registration channel for the registration process, as described in Section 3.3 and FCO_CPC_EXT.1.2.
If "TLS" or "DTLS" is selected, then the TSF is validated against the applicable requirements of the Functional Package for TLS. Additionally, the reference identifier established for the server (FCS_DTLSC_EXT.1.5 or FCS_TLSC_EXT.1.5 in the Functional Package for TLS) may be established through a “gatekeeper” discovery process. The TSS should describe the discovery process and highlight how the reference identifier is supplied to the “joining” component.
If "SSH" is selected, then the TSF is validated against the applicable requirements of the Functional Package for SSH.
See Section B.4.1 for additional requirements.
The TSF shall provide a communication path between itself and a joining component [selection: remote, local] users that is logically distinct from other communication paths and provides assured identification of
its endpoints and protection of the communicated data from modification and
The TSF shall require the use of the trusted path for joining components to the TSF under environmental constraints identified in
[assignment: reference to operational guidance].Application Note 45
This SFR implements one of the types of channel identified in the main selection for FCO_CPC_EXT.1.2. The “joining component” in FTP_TRP.1/Join is the IT entity that is attempting to join the distributed TOE by using the registration process.
The effect of this SFR is to require the ability for components to communicate in a secure manner while the distributed TSF is being created (or when adding components to an existing distributed TSF). When creating the TSF from the initial pair of components, either of these components may be identified as the TSF for the purposes of satisfying the meaning of ‘TSF’ in this SFR.
The selection at the end of FTP_TRP.1.1/Join recognises that in some cases confidentiality (i.e., protection of the data from disclosure) may not be provided by the channel. The ST author distinguishes in the TSS whether in this case the TOE relies on the environment to provide confidentiality (as part of the constraints referenced in FTP_TRP.1.3/Join) or whether the registration data exchanged does not require confidentiality (in which case this assertion must be justified). If ‘no other mechanisms’ is selected, the ST author may omit this phrase in the completed SFR text to improve readability.
The assignment in FTP_TRP.1.3/Join ensures that the ST highlights any specific details needed to protect the registration environment.
Note: When the ST uses FTP_TRP.1/Join for the registration channel then this channel cannot be reused as the normal inter-component communication channel (the latter channel must meet FTP_ITC.1 or FPT_ITT.1).
The trusted path used for joining might utilise X.509 certificates; however, there are no required X.509 SFRs associated with this trusted path as there are many ways the security of the joining path could be provided. It is up to the ST author to describe how the security of this trusted path is implemented; whether the security relies on X.509 SFRs, environmental constraints from FTP_TRP.1.3/Join, and/or some other method.
See Section B.4.1 for additional requirements.
Specific requirements for Preparative Procedures relating to FTP_TRP.1/Join are defined in the Evaluation Activities in [SD].
This PP does not define any Objective requirements.
When the defined number of unsuccessful authentication attempts has been met, the TSF shall
[selection: prevent the offending Administrator from successfully establishing a remote session using any authentication method that involves a password until [assignment: action to unlock] is taken by an Administrator, prevent the offending Administrator from successfully establishing a remote session using any authentication method that involves a password until an Administrator defined time period has elapsed].Application Note 74
This requirement applies to a defined number of successive unsuccessful remote password-based authentication attempts and does not apply to local Administrative access, since it does not make sense to lock a local Administrator’s account in this fashion. Compliant TOEs may optionally include cryptographic authentication failures and/or local authentication failures in the number of unsuccessful authentication attempts. This could be addressed by (for example) requiring a separate account for local Administrators or having the authentication mechanism implementation distinguish local and remote login attempts. The ‘action’ taken by a local Administrator is implementation specific and would be defined in the Administrator guidance (for example, lockout reset, or password reset). The ST author chooses one or both of the selections for handling of authentication failures depending on how the TOE has implemented this handler.
The TSS describes how the TOE ensures that authentication failures by remote Administrators cannot lead to a situation where no Administrator access is available, either permanently or temporarily (e.g., by providing local logon, which is not subject to blocking, or by allowing a reboot to clear the lockout status and restore administrator access). The Operational Guidance describes, and identifies the importance of, any actions that are required in order to ensure that Administrator access will always be maintained, even if remote administration is made permanently or temporarily unavailable due to blocking of accounts as a result of FIA_AFL.1.
Passwords shall be able to be composed of any combination of upper and lower case letters, numbers and the following special characters:
Minimum password length shall be configurable to between
characters.
Application Note 76
The ST author selects the special characters that are supported by the TOE. They may optionally list additional special characters supported using the assignment. "Administrative passwords" refers to passwords used by Administrators at the local console, over protocols that support passwords, such as SSH and HTTPS, or to grant configuration data that supports other SFRs in the Security Target.
The second assignment should be configured with the largest minimum password length the Security Administrator can configure.
The TSF shall provide only obscured feedback to the administrative user while the authentication is in progress at the local console.
Application Note 75
‘Obscured feedback’ implies the TSF does not produce a visible display of any authentication data entered by an administrator (such as the echoing of a password), although an obscured indication of progress may be provided (such as an asterisk for each character). It also implies that the TSF does not return any information during the authentication process to the administrator that may provide any indication of the authentication data.
The TSF shall restrict the ability to manage the cryptographic keys to Security Administrators.
Application Note 83
FMT_MTD.1.1/CryptoKeys restricts management of cryptographic keys to Security Administrators. It should be included if cryptographic keys can be managed (e.g., modified, deleted or generated/imported) by the Security Administrator. The identifier ‘CryptoKeys’ has been added here to separate this iteration of FMT_MTD.1 from the mandatory iteration of FMT_MTD.1 defined in Section 6.6.2.1 (FMT_MTD.1/CoreData).
Application Note 78
The intent of the requirement is that raw password authentication data of Security Administrators is not stored in the clear, and that no Administrator is able to read the plaintext password of a Security Administrator through “normal” interfaces. An all-powerful Administrator could directly read memory to capture a password but is trusted not to do so. Passwords should be obscured during entry on the local console in accordance with FIA_UAU.7.
Although this is out-of-scope of this cPP, it is strongly advised to protect all authentication data of the device the same way and/or with similar strength as administrative passwords to reduce the risk of attacks like privilege escalation, etc.
Application Note 84
An interactive session governed by this SFR is a session in which an authenticated state is achieved and then preserved across multiple commands. By contrast, if authentication accompanies each individual command (without preservation of the same authenticated state) then this is not considered an interactive session.
As indicated in the introduction to this PP, the baseline requirements (those that must be performed by the TOE or its underlying platform) are contained in the body of this PP. There are additional requirements based on selections in the body of the PP: if certain selections are made, then additional requirements below must be included.
The TSF shall be able to generate audit records for each TOE component. The audit records generated by the TSF of each TOE component shall include the subset of security relevant audit events which can occur on the TOE component.
Application Note 48
The TOE must be able to generate audit records for each TOE component. Some TOE components of a distributed TOE might not implement the complete TSF of the overall TOE but only a subset of the TSF. The audit records for each TOE component need to cover all security relevant audit events according to the subset of the TSF implemented by this particular TOE component but not necessarily all security relevant audit events according to the TSF of the overall TOE. If a security-relevant event can occur on multiple TOE components, it needs to cause generation of an audit record uniquely identifying the component associated with the event. The ST author should identify for each TOE component which of the overall required audit events defined in FAU_GEN.1.1 are logged. The ST author may decide to do this by providing a corresponding table. The information provided needs to be in agreement with Table 1. The overall TOE needs to cover all auditable events listed in Table 2 (and Table 10, Table 11, the claimed PP-Module(s), and the claimed functional package(s) as applicable to the overall TOE).
The TSF shall provide the Security Administrator with the capability to read all audited events and record contents from the audit data
Application Note 49
If a component of a distributed TOE collects data from other components and then forwards it to another component or external IT entity (reference FAU_STG_EXT.1.1) then the operations in this SFR must be performed in a way to cover the storage space action(s) for all of the audit data that the TOE collects (i.e., not just for the data generated by the collecting component for itself).
It is acceptable for a TOE component to store audit information in multiple places (e.g., for redundancy), whether locally in the TOE component itself and in another TOE component, or in more than one other TOE component.
TOE components are not required to monitor or audit connectivity or network outages between TOE components. This aspect is covered by the assumption A.COMPONENTS_RUNNING
Application Note 50
If a component of a distributed TOE collects data from other components and then forwards it to another component or external IT entity (cf. FAU_STG_EXT.1.1) then the operations in this SFR must be performed in a way to cover the storage space action(s) for all of the audit data that the TOE collects (i.e. not just for the data generated by the collecting component for itself).
It is acceptable for a TOE component to store audit information in multiple places (e.g., for redundancy), whether locally in the TOE component itself and in another TOE component, or in more than one other TOE component.
TOE components are not required to monitor or audit connectivity or network outages between TOE components. This aspect is covered by the assumption A.COMPONENTS_RUNNING.
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 allowed choices for completion of the selection operations of FCS_COP.1/AEAD.| Identifier | Cryptographic algorithm | Cryptographic key sizes | List of standards |
|---|---|---|---|
| AES-CCM | AES in CCM mode with unpredictable, non-repeating nonce, minimum size of 64 bits | [selection: 128, 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] |
| 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. | [selection: 128, 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] |
The TSF shall perform CMAC in accordance with a specified cryptographic algorithm AES using CMAC mode and cryptographic key sizes 128 bits that meet the following:
[selection: ISO/IEC 9797-1:2011 subclause 7.6 (CMAC) and ISO/IEC 18033-3:2010 subclause 5.2 (AES), NIST SP 800-38B (CMAC) and NIST FIPS 197 (AES)].The TSF shall perform key encapsulation 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 allowed choices for completion of the selection operations of FCS_COP.1/KeyEncap.| Identifier | Cryptographic Algorithm | Cryptographic Key Sizes | List of Standards |
|---|---|---|---|
| ML-KEM | ML-KEM | Parameter set = ML-KEM-1024 | NIST FIPS 203 |
Application Note 52
The only anticipated use of key encapsulation is the use of ML-KEM as part of key establishment for trusted communication.
The TSF shall perform key wrapping 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 allowed choices for completion of the selection operations of FCS_COP.1/KeyWrap.| Identifier | Cryptographic Algorithm | Cryptographic Key Sizes | List of Standards |
|---|---|---|---|
| AES-KW | AES in KW mode | 256 bits | [selection: ISO/IEC 18033-3:2010 (Subclause 5.2), FIPS PUB 197] [AES] [selection: ISO/IEC 19772:2020 (clause 6), NIST SP 800-38F (Section 6.2)] [KW mode] |
| AES-KWP | AES in KWP mode | 256 bits | [selection: ISO/IEC 18033-3:2010 (Subclause 5.2), FIPS PUB 197] [AES]NIST SP 800-38F (Section 6.3) [KWP mode] |
| 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] |
| 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] |
The TSF shall perform symmetric-key encryption/decryption 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 allowed choices for completion of the selection operations of FCS_COP.1/SKC.| Identifier | Cryptographic Algorithm | Cryptographic Key Sizes | List of Standards |
|---|---|---|---|
| AES-CBC | AES in CBC mode with non-repeating and unpredictable IVs | [selection: 128, 256] | [selection: ISO/IEC 18033-3:2010 (Subclause 5.2), FIPS PUB 197] [AES] [selection: ISO/IEC 10116:2017 (Clause 7), NIST SP 800-38A] [CBC] |
| XTS-AES | AES in XTS mode with unique tweak values that are consecutive non-negative integers starting at an arbitrary non-negative integer | [selection: 256, 512] | [selection: ISO/IEC 18033-3:2010 (Subclause 5.2), FIPS PUB 197] [AES] [selection: IEEE Std. 1619-2018, NIST SP 800-38E] [XTS] |
| AES-CTR | AES in Counter Mode with a non-repeating initial counter and with no repeated use of counter values across multiple messages with the same secret key | [selection: 128, 256] | [selection: ISO/IEC 18033-3:2010 (Subclause 5.2), FIPS PUB 197] [AES] [selection: : ISO/IEC 10116:2017 (Clause 10), NIST SP 800-38A] [CTR] |
The TSF shall perform extendable-output function in accordance with a specified cryptographic algorithm
[selection: Cryptographic Algorithm] and [selection: Parameters] that meet the following: [selection: List of Standards] . The following table provides the allowed choices for completion of the selection operations of FCS_COP.1.1/XOF.| Cryptographic Algorithm | Parameters | List of Standards |
|---|---|---|
| SHAKE | Functions = [SHAKE128, SHAKE256] | NIST FIPS PUB 202 (Section 6.2) |
Since LMS and XMSS use both SHAKE128 and SHAKE256 internally, claiming and testing of both Functions is mandatory
Application Note 60
RFC 4301 calls for an IPsec implementation to protect IP traffic through the use of a Security Policy Database (SPD). The SPD is used to define how IP packets are to be handled: PROTECT the packet (e.g., encrypt the packet), BYPASS the IPsec services (e.g., no encryption), or DISCARD the packet (e.g., drop the packet). The SPD can be implemented in various ways, including router access control lists, firewall rulesets, a ‘traditional’ SPD, etc. Regardless of the implementation details, there is a notion of a ‘rule’ that a packet is ‘matched’ against and a resulting action that takes place.
While there must be a means to order the rules, a general approach to ordering is not mandated, as long as the SPD can distinguish the IP packets and apply the rules accordingly. There may be multiple SPDs (one for each network interface), but this is not required.
Application Note 62
When an AES-CBC algorithm is selected, at least one SHA-based HMAC must also be chosen. If only an AES-GCM algorithm is selected, then a SHA-based HMAC is not required since AES-GCM satisfies both confidentiality and integrity functions. IPsec may utilise a truncated version of the SHA-based HMAC functions contained in the selections. Where a truncated output is utilised, it should be highlighted in the TSS.
Application Note 65
The ST author chooses either the IKEv1 requirements or IKEv2 requirements (or both, depending on the selection in FCS_IPSEC_EXT.1.5). The ST author chooses either volume-based lifetimes or time-based lifetimes (or a combination). The range between the minimum and maximum rekeys time must include a rekey time that causes a rekey to occur at or slightly before 24 hours. The exact values supported may vary by TOE implementation. Some TOEs might require the administrators to ensure rekeying prior to the desired time (e.g., configure a time value of 23h 59min to ensure the actual rekey is performed no later than 24h), while other TOEs might automatically ensure rekeying is performed prior to the configured time.
This requirement must be accomplished by providing Security Administrator-configurable lifetimes. Hardcoded limits do not meet this requirement.
Application Note 66
The ST author chooses either the IKEv1 requirements or IKEv2 requirements (or both, depending on the selection in FCS_IPSEC_EXT.1.5). The ST author chooses either volume-based lifetimes or time-based lifetimes (or a combination). The range between the minimum and maximum rekeys time must include a rekey time that causes a rekey to occur at or slightly before 8 hours. The exact values supported may vary by TOE implementation. Some TOEs might require the administrators to ensure rekeying prior to the desired time (e.g., configure a time value of 7h 59min to ensure the actual rekey is performed no later than 8h), while other TOEs might automatically ensure rekeying is performed prior to the configured time.
This requirement must be accomplished by providing Security Administrator-configurable lifetimes. Hardcoded limits do not meet this requirement.
Application Note 67
For DH groups 19 and 20, the ‘x’ value is the point multiplier for the generator point G.
Since the implementation may allow different Diffie-Hellman groups to be negotiated for use in forming the SAs, the assignment in FCS_IPSEC_EXT.1.9 may contain multiple values. For each DH group supported, the ST author consults Table 2 in NIST SP 800-57 “Recommendation for Key Management –Part 1: General” to determine the security strength (‘bits of security’) associated with the DH group. Each unique value is then used to fill in the assignment for this element. For example, suppose the implementation supports DH group 14 (2048-bit MODP) and group 20 (ECDH using NIST curve P-384). From Table 2, the bits of security value for group 14 is 112, and for group 20 is 192.
Application Note 68
This SFR is for the IKEv1 (phase 1 and phase 2) and IKEv2 (IKE_AUTH and CREATE_CHILD_SA) protocol exchanges.
The ST author must select the second option for nonce lengths if IKEv2 is selected (as this is mandated in RFC 7296). The ST author may select either option for IKEv1.
The security strengths of DH groups are defined in NIST SP 800-57.
Because nonces may be exchanged before the DH group is negotiated, the nonce used should be large enough to support all TOE-chosen proposals in the exchange.
Application Note 70
The ST author chooses either or both of the IKE selections based on what is implemented by the TOE. Obviously, the IKE version(s) chosen should be consistent not only in this element, but with other choices for other elements in this component. While it is acceptable for this capability to be configurable, the default configuration in the evaluated configuration (either ‘out of the box’ or by configuration guidance in the AGD documentation) must enable this functionality.
Application Note 71
At least one public-key-based Peer Authentication method is required in order to conform to this cPP; one or more of the public key schemes is chosen by the ST author to reflect what is implemented. The ST author also ensures that appropriate FCS requirements reflecting the algorithms used (and key generation capabilities, if provided) are listed to support those methods. Note: The TSS will elaborate on the way in which these algorithms are to be used (for example, RFC 2409 specifies three authentication methods using public keys; each one supported will be described in the TSS).
If the selection “Pre-shared Keys that conform to RFC 8784” is chosen, the selection-based requirement FIA_PSK_EXT.1 in Annex B must be claimed.
Application Note 72
When using RSA or ECDSA certificates for peer authentication, the reference and presented identifiers take the form of either a DN, IP address, FQDN or user FQDN. The reference identifier is the identifier the TOE expects to receive from the peer during IKE authentication. The presented identifier is the identifier that is contained within the peer certificate body. The ST author should select the presented and reference identifier types supported and may optionally assign additional supported identifier types in the second selection. Excluding the DN identifier type (which is necessarily the Subject DN in the peer certificate), the TOE may support the identifier in either the Common Name or Subject Alternative Name (SAN) or both.
The critical requirement of X.509 identifiers is the ability to bind the public key uniquely to an identity. This can be achieved by using strongly-typed identifiers or controlling the CA and certificate issuance. One recommended method for identity verification is supporting the use of the Subject Alternative Name (SAN) extension using DNS names, URI names, or Service Names. However, the support for a SAN extension is optional as long as identifier uniqueness can be achieved by other means.
Supported peer certificate algorithms are the same as FCS_IPSEC_EXT.1.13
Application Note 55
This requirement is claimed when a TOE uses one or more external sources of entropy to initialize or reseed a DRBG that is outside the TOE boundary. Seeding a DRBG is the same as initializing a DRBG. In the case of a network device this would only occur with a vND where the entropy source is provided by the underlying virtualization System (VS) platform. The ST author ensures that the assignment is completed with the minimum length of the input sufficient to initialize or reseed a DRBG.
The TSF interface for the purpose of seeding here is the interface used to gather entropy for initializing or reseed.
Application Note 56
This requirement is claimed when a TOE uses a single internal source of entropy to initialize or reseed a DRBG that is within the TOE boundary. Seeding a DRBG is the same as initializing a DRBG.
Hardware-based noise sources are entropy sources whose primary function is noise generation, such as ring oscillators, diodes, and thermal noise. While a TOE may use software to collect the noise from these hardware sources, these are not software-based.
Software-based noise sources generate noise as a byproduct of their normal operation. Examples of software-based noise sources can be user or system-based events such as reading the least significant bits from an event timer, etc.
The TOE collects enough input from the internal noise source such that the total measured entropy of the input is sufficient to initialize or reseed a DRBG. The ST author ensures that the assignment is completed with the number of bits of the input sufficient to initialize or reseed a DRBG.
Application Note 57
This requirement is claimed when a TOE uses two or more internal sources of entropy to initialize or reseed a DRBG. Seeding a DRBG is the same as initializing a DRBG. FCS_RBG.5 defines the mechanism by which these sources are combined to ensure sufficient minimum entropy.
Application Note 58
This requirement is claimed when a TOE combines two or more sources of entropy to initialize or reseed a DRBG. Seeding a DRBG is the same as initializing a DRBG. The ST author ensures that the assignment is completed with the number of bits of the combined entropy sufficient to initialize or reseed a DRBG.
One can apply NIST SP 800-90B (or AIS-31) statistical tests against internal noise sources (a.k.a. raw entropy) to confirm the min-entropy of the noise sources either in aggregate or individually. One should not apply NIST SP 800-90B (or AIS-31) statistical tests against external noise sources since the TOE is unable to enforce entropy requirements or conditioning requirements against external sources of entropy. However, the TSS may include estimates for min-entropy from external sources that contribute to the overall entropy requirements for the DRBG.
to Security Administrators.
Application Note 81
FMT_MOF.1/AutoUpdate is only applicable and should be included if the TOE supports automatic checking for updates and/or automatic updates and allows them to be enabled and disabled. Enable and disable of automatic checking for updates and/or automatic updates is restricted to Security Administrators. The option “automatic update” may only be selected if digital signatures are used to validate the trusted update.
to Security Administrators.
Application Note 82
FMT_MOF.1/Functions should be chosen if one or more of the following scenarios apply:
If the transmission protocol for transmission of audit data to an external IT entity as defined in FAU_STG_EXT.1.1 is configurable, “transmission of audit data to an external IT entity” should be chosen.
If the handling of audit data is configurable, “handling of audit data” must be chosen. The term “handling of audit data” refers to any administratively configurable selection or assignments in any FAU_STG_EXT.x SFR.
If the behaviour of the audit functionality is configurable when Local Audit Storage Space is full, “audit functionality when Local Audit Storage Space is full” must be chosen.
The first selection for ‘determine the behaviour of’ and ‘modify the behaviour of’ should be done as appropriate. It might be necessary to have different selections for the first selection depending on the second selection (e.g., “handling of audit data” might require “determine the behaviour of” and “modify the behaviour of” for the first selection on the one hand and “audit functionality when Local Audit Storage Space is full” might require “modify the behaviour of” only). In that case FMT_MOF.1/Functions should be iterated with increasing number appended (i.e., FMT_MOF.1/Functions1, FMT_MOF.1/Functions2, etc.).
The TSF shall restrict the ability to start and stop the functions services to Security Administrators.
Application Note 80
FMT_MOF.1/Services should only be chosen if the Security Administrator has the ability to start and stop services and the corresponding option has been selected in FMT_SMF.1.
In FMT_MOF.1.1/Services 'enable and disable' have been refined to 'start and stop' and 'the functions: [assignment: list of functions]' has been refined to 'services'.
With respect to FAU_GEN.1.1, FMT_SMF.1 and FMT_MOF.1/Services the term ‘services’ refers to trusted path and trusted channel communications, on demand self-tests, trusted update and Administrator sessions (that exist under the trusted path) (e.g., netconf).
If the certificate is deemed invalid for reasons other than expiration or revocation information being unavailable, the TSF shall not install the update.
Application Note 79
This component must be included in the ST if “X.509 digital signature mechanism” is selected in FPT_TUD_EXT.1.3.
Validity is determined in accordance with FIA_X509_EXT.1. in the Functional Package for X.509
It is acceptable to provide a manual method for an administrator to provide revocation information (e.g., CRL upload) in addition to retrieving revocation information automatically in accordance with FIA_X509_EXT.1 and FIA_X509_EXT.2 in the Functional Package for X.509. It is expected that current updates are signed using current (not expired) certificates that will be valid at least until the next expected update. However, an administrator may desire to install previous updates that are signed by expired certificates. To indicate support for this practice, the author of the ST selects whether the certificate will be accepted, rejected, or the choice is left to the Administrator to accept or reject the certificate.
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. |
Direct Rationale | A type of Protection Profile, PP-Module, or Security Target in which the security problem definition (SPD) elements are mapped directly to the SFRs and possibly to the security objectives for the operational environment. There are no security objectives for the TOE. |
Distributed TOE | A TOE composed of multiple components operating as a logical whole. |
Extended Package (EP) | A deprecated document form for collecting SFRs that implement a particular protocol, technology, or functionality. See Functional Packages. |
Functional Package (FP) | A document that collects SFRs for a particular protocol, technology, or functionality. |
Operational Environment (OE) | Hardware and software that are outside the TOE boundary that support the TOE functionality and security policy. |
Protection Profile (PP) | An implementation-independent set of security requirements for a category of products. |
Protection Profile Configuration (PP-Configuration) | A comprehensive set of security requirements for a product type that consists of at least one Base-PP and at least one PP-Module. |
Protection Profile Module (PP-Module) | An implementation-independent statement of security needs for a TOE type complementary to one or more Base-PPs. |
Security Assurance Requirement (SAR) | A requirement to assure the security of the TOE. |
Security Functional Requirement (SFR) | A requirement for security enforcement by the TOE. |
Security Target (ST) | A set of implementation-dependent security requirements for a specific product. |
Target of Evaluation (TOE) | The product under evaluation. |
TOE Security Functionality (TSF) | The security functionality of the product under evaluation. |
TOE Summary Specification (TSS) | A description of how a TOE satisfies the SFRs in an ST. |
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 administrator 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. [OMB] |
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 | A user 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. |
Virtual Machine (VM) | Blah Blah Blah |
| Acronym | Meaning |
|---|---|
| AES | Advanced Encryption Standard |
| API | Application Programming Interface |
| API | Application Programming Interface |
| app | Application |
| ASLR | Address Space Layout Randomization |
| Base-PP | Base Protection Profile |
| CC | Common Criteria |
| CEM | Common Evaluation Methodology |
| CESG | Communications-Electronics Security Group |
| CMC | Certificate Management over CMS |
| CMS | Cryptographic Message Syntax |
| CN | Common Names |
| cPP | Collaborative Protection Profile |
| CRL | Certificate Revocation List |
| CSA | Computer Security Act |
| CSP | Critical Security Parameters |
| DAR | Data At Rest |
| DEP | Data Execution Prevention |
| DES | Data Encryption Standard |
| DHE | Diffie-Hellman Ephemeral |
| DNS | Domain Name System |
| DRBG | Deterministic Random Bit Generator |
| DSS | Digital Signature Standard |
| DSS | Digital Signature Standard |
| DT | Date/Time Vector |
| DTLS | Datagram Transport Layer Security |
| EAP | Extensible Authentication Protocol |
| ECDHE | Elliptic Curve Diffie-Hellman Ephemeral |
| ECDSA | Elliptic Curve Digital Signature Algorithm |
| EP | Extended Package |
| EST | Enrollment over Secure Transport |
| FIPS | Federal Information Processing Standards |
| FP | Functional Package |
| HMAC | Hash-based Message Authentication Code |
| HTTP | Hypertext Transfer Protocol |
| HTTPS | Hypertext Transfer Protocol Secure |
| IETF | Internet Engineering Task Force |
| IP | Internet Protocol |
| ISO | International Organization for Standardization |
| IT | Information Technology |
| ITSEF | Information Technology Security Evaluation Facility |
| NIAP | National Information Assurance Partnership |
| NIST | National Institute of Standards and Technology |
| OCSP | Online Certificate Status Protocol |
| OE | Operational Environment |
| OID | Object Identifier |
| OMB | Office of Management and Budget |
| OS | Operating System |
| PII | Personally Identifiable Information |
| PKI | Public Key Infrastructure |
| PP | Protection Profile |
| PP | Protection Profile |
| PP-Configuration | Protection Profile Configuration |
| PP-Module | Protection Profile Module |
| RBG | Random Bit Generator |
| RFC | Request for Comment |
| RNG | Random Number Generator |
| RNGVS | Random Number Generator Validation System |
| S/MIME | Secure/Multi-purpose Internet Mail Extensions |
| SAN | Subject Alternative Name |
| SAR | Security Assurance Requirement |
| SFR | Security Functional Requirement |
| SHA | Secure Hash Algorithm |
| SIP | Session Initiation Protocol |
| ST | Security Target |
| SWID | Software Identification |
| TLS | Transport Layer Security |
| TOE | Target of Evaluation |
| TSF | TOE Security Functionality |
| TSFI | TSF Interface |
| TSS | TOE Summary Specification |
| URI | Uniform Resource Identifier |
| URL | Uniform Resource Locator |
| USB | Universal Serial Bus |
| VM | Virtual Machine |
| XCCDF | eXtensible Configuration Checklist Description Format |
| XOR | Exclusive Or |