### Dell Networking SmartFabric OS10.6 ## Security Target Version 1.1 September 2026 Document prepared by [www.lightshipsec.com](https://www.lightshipsec.com/) Page 1 of 54 Dell Technologies Inc. Security Target #### Document History | Version | Date | Author | Description | |-----------|-------------|-----------|------------------------------------| | 1.0 | 10 Aug 2026 | M. Torabi | Released for check-out submission. | | 1.1 | 01 Sep 2026 | M. Torabi | Addressed CB OR. | Page 2 of 54 Dell Technologies Inc. Security Target #### Table of Contents | 1 Introduction ........................................................................................................................... | 1 Introduction ........................................................................................................................... | 5 | |--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------| | 1.1 | Overview ........................................................................................................................ | 5 | | 1.2 | Identification ................................................................................................................... | 5 | | 1.3 | Conformance Claims ...................................................................................................... | 5 | | 1.4 | Terminology | .................................................................................................................... 8 | | 2 TOE Description .................................................................................................................... 9 | 2 TOE Description .................................................................................................................... 9 | 2 TOE Description .................................................................................................................... 9 | | 2.1 | Type | ............................................................................................................................... 9 | | 2.2 | Usage ............................................................................................................................. | 9 | | 2.3 | Security Functions / Logical Scope | ................................................................................ 9 | | 2.4 | Physical Scope ............................................................................................................. | 11 | | 3 Security Problem Definition ............................................................................................... 14 | 3 Security Problem Definition ............................................................................................... 14 | 3 Security Problem Definition ............................................................................................... 14 | | 3.1 | Threats ......................................................................................................................... | 14 | | 3.2 | Assumptions | ................................................................................................................. 15 | | 3.3 | Organizational Security Policies ................................................................................... | 16 | | 4 | Security Objectives ............................................................................................................. | 17 | | 5 | Requirements | 18 | | Security ....................................................................................................... | Security ....................................................................................................... | Security ....................................................................................................... | | 5.1 | Conventions ................................................................................................................. | 18 | | 5.2 | Extended Components Definition ................................................................................. | 18 | | 5.3 | Functional Requirements ............................................................................................. | 18 | | 5.4 | Assurance Requirements ............................................................................................. | 36 | | 6 TOE Summary Specification .............................................................................................. 37 | 6 TOE Summary Specification .............................................................................................. 37 | 6 TOE Summary Specification .............................................................................................. 37 | | 6.1 | Security Audit | ............................................................................................................... 37 | | 6.2 | Cryptographic Support | 37 | | 6.3 | ................................................................................................. Identification and Authentication .................................................................................. | 41 | | 6.4 | Security Management | .................................................................................................. 44 | | 6.5 | Protection of the TSF | ................................................................................................... 45 | | 6.6 | TOE Access | ................................................................................................................. 48 | | 6.7 | Trusted Path/Channels | ................................................................................................ 49 | | Rationale .............................................................................................................................. 50 | Rationale .............................................................................................................................. 50 | Rationale .............................................................................................................................. 50 | | 7 7.1 | Conformance Claim Rationale ..................................................................................... | 50 | | 7.2 | Security Objectives Rationale ...................................................................................... | 50 | | 7.3 Annex | Security Requirements Rationale ................................................................................. A: Extended Components Definition | 50 ............................................................................. 54 | | List of Tables | List of Tables | List of Tables | | Table 1: Evaluation identifiers ......................................................................................................... | Table 1: Evaluation identifiers ......................................................................................................... | 5 | | Table 2: NIAP Technical Decisions ................................................................................................. | Table 2: NIAP Technical Decisions ................................................................................................. | 5 | | Table 3: Terminology ....................................................................................................................... | Table 3: Terminology ....................................................................................................................... | 8 | | Table 4: CAVP Certificates ............................................................................................................ | Table 4: CAVP Certificates ............................................................................................................ | 10 | | Table 5: TOE models ..................................................................................................................... | Table 5: TOE models ..................................................................................................................... | 12 | | Table 6: Threats............................................................................................................................. | Table 6: Threats............................................................................................................................. | 14 | | Table 7: Assumptions .................................................................................................................... | Table 7: Assumptions .................................................................................................................... | 15 | | Table 8: Organizational Security Policies ...................................................................................... | Table 8: Organizational Security Policies ...................................................................................... | 16 ..................................................... 17 | | Table 9: Security Objectives for the Operational Environment Table 10: Summary of SFRs ......................................................................................................... | Table 9: Security Objectives for the Operational Environment Table 10: Summary of SFRs ......................................................................................................... | 18 | | Table 11: Audit Events .................................................................................................................. | Table 11: Audit Events .................................................................................................................. | 20 | Page 3 of 54 Dell Technologies Inc. Security Target Table 12: Assurance Requirements .............................................................................................. 36 Table 13: Key Agreement Mapping ............................................................................................... 38 Table 14: HMAC Characteristics ................................................................................................... 39 Table 15: Keys ............................................................................................................................... 45 Table 16: Passwords ..................................................................................................................... 46 Table 17: NDcPP SFR Rationale .................................................................................................. 50 Page 4 of 54 Dell Technologies Inc. Security Target ### 1 Introduction ### 1.1 Overview - 1 This Security Target (ST) defines the Dell Networking SmartFabric OS10.6 Target of Evaluation (TOE) for the purposes of Common Criteria (CC) evaluation. ### 1.2 Identification Table 1: Evaluation identifiers | Vendor Name | Dell Technologies Inc. | |----------------------|----------------------------------------------------------| | Target of Evaluation | Dell Networking SmartFabric OS10.6 OS Version: 10.6.1 | | Security Target | Dell Networking SmartFabric OS10.6 Security Target, v1.1 | ### 1.3 Conformance Claims - 2 This ST supports the following conformance claims: - a) CC version 3.1 revision 5 - b) CC Part 2 extended - c) CC Part 3 conformant - d) collaborative Protection Profile for Network Devices, v3.0e (referenced within as NDcPP) - e) Functional Package for SSH, v1.0 (reference within as PKG_SSH) conformant - f) NIAP Technical Decisions per Table 2 Table 2: NIAP Technical Decisions | TD # | Name | References | Applicability Rationale | Source | |--------|---------------------------------------------------------------------|------------------------|---------------------------|----------| | TD0682 | Addressing Ambiguity in FCS_SSHS_EXT.1 Tests | FCS_SSHS_EXT.1 | Applicable. | PKG_SSH | | TD0695 | Choice of 128 or 256 bit size in AES-CTR in SSH Functional Package. | Section 1.3, FCS_COP.1 | Applicable. | PKG_SSH | | TD0732 | FCS_SSHS_EXT.1.3 Test 2 Update | FCS_SSH_EXT.1.3 | Applicable. | PKG_SSH | | TD0777 | Clarification to Selections for Auditable Events for FCS_SSH_EXT.1 | Section 3.1, Table 1 | Applicable. | PKG_SSH | Page 5 of 54 Dell Technologies Inc. Security Target | TD # | Name | References | Applicability Rationale | Source | |--------|-------------------------------------------------------------------------------------------------|----------------------------------------------------|---------------------------------------------------|----------| | TD0836 | NIT Technical Decision: Redundant Requirements in FPT_TST_EXT.1 | FPT_TST_EXT.1, CPP_ND_V3.0E-SD, Section 4.1.5 | Applicable. | NDcPP | | TD0868 | NIT Technical Decision: Clarification of time frames in FCS_IPSEC_EXT.1.7 and FCS_IPSEC_EXT.1.8 | FCS_IPSEC_EXT.1.7, FCS_IPSEC_EXT.1.8 | IPSEC not implemented by the TOE. Not Applicable. | NDcPP | | TD0879 | NIT Decision: Correction of Chapter Headings in CPP_ND_V3.0E | Appendix B.6.3, Appendix B.7 | Applicable. | NDcPP | | TD0880 | NIT Decision: Removal of Duplicate Selection in FMT_SMF.1.1 | FMT_SMF.1.1 | Applicable. | NDcPP | | TD0886 | Clarification to FAU_STG_EXT.1 Test 6 | FAU_STG_EXT.1, CPP_ND_V3.0E-SD | Applicable. | NDcPP | | TD0899 | NIT Technical Decision: Correction of Renegotiation Test for TLS 1.2 | FCS_TLSC_EXT.1.9, FCS_TLSS_EXT.1.8, CPP_ND_3.0E-SD | Applicable. | NDcPP | | TD0900 | NIT Technical Decision: Clarification to Local Administrator Access in FIA_UIA_EXT.1.3 | FIA_UIA_EXT.1.3 | Applicable. | NDcPP | | TD0909 | Updates to FCS_SSH_EXT.1.1 App Note in SSH FP 1.0 | FCS_SSH_EXT.1.1 | Applicable. | PKG_SSH | | TD0921 | NIT Technical Decision: Addition of FIPS PUB 186-5 and Correction of Assignment | FCS_CKM.1, FCS_COP.1/SigGen, CPP_ND_V3.0e-SD | Applicable. | NDcPP | | TD0923 | NIT Technical Decision: Auditable event for FAU_STG_EXT.1 in FAU_GEN.1.2 | FAU_GEN.1.2 | Applicable. | NDcPP | | TD0967 | Allowance of Kex-strict in PKG_SSH_V1.0 | FCS_SSH_EXT.1.6 | Applicable. | PKG_SSH | Page 6 of 54 Dell Technologies Inc. Security Target | TD # | Name | References | Applicability Rationale | Source | |--------|----------------------------------------------------------------------------------------------|--------------------------------------------------------|-----------------------------------------------------|----------| | TD0973 | NIT Technical Decision: FCS_(D)TLSS_EXT.1.3 Test 2 DHE Ciphersuite Conditionality | FCS_TLSS_EXT.1.3, FCS_DTLSS_EXT.1.3, CPP_ND_V3.0E-SD | Not Applicable. TOE is not a (D)TLS server. | NDcPP | | TD0990 | NIT Technical Decision: CTR_DRBG in FCS_RBG_EXT.1.2 | FCS_RBG_EXT.1.2 | Applicable. | NDcPP | | TD1015 | Addition of ECD to PKG_SSH_V1.0 | ECD | Applicable. | PKG_SSH | | TD1023 | Clarifications to FCS_SSH_EXT.1.5 When aes256- gcm@openssh.com Is Selected | FCS_SSH_EXT.1.5 | Applicable. | PKG_SSH | | TD1033 | Sunset Dates for NDcPP Configurations | Sunset Date | Applicable. | NDcPP | | TD1052 | NIT Technical Decision: Separation of Test Definitions for DTLSv1.2 and v1.3 (Renegotiation) | FCS_DTLSC_EXT.1.9, FCS_DTLSS_EXT.1.11, CPP_ND_V3.0E-SD | Not Applicable. TOE does not claim DTLS interfaces. | NDcPP | Page 7 of 54 Dell Technologies Inc. Security Target ### 1.4 Terminology Table 3: Terminology | Term | Definition | |--------|------------------------------------------------------| | CC | Common Criteria | | NDcPP | collaborative Protection Profile for Network Devices | | PP | Protection Profile | | TOE | Target of Evaluation | | TSF | TOE Security Functionality | Page 8 of 54 Dell Technologies Inc. Security Target ### 2 TOE Description ### 2.1 Type - 3 The TOE is a network switch. ### 2.2 Usage - 4 The TOE is deployed within a network to provide layer 2 and layer 3 network management and interconnectivity functionality. The TOE interfaces within the scope of evaluation are shown in Figure 1. - 5 The TOE interfaces are as follows: - a) CLI. Administrative CLI via direct serial connection or SSH. - b) Logs. Syslog via TLS. Figure 1: Example TOE deployment ### 2.3 Security Functions / Logical Scope - 6 The TOE provides the following security functions: - a) Trusted Path/Channels. The TOE protects the integrity and confidentiality of communications using secure protocols as noted in section 2.2 above, and using cryptographic algorithms as described in Table 4. - b) Secure Management. The TOE enables secure management of its security functions, including: - i) Administrator authentication with passwords Page 9 of 54 Dell Technologies Inc. Security Target - ii) Configurable password policies - iii) Role Based Access Control - iv) Access banners - v) Management of critical security functions and data - vi) Protection of cryptographic keys and passwords - c) Trusted Update. The TOE ensures the authenticity and integrity of software updates through GPG digital signatures and published hash. The TOE also implements 'show version' CLI command that displays information about firmware version running on the TOE. An authorized user must authenticate to the secure Dell Support website where the software downloads are available. The downloaded image must be transferred to the appliance using a secure method such as Secure Copy or SFTP. - d) Protection of the TSF. The TOE performs a suite of self-tests to ensure the correct operation and enforcement of its security functions. The TOE performs diagnostic self-tests and cryptographic module self-tests during start-up and generates audit records to record a failure. Self-tests comply with the FIPS 140-2 requirements for self-testing. Note. For the evaluated configuration, Secure Boot must be enabled in the system BIOS. - e) Identification and Authentication. The TOE ensures that all users must be authenticated before accessing its functions and data. TOE can be accessed directly via serial RJ45 connection or remotely via SSHv2 connection. When a user account has sequentially failed authentication the configured number of times, the account will be locked for a Security Administrator defined time period. The TOE uses X.509v3 certificates to support authentication for TLS. Certificate revocation checking is performed using a CRL. - f) Security Audit. The TOE generates audit records of security-relevant events, including user and administrator actions, and logs these events locally. Each audit event includes identity of the user responsible for the action, when applicable. Additionally, the Security Administrator can configure the TOE to send logs in real-time to a syslog server via TLS. - g) Cryptographic Support. The TOE implements a cryptographic module. The cryptographic module has the ability to generate and destroy cryptographic keys. Relevant Cryptographic Algorithm Validation Program (CAVP) certificates are shown in Table 4. Table 4: CAVP Certificates | SFR | Algorithm(s) (Keys/curves/digest-size) | Standard | Usage | Module | Certificate | |---------------------------|------------------------------------------|------------------------|----------|--------------------------------------------|---------------| | FCS_COP.1/Data Encryption | AES-CTR (128, 256-bit) | ISO 18033-3, ISO 10116 | SSH | Dell FIPS Module based on the OpenSSL FIPS | A8619 | | FCS_COP.1/Data Encryption | AES-GCM (128, 256-bit) | ISO 18033-3, ISO 19772 | SSH, TLS | Dell FIPS Module based on the OpenSSL FIPS | A8619 | Page 10 of 54 Dell Technologies Inc. Security Target | SFR | Algorithm(s) (Keys/curves/digest-size) | Standard | Usage | Module | Certificate | |----------------------|------------------------------------------------------------------------------|-------------------------------------------------------------------|-------------------------------------------------|-----------------|---------------| | FCS_CKM.1 | RSA KeyGen 2048, 3072, 4096- bit | FIPS PUB 186-4 / FIPS PUB 186-5 | SSH, TLS | Provider v3.1.2 | | | FCS_CKM.1 | ECDSA KeyGen P-256, P-384, P-521 | FIPS PUB 186-4 / FIPS PUB 186-5, ISO/IEC 14888-3 | SSH, TLS | | | | FCS_COP.1/ SigGen | RSA SigGen 2048, 3072, 4096- bit RSA SigVer 2048, 3072, 4096- bit | FIPS PUB 186-4 / FIPS PUB 186-5, ISO/IEC 9796-2 | SSH, TLS, Update Verification | | | | FCS_COP.1/ SigGen | ECDSA SigGen P-256, P-384, P-521 ECDSA SigVer P-256, P-384, P-521 | FIPS PUB 186-4 / FIPS PUB 186-5, ISO/IEC 14888-3, NIST SP 800-186 | SSH, TLS | | | | FCS_COP.1/Hash | SHA-256 (256-bit digest), SHA-384 (384-bit digest), SHA-512 (512-bit digest) | ISO/IEC 10118-3:2004 | TLS, SSH, Password Storage, Update Verification | | | | FCS_COP.1/ KeyedHash | HMAC-SHA-256 (256-bit key/digest), HMAC-SHA-512 (512-bit key/digest) | ISO/IEC 9797- 2:2011 Section 7 | TLS, SSH | | | | FCS_CKM.2 | KAS-ECC P-256, P-384, P-521 | NIST SP 800-56A Revision 3 | SSH, TLS | | | | FCS_RBG_EXT.1 | Counter DRBG (AES-256) | ISO/IEC 18031:2011 | Entropy source | | | ### 2.4 Physical Scope - 7 The physical boundary of the TOE includes all software and hardware shown in the Table 5 TOE is delivered via commercial courier. Page 11 of 54 Dell Technologies Inc. Security Target Table 5: TOE models | Type | Model | CPU | Software | CAVP | |----------|---------------------------------------------------------------------|------------------------------------|---------------------------------------|--------| | Physical | S4112F-ON S4112T-ON S4128F-ON S4128T-ON S4148F-ON S4148T-ON MX5108n | Intel Atom C2338 (Silvermont) | Dell Networking SmartFabric OS 10.6.1 | A8619 | | Physical | S5212F-ON N3248TE-ON | Intel Atom C3338 (Denverton) | | | | Physical | S5224F-ON S5232F-ON S5248F-ON S5296F-ON | Intel Atom C3538 (Goldmont) | | | | Physical | Z9432F-ON S5448F-ON | Intel Atom C3758 (Goldmont) | | | | Physical | E3224F-ON S3248T-ON | Intel Atom C3558/C3558R (Goldmont) | | | | Physical | Z9664F-ON | Intel Xeon D-1714 (Ice Lake) | | | #### 2.4.1 Guidance Documents - 8 The TOE includes the following guidance documents (PDF): - a) Dell Networking SmartFabric OS10.6 Common Criteria Guide, v1.0 - b) Dell SmartFabric OS10 User Guide Release 10.6.1, April 2026 Rev. A00 Page 12 of 54 Dell Technologies Inc. Security Target #### 2.4.2 Non-TOE Components - 9 The TOE operates with the following components in the environment: - a) Audit Server. The TOE can send audit events to a Syslog server. #### 2.4.3 Functions not included in the TOE Evaluation The evaluation is limited to those security functions identified in Security Functions / Logical Scope 2.3. Switching and software defined networking functions are outside - 10 the scope of TOE security functions. Page 13 of 54 Dell Technologies Inc. Security Target ### 3 Security Problem Definition 11 The Security Problem Definition is reproduced from section 4 of the NDcPP. ### 3.1 Threats Table 6: Threats | Identifier | Description | |---------------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | T.UNAUTHORIZED_ ADMINISTRATOR_ ACCESS | 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. | | T.WEAK_ CRYPTOGRAPHY | Threat agents may exploit weak cryptographic algorithms or perform a cryptographic exhaust against the key space. Poorly chosen encryption algorithms, modes, and key sizes will allow attackers to compromise the algorithms, or brute force exhaust the key space and give them unauthorized access allowing them to read, manipulate and/or control the traffic with minimal effort. | | T.UNTRUSTED_ COMMUNICATION_ CHANNELS | 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. | | T.WEAK_ AUTHENTICATION_ ENDPOINTS | 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. | | T.UPDATE_ COMPROMISE | 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. | | T.UNDETECTED_ ACTIVITY | 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 | Page 14 of 54 Dell Technologies Inc. Security Target | Identifier | Description | |---------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | | the Administrator would have no knowledge that the device has been compromised. | | T.SECURITY_ FUNCTIONALITY_ COMPROMISE | 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. | | T.SECURITY_ FUNCTIONALITY_ FAILURE | An external, unauthorized 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. | ### 3.2 Assumptions Table 7: Assumptions | Identifier | Description | |--------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | A.PHYSICAL_ PROTECTION | 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 unauthorized 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. | | A.LIMITED_ FUNCTIONALITY | The device is assumed to provide networking functionality as its core function and not provide functionality/services that could be deemed as general purpose computing. For example, the device should not provide a computing platform for general purpose applications (unrelated to networking functionality). If 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 the 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. | Page 15 of 54 Dell Technologies Inc. Security Target | Identifier | Description | |--------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | A.NO_THRU_ TRAFFIC_ PROTECTION | 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. Traffic that is traversing the Network Device, destined for another network entity, is not covered by the ND cPP. It is assumed that this protection will be covered by cPPs and PP-Modules for particular types of Network Devices (e.g., firewall). | | A.TRUSTED_ ADMINISTRATOR | 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 appropriately trained, 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). | | A.REGULAR_ UPDATES | 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. | | A.ADMIN_ CREDENTIALS_ SECURE | The Administrator's credentials (private key) used to access the Network Device are protected by the platform on which they reside. | | A.RESIDUAL_ INFORMATION | The Administrator must ensure that there is no unauthorized 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. | ### 3.3 Organizational Security Policies Table 8: Organizational Security Policies | Identifier | Description | |-----------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | P.ACCESS_BANNER | The TOE shall display an initial banner describing restrictions of use, legal agreements, or any other appropriate information to which Administrators consent by accessing the TOE. | Page 16 of 54 Dell Technologies Inc. Security Target ### 4 Security Objectives 12 The security objectives are reproduced from section 5 of the NDcPP. Table 9: Security Objectives for the Operational Environment | Identifier | Description | |---------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | OE.PHYSICAL | Physical security, commensurate with the value of the TOE and the data it contains, is provided by the environment. | | OE.NO_GENERAL_ PURPOSE | 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 the its own VM, and does not include other VMs or the VS. | | OE.NO_THRU_ TRAFFIC_ PROTECTION | 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. | | OE.TRUSTED_ADMIN | 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(s) are 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. | | OE.UPDATES | The TOE firmware and software is updated by an Administrator on a regular basis in response to the release of product updates due to known vulnerabilities. | | OE.ADMIN_ CREDENTIALS_ SECURE | The Administrator's credentials (private key) used to access the TOE must be protected on any other platform on which they reside. | | OE.RESIDUAL_ INFORMATION | The Security Administrator ensures that there is no unauthorized 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. | Page 17 of 54 Dell Technologies Inc. Security Target ### 5 Security Requirements ### 5.1 Conventions - 13 This document uses the following font conventions to identify the operations defined by the CC: - a) Assignment. Indicated with italicized text. - b) Refinement. Indicated with bold text and strikethroughs. - c) Selection. Indicated with underlined text. - d) Assignment within a Selection: Indicated with italicized and underlined text. - e) Iteration. Indicated by adding a string starting with '/' (e.g. 'FCS_COP.1/Hash'). - 14 Note: Operations performed within the Security Target are denoted within brackets []. Operations shown without brackets are reproduced from the NDcPP. ### 5.2 Extended Components Definition - 15 Refer to Annex A: Extended Components Definition. ### 5.3 Functional Requirements Table 10: Summary of SFRs | Requirement | Title | |--------------------------|-----------------------------------------------------------------| | FAU_GEN.1 | Audit Data Generation | | FAU_GEN.2 | User identity association | | FAU_STG_EXT.1 | Protected Audit Event Storage | | FCS_CKM.1 | Cryptographic Key Generation | | FCS_CKM.2 | Cryptographic Key Establishment | | FCS_CKM.4 | Cryptographic Key Destruction | | FCS_COP.1/DataEncryption | Cryptographic Operation (AES Data Encryption/Decryption) | | FCS_COP.1/SigGen | Cryptographic Operation (Signature Generation and Verification) | | FCS_COP.1/Hash | Cryptographic Operation (Hash Algorithm) | | FCS_COP.1/KeyedHash | Cryptographic Operation (Keyed Hash Algorithm) | | FCS_RBG_EXT.1 | Random Bit Generation | | FCS_SSH_EXT.1 | SSH Protocol | Page 18 of 54 Dell Technologies Inc. Security Target | Requirement | Title | |------------------------|------------------------------------------------------------| | FCS_SSHS_EXT.1 | SSH Protocol - Server | | FCS_TLSC_EXT.1 | TLS Client Protocol | | FCS_TLSC_EXT.2 | TLS Client Support for Mutual Authentication | | FIA_AFL.1 | Authentication Failure Handling | | FIA_PMG_EXT.1 | Password Management | | FIA_UIA_EXT.1 | User Identification and Authentication | | FIA_UAU.7 | Protected Authentication Feedback (Refinement) | | FIA_X509_EXT.1/Rev | X.509 Certificate Validation | | FIA_X509_EXT.2 | X.509 Certificate Authentication | | FIA_X509_EXT.3 | X.509 Certificate Requests | | FMT_MOF.1/ManualUpdate | Management of Security Functions Behaviour | | FMT_MOF.1/Functions | Management of Security Functions Behaviour | | FMT_MTD.1/CoreData | Management of TSF Data | | FMT_MTD.1/CryptoKeys | Management of TSF Data | | FMT_SMF.1 | Specification of Management Functions | | FMT_SMR.2 | Restrictions on Security Roles | | FPT_SKP_EXT.1 | Protection of TSF Data (for reading of all symmetric keys) | | FPT_APW_EXT.1 | Protection of Administrator Passwords | | FPT_TST_EXT.1 | TSF Testing | | FPT_TUD_EXT.1 | Trusted Update | | FPT_STM_EXT.1 | Reliable Time Stamps | | FTA_SSL_EXT.1 | TSF-initiated Session Locking | | FTA_SSL.3 | TSF-initiated Termination | | FTA_SSL.4 | User-initiated Termination | | FTA_TAB.1 | Default TOE Access Banners | Page 19 of 54 Dell Technologies Inc. Security Target | Requirement | Title | |-----------------|---------------------------| | FTP_ITC.1 | Inter-TSF Trusted Channel | | FTP_TRP.1/Admin | Trusted Path | #### 5.3.1 Security Audit (FAU) ####### FAU_GEN.1 Audit Data Generation ####### FAU_GEN.1.1 The TSF shall be able to generate an audit record of the following auditable events: - a) Start-up and shutdown of the audit functions; - b) All auditable events for the not specified level of audit; and - c) All administrative actions comprising: 4. o Administrative login and logout (name of Administrator account shall be logged if individual accounts are required for Administrators). 5. o 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). 6. o 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). 7. o [Resetting passwords (name of related Administrator account shall be logged), no other actions]]; - d) Specifically defined auditable events listed in Table 2 Table 11 . Table 11: Audit Events | Requirement | Auditable Events | Additional Audit Record Contents | |--------------------------|----------------------------------------|----------------------------------------------------------------| | FAU_GEN.1 | None. | None. | | FAU_GEN.2 | None. | None. | | FAU_STG_EXT.1 | Configuration of local audit settings. | Identity of account making changes to the audit configuration. | | FCS_CKM.1 | None. | None. | | FCS_CKM.2 | None. | None. | | FCS_CKM.4 | None. | None. | | FCS_COP.1/DataEncryption | None. | None. | Page 20 of 54 Dell Technologies Inc. Security Target | Requirement | Auditable Events | Additional Audit Record Contents | |---------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | FCS_COP.1/SigGen | None. | None. | | FCS_COP.1/Hash | None. | None. | | FCS_COP.1/KeyedHash | None. | None. | | FCS_RBG_EXT.1 | None. | None. | | FCS_SSH_EXT.1 | • [Failure to establish SSH connection] • [Establishment of SSH connection] • [Termination of SSH connection session] • [Dropping of packet(s) outside defined size limits] | • [Reason for failure and Non-TOE endpoint of attempted connection (IP Address)] • [Non-TOE endpoint of connection (IP Address)] • [Non-TOE endpoint of connection (IP Address)] | | FCS_SSHS_EXT.1 | No events specified. | • [Packet size] N/A | | FCS_TLSC_EXT.1 | Failure to establish a TLS Session | Reason for failure | | FCS_TLSC_EXT.2 | None. | None | | FIA_AFL.1 | Unsuccessful login attempts limit is met or exceeded. | Origin of the attempt (e.g., IP address). | | FIA_PMG_EXT.1 | None. | None. | | FIA_UIA_EXT.1 | All use of identification and authentication mechanism. | Origin of the attempt (e.g., IP address). | | FIA_UAU.7 | None. | None. | | FIA_X509_EXT.1/Rev | • Unsuccessful attempt to validate a certificate • Any addition, replacement or removal of trust anchors in the TOE's trust store | • Reason for failure of certificate validation • Identification of certificates added, replaced or removed as trust anchor in the TOE's trust store | | FIA_X509_EXT.2 | None. | None. | | FIA_X509_EXT.3 | None. | None. | Page 21 of 54 Dell Technologies Inc. Security Target | Requirement | Auditable Events | Additional Audit Record Contents | |--------------------------------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------| | FMT_MOF.1/ManualUpdate | Any attempt to initiate a manual update. | None. | | FMT_MOF.1/Functions | None. | None. | | FMT_MTD.1/CoreData | None. | None. | | FMT_MTD.1/CryptoKeys | None. | None. | | FMT_SMF.1 | All management activities of TSF data. | None. | | FMT_SMR.2 | None. | None. | | FPT_SKP_EXT.1 | None. | None. | | FPT_APW_EXT.1 | None. | None. | | FPT_TST_EXT.1 | None. | None. | | FPT_TUD_EXT.1 | Initiation of update; result of the update attempt (success or failure) | None. | | FPT_STM_EXT.1 | Discontinuous changes to time - either Administrator actuated or changed via an automated process. (Note that 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). | | FTA_SSL_EXT.1 (if 'terminate the session' is selected) | The termination of a local session by the session locking mechanism. | None. | | FTA_SSL.3 | The termination of a remote session by the session locking mechanism. | None. | | FTA_SSL.4 | The termination of an interactive session. | None. | | FTA_TAB.1 | None. | None. | Page 22 of 54 Dell Technologies Inc. Security Target | Requirement | Auditable Events | Additional Audit Record Contents | |-----------------|------------------------------------------------------------------------------------------------------------------------|------------------------------------| | FTP_ITC.1 | • Initiation of the trusted channel. • Termination of the trusted channel. • Failure of the trusted channel functions. | • None • None • Reason for failure | | FTP_TRP.1/Admin | • Initiation of the trusted path. • Termination of the trusted path. • Failure of the trusted path functions. | • None • None • Reason for failure | - FAU_GEN.1.2 The TSF shall record within each audit record at least the following information: - a) Date and time of the event, type of event, subject identity (if applicable), and the outcome (success or failure) of the event; and - b) For each audit event type, based on the auditable event definitions of the functional components included in the cPP/ST, information specified in column three of Table 2 Table 11 . - User identity association For audit events resulting from actions of identified users, the TSF shall ####### FAU_GEN.2 - FAU_GEN.2.1 be able to associate each auditable event with the identity of the user that caused the event. ####### FAU_STG_EXT.1 Protected Audit Event Storage - FAU_STG_EXT.1.1 The TSF shall be able to transmit the generated audit data to an external IT entity using a trusted channel according to FTP_ITC.1. - FAU_STG_EXT.1.2 The TSF shall be able to store generated audit data on the TOE itself. In addition [ - The TOE shall consist of a single standalone component that stores audit data locally] - FAU_STG_EXT.1.3 The TSF shall maintain a [log file] of audit records in the event that an interruption of communication with the remote audit server occurs. - FAU_STG_EXT.1.4 The TSF shall be able to store [persistent] audit records locally with a minimum storage size of [ 5 rotated log files of 1GB each ]. Page 23 of 54 Dell Technologies Inc. Security Target FAU_STG_EXT.1.5 FAU_STG_EXT.1.6 The TSF shall [overwrite previous audit records according to the following rule: [ log rotation: delete oldest log file ]] when the local storage space for audit data is full. The TSF shall provide the following mechanisms for administrative access to locally stored audit records [ability to view locally]. #### 5.3.2 Cryptographic Support (FCS) ####### FCS_CKM.1 ####### Cryptographic Key Generation FCS_CKM.1.1 Application note: The TSF shall generate asymmetric cryptographic keys in accordance with a specified cryptographic key generation algorithm: [ - RSA schemes using cryptographic key sizes of [ 2048-bit, 3072-bit, 4096-bit ] that meet the following: FIPS PUB 1864, 'Digital Signature Standard (DSS)', Appendix B.3 or FIPS PUB 186-5, "Digital Signature Standard (DSS)", A.1; - ECC schemes using ' NIST curves ' [P-256, P-384, P-521] that meet the following: FIPS PUB 1864, 'Digital Signature Standard (DSS)', Appendix B.4, or FIPS PUB 1865, 'Digital Signature Standard (DSS)', Appendix A.2, or ISO/IEC 14888 - 3, 'IT Security techniques - Digital signatures with appendix - Part 3: Discrete logarithm based mechanisms', Section 6.6. ; ] and specified cryptographic key sizes [assignment: cryptographic key sizes] that meet the following: [assignment: list of standards]. This SFR modified by TD0921. ####### FCS_CKM.2 ####### Cryptographic Key Establishment FCS_CKM.2.1 ####### FCS_CKM.4 The TSF shall perform cryptographic key establishment in accordance with a specified cryptographic key establishment method: [ - Elliptic curve-based key establishment schemes that meet the following: NIST Special Publication 800-56A Revision 3, 'Recommendation for Pair -Wise Key Establishment Schemes Using Discrete Logarithm Cryptography'; ] that meets the following: [assignment: list of standards]. ####### Cryptographic Key Destruction FCS_CKM.4.1 The TSF shall destroy cryptographic keys in accordance with a specified cryptographic key destruction method - For plaintext keys in volatile storage, the destruction shall be executed by a [single overwrite consisting of [zeroes]]; - For plaintext keys in non-volatile storage, the destruction shall be executed by the invocation of an interface provided by a part of the TSF that [ Page 24 of 54 Dell Technologies Inc. Security Target - o logically addresses the storage location of the key and performs a [single overwrite consisting of [zeroes]] that meets the following: No Standard . ####### FCS_COP.1/DataEncryption Cryptographic Operation (AES Data Encryption/Decryption) FCS_COP.1.1/DataEncryption The TSF shall perform encryption/decryption in accordance with a specified cryptographic algorithm AES used in [CTR, GCM] mode and cryptographic key sizes [128 bits, 256 bits] that meet the following: AES as specified in ISO 18033-3, [CTR as specified in ISO 10116, GCM as specified in ISO 19772]. ####### FCS_COP.1/SigGen Cryptographic Operation (Signature Generation and Verification) FCS_COP.1.1/SigGen The TSF shall perform cryptographic signature services (generation and verification) in accordance with a specified cryptographic algorithm [ - RSA Digital Signature Algorithm, - Elliptic Curve Digital Signature Algorithm ] And cryptographic key sizes [ - For RSA: [ 2048-bit, 3072-bit, 4096-bit ], - For ECDSA: [ 256-bit, 384-bit, 521-bit ] ] That meet the following: [ - For RSA schemes: FIPS PUB 1864, 'Digital Signature Standard (DSS)', Section 5.5, using PKCS #1 v2.1 or FIPS PUB 186-5, "Digital Signature Standard (DSS)", Section 5.4 using PKCS #1 v2.2 Signature Schemes RSASSA-PSS and/or RSASSA-PKCS1v1_5; ISO/IEC 9796-2, Digital signature scheme 2 or Digital Signature scheme 3, - For ECDSA schemes implementing [P-256, P-384, P-521] curves that meet the following: FIPS PUB 1864, 'Digital Signature Standard (DSS)', Section 6 and Appendix D, Implementing 'NIST Recommended' curves; or FIPS PUB 186-5, "Digital Signature Standard (DSS)", Section 6 and NIST SP 800-186 Section 3.2.1, Implementing Weierstrass curves; or ISO/IEC 14888-3, "IT Security techniques - Digital signatures with appendix - Part 3: Discrete logarithm based mechanisms", Section 6.6. ]. Application note: This SFR modified by TD0921. ####### FCS_COP.1/Hash Cryptographic Operation (Hash Algorithm) Page 25 of 54 Dell Technologies Inc. Security Target FCS_COP.1.1/Hash The TSF shall perform cryptographic hashing services in accordance with a specified cryptographic algorithm [SHA-256, SHA-384, SHA-512] and cryptographic key sizes [assignment: cryptographic key sizes] and message digest sizes [256, 384, 512] bits that meet the following: ISO/IEC 10118-3:2004 . ####### FCS_COP.1/KeyedHash Cryptographic Operation (Keyed Hash Algorithm) FCS_COP.1.1/KeyedHash The TSF shall perform keyed-hash message authentication in accordance with a specified cryptographic algorithm [HMAC-SHA-256, HMAC-SHA-512] and cryptographic key sizes [256, 512] and message digest sizes [256, 512] bits that meet the following: ISO/IEC 97972:2011, Section 7 'MAC Algorithm 2' . ####### FCS_RBG_EXT.1 Random Bit Generation FCS_RBG_EXT.1.1 FCS_RBG_EXT.1.2 Application note: The TSF shall perform all deterministic random bit generation services in accordance with ISO/IEC 18031:2011 using [CTR_DRBG (AES)]. The deterministic RBG shall be seeded by at least one entropy source that accumulates entropy from [[ one ] platform-based noise source] with a minimum of [256 bits] of entropy at least equal to [ - the greatest security strength according to ISO/IEC 18031:2011 Table C.2 - "Security strengths, Entropy and Seed length requirements for the AES-128, 192 and 256 Block Cipher", ] This SFR modified by TD0990. ####### FCS_SSH_EXT.1 SSH Protocol FCS_SSH_EXT.1.1 FCS_SSH_EXT.1.2 The TSF shall implement SSH acting as a [server] in accordance with that complies with RFCs 4251, 4252, 4253, 4254, [4344, 5647, 5656, 6668, 8308, 8332] and [no other standard]. The TSF shall ensure that the SSH protocol implementation supports the following authentication methods: [ - 'password' (RFC 4252) , - 'publickey' (RFC 4252): [ - o rsa-sha2-256 (RFC 8332), - o rsa-sha2-512 (RFC 8332), - o ecdsa-sha2-nistp256 (RFC 5656), - o ecdsa-sha2-nistp384 (RFC 5656), - o ecdsa-sha2-nistp521 (RFC 5656) ] and no other methods. Page 26 of 54 Dell Technologies Inc. Security Target FCS_SSH_EXT.1.3 The TSF shall ensure that, as described in RFC 4253, packets greater than [ 256K bytes ] in an SSH transport connection are dropped. FCS_SSH_EXT.1.4 The TSF shall protect data in transit from unauthorised disclosure using the following mechanisms: [ - aes128-ctr (RFC 4344), - aes256-ctr (RFC 4344), - aes128-gcm@openssh.com (RFC 5647), - aes256-gcm@openssh.com (RFC 5647) ] and no other mechanisms. FCS_SSH_EXT.1.5 The TSF shall protect data in transit from modification, deletion, and insertion using: [ - hmac-sha2-256 (RFC 6668), - hmac-sha2-512 (RFC 6668), - implicit — ] and no other mechanisms. FCS_SSH_EXT.1.6 The TSF shall establish a shared secret with its peer using: [ - ecdh-sha2-nistp256 (RFC 5656), - ecdh-sha2-nistp384 (RFC 5656), - ecdh-sha2-nistp521 (RFC 5656), ] and no other mechanisms. FCS_SSH_EXT.1.7 The TSF shall use SSH KDF as defined in [ FCS_SSH_EXT.1.8 - RFC 4253 (Section 7.2), - RFC 5656 (Section 4) ] to derive the following cryptographic keys from a shared secret: session keys. The TSF shall ensure that [selection: - a rekey of the session keys ] occurs when any of the following thresholds are met: - one hour connection time - no more than one gigabyte of transmitted data, or - no more than one gigabyte of received data. ####### FCS_SSHS_EXT.1 SSH Protocol - Server FCS_SSHS_EXT.1 The TSF shall authenticate itself to its peer (SSH Client) using: [ Page 27 of 54 Dell Technologies Inc. Security Target - rsa-sha2-256 (RFC 8332), - rsa-sha2-512 (RFC 8332), - ecdsa-sha2-nistp256 (RFC 5656), - ecdsa-sha2-nistp384 (RFC 5656), - ecdsa-sha2-nistp521 (RFC 5656), ]. ####### FCS_TLSC_EXT.1 TLS Client Protocol FCS_TLSC_EXT.1.1 The TSF shall implement [TLS 1.3 (RFC 8446), TLS 1.2 (RFC 5246)] FCS_TLSC_EXT.1.2 FCS_TLSC_EXT.1.3 supporting the following ciphersuites: [ - TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 as defined in RFC 5289 - TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5289 - TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5289 - TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 as defined in RFC 5289 - TLS_AES_128_GCM_SHA256 - TLS_AES_256_GCM_SHA384 ] and no other ciphersuites. The TSF shall verify that the presented identifier matches [the reference identifier per RFC 6125 section 6, IPv4 address in the CN or in the SAN] The TSF shall not establish a trusted channel if the server certificate is invalid [ - without any administrator override mechanism ]. - FCS_TLSC_EXT.1.4 The TSF shall [present the Supported Groups Extension with the following curves/groups: [secp256r1, secp384r1, secp521r1] and no other curves/groups] in the Client Hello. FCS_TLSC_EXT.1.5 The TSF shall [ - present the signature_algorithms extension with support for the following algorithms: [ - o rsa_pkcs1 with sha256(0x0401), - o rsa_pkcs1with sha384(0x0501), - o rsa_pkcs1 with sha512(0x0601), - o ecdsa_secp256r1 with sha256(0x0403), Page 28 of 54 Dell Technologies Inc. Security Target FCS_TLSC_EXT.1.6 ciphersuites as defined in FCS_TLSC_EXT.1.1. FCS_TLSC_EXT.1.7 FCS_TLSC_EXT.1.8 FCS_TLSC_EXT.1.9 ####### FCS_TLSC_EXT.2 FCS_TLSC_EXT.2.1 using X.509v3 certificates. - o ecdsa_secp384r1 with sha384(0x0503), o ecdsa_secp521r1 with sha512(0x0603), o rsa_pss_rsae with sha256(0x0804), o rsa_pss_rsae with sha384(0x0805), o rsa_pss_rsae with sha512(0x0806), o rsa_pss_pss with sha256(0x0809), o rsa_pss_pss with sha384(0x080a), o rsa_pss_pss with sha512(0x080b) o ] and no other algorithms; ]. The TSF [does not provide] the ability to configure the list of supported The TSF shall prohibit the use of the following extensions: · Early data extension · Post-handshake client authentication according to RFC 8446, Section 4.2.6. The TSF shall [not use PSKs]. The TSF shall [reject [TLS 1.2, TLS 1.3] renegotiation attempts]. TLS Client Support for Mutual Authentication The TSF shall support TLS communication with mutual authentication #### 5.3.3 Identification and Authentication (FIA) ####### FIA_AFL.1 Authentication Failure Handling FIA_AFL.1.1 The TSF shall detect when an Administrator configurable positive integer within [ 1-16 ] unsuccessful authentication attempts occur related to Administrators attempting to authenticate remotely using a password . FIA_AFL.1.2 When the defined number of unsuccessful authentication attempts has been met, the TSF shall [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]. ####### FIA_PMG_EXT.1 Password Management FIA_PMG_EXT.1.1 The TSF shall provide the following password management capabilities for administrative passwords: Page 29 of 54 Dell Technologies Inc. Security Target - a) Passwords shall be able to be composed of any combination of upper and lower case letters, numbers, and the following special characters: [ '!', '@', '#', '$', '%', '^', '&', '*', '(', ')' ]; - b) Minimum password length shall be configurable to between [ 9 ] and [ 32 ] characters. ####### FIA_UIA_EXT.1 User Identification and Authentication FIA_UIA_EXT.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; - [ no other actions ] - FIA_UIA_EXT.1.2 The TSF shall require each administrative user to be successfully identified and authenticated before allowing any other TSF-mediated actions on behalf of that administrative user. - FIA_UIA_EXT.1.3 The TSF shall provide the following remote authentication mechanisms [SSH password, SSH public key] and [no other mechanism]. The TSF shall provide the following local authentication mechanisms [passwordbased]. - FIA_UIA_EXT.1.4 The TSF shall authenticate any administrative user's claimed identity according to each authentication mechanism specified in FIA_UIA_EXT.1.3. Application note: This SFR modified by TD0900. ####### FIA_UAU.7 Protected Authentication Feedback (Refinement) administrative FIA_UAU.7.1 The TSF shall provide only obscured feedback to the user while the authentication is in progress at the local console . ####### FIA_X509_EXT.1/Rev X.509 Certificate Validation FIA_X509_EXT.1.1/Rev The TSF shall validate certificates in accordance with the following rules: - RFC 5280 certificate validation and certification path validation supporting a minimum path length of three certificates . - The certification path must terminate with a trusted CA certificate designated as a trust anchor. - The TSF shall validate a certification path by ensuring that all CA certificates in the certification path contain the basicConstraints extension with the CA flag set to TRUE. - The TSF shall validate the revocation status of the certificate using [a Certificate Revocation List (CRL) as specified in RFC 5280 Section 6.3] - The TSF shall validate the extendedKeyUsage field according to the following rules: Page 30 of 54 Dell Technologies Inc. Security Target - o Certificates used for trusted updates and executable code integrity verification shall have the Code Signing purpose (idkp 3 with OID 1.3.6.1.5.5.7.3.3) in the extendedKeyUsage field. - o Server certificates presented for DTLS/TLS shall have the Server Authentication purpose (id-kp 1 with OID 1.3.6.1.5.5.7.3.1) in the extendedKeyUsage field. - o Client certificates presented for DTLS/TLS shall have the Client Authentication purpose (id-kp 2 with OID 1.3.6.1.5.5.7.3.2) in the extendedKeyUsage field. - o OCSP certificates presented for OCSP responses shall have the OCSP Signing purpose (id-kp 9 with OID 1.3.6.1.5.5.7.3.9) in the extendedKeyUsage field. FIA_X509_EXT.1.2/Rev The TSF shall only treat a certificate as a CA certificate if the basicConstraints extension is present and the CA flag is set to TRUE. ####### FIA_X509_EXT.2 X.509 Certificate Authentication FIA_X509_EXT.2.1 The TSF shall use X.509v3 certificates as defined by RFC 5280 to support authentication for [TLS], and [no additional uses]. FIA_X509_EXT.2.2 When the TSF cannot establish a connection to determine the validity of a certificate, the TSF shall [accept the certificate]. ####### FIA_X509_EXT.3 X.509 Certificate Requests FIA_X509_EXT.3.1 The TSF shall generate a Certificate Request as specified by RFC 2986 and be able to provide the following information in the request: public key and [Common Name]. FIA_X509_EXT.3.2 The TSF shall validate the chain of certificates from the Root CA upon receiving the CA Certificate Response. #### 5.3.4 Security Management (FMT) ####### FMT_MOF.1/ManualUpdate Management of Security Functions Behaviour FMT_MOF.1.1/ManualUpdate The TSF shall restrict the ability to enable the functions to perform manual updates to Security Administrators . ####### FMT_MOF.1/Functions Management of Security Functions Behaviour FMT_MOF.1.1/Functions The TSF shall restrict the ability to [modify the behaviour of] the functions [transmission of audit data to an external IT entity] to Security Administrators . ####### FMT_MTD.1/CoreData Management of TSF Data FMT_MTD.1.1/CoreData The TSF shall restrict the ability to manage the TSF data to Security Administrators . Page 31 of 54 Dell Technologies Inc. Security Target ####### FMT_MTD.1/CryptoKeys Management of TSF data FMT_MTD.1.1/CryptoKeys The TSF shall restrict the ability to manage the cryptographic keys to Security Administrators . ####### FMT_SMF.1 Specification of Management Functions FMT_SMF.1.1 The TSF shall be capable of performing the following management functions: - 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; - [ - o Ability to modify the behaviour of the transmission of audit data to an external IT entity; - o Ability to manage the cryptographic keys; - o Ability to set the time which is used for time-stamps; - o Ability to manage the TOE's trust store and designate X509.v3 certificates as trust anchors; - o Ability to generate Certificate Signing Request (CSR) and process CA certificate response; - o Ability to administer the TOE locally; - o Ability to configure the local session inactivity time before session termination or locking; - o Ability to configure the authentication failure parameters for FIA_AFL.1; - o Ability to manage the trusted public keys database; - o Ability to manage the public key or certificate used to validate the digital update; - o No other capabilities]. Application note: This SFR modified by TD0880. ####### FMT_SMR.2 Restrictions on Security Roles FMT_SMR.2.1 The TSF shall maintain the roles: - Security Administrator . Page 32 of 54 Dell Technologies Inc. Security Target FMT_SMR.2.2 The TSF shall be able to associate users with roles. FMT_SMR.2.3 The TSF shall ensure that the conditions - The Security Administrator role shall be able to administer the TOE remotely are satisfied. #### 5.3.5 Protection of the TSF (FPT) ####### FPT_SKP_EXT.1 Protection of TSF Data (for reading of all symmetric keys) FPT_SKP_EXT.1.1 The TSF shall prevent reading of all pre-shared keys, symmetric keys, and private keys. ####### FPT_APW_EXT.1 Protection of Administrator Passwords FPT_APW_EXT.1.1 The TSF shall store administrative passwords in non-plaintext form. FPT_APW_EXT.1.2 The TSF shall prevent the reading of plaintext administrative passwords. ####### FPT_TST_EXT.1 TSF testing FPT_TST_EXT.1.1 The TSF shall run a suite of the following self-tests FPT_TST_EXT.1.2 Application note: - during initial start-up (on power on) to verify the integrity of the TOE firmware and software; - Prior to providing any cryptographic service and [at no other time] to verify correct operation of cryptographic implementation necessary to fulfil the TSF; - [no other] self-tests [ none ]. to demonstrate the correct operation of the TSF. The TSF shall respond to [all failures] by [[ halting the boot process or entering failure mode with error messages displayed on the console; administrator must reload a valid image ]]. This SFR modified by TD0836. ####### FPT_TUD_EXT.1 Trusted update | FPT_TUD_EXT.1.1 | The TSF shall provide Security Administrators the ability to query the currently executing version of the TOE firmware/software and [the most recently installed version of the TOE firmware/software]. | |-------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | FPT_TUD_EXT.1.2 | The TSF shall provide Security Administrators the ability to manually initiate updates to TOE firmware/software and [no other update mechanism]. | | FPT_TUD_EXT.1.3 | The TSF shall provide means to authenticate firmware/software updates to the TOE using a [digital signature] prior to installing those updates. | Page 33 of 54 Dell Technologies Inc. Security Target ####### FPT_STM_EXT.1 Reliable Time Stamps FPT_STM_EXT.1.1 The TSF shall be able to provide reliable time stamps for its own use. FPT_STM_EXT.1.2 The TSF shall [allow the Security Administrator to set the time]. #### 5.3.6 TOE Access (FTA) ####### FTA_SSL_EXT.1 TSF-initiated Session Locking FTA_SSL_EXT.1.1 The TSF shall, for local interactive sessions, [ - terminate the session] after a Security Administrator-specified time period of inactivity. ####### FTA_SSL.3 TSF-initiated Termination FTA_SSL.3.1 The TSF shall terminate a remote interactive session after a Security Administrator-configurable time interval of session inactivity . ####### FTA_SSL.4 User-initiated Termination FTA_SSL.4.1 The TSF shall allow user Administrator -initiated termination of the user's Administrator's own interactive session. ####### FTA_TAB.1 Default TOE Access Banners FTA_TAB.1.1 Before establishing an administrative user session the TSF shall display a Security Administrator-specified advisory notice and consent warning message regarding unauthorised use of the TOE. #### 5.3.7 Trusted path/channels (FTP) ####### FTP_ITC.1 ####### Inter-TSF trusted channel FTP_ITC.1.1 The TSF shall be capable of using [TLS] to provide a trusted communication channel between itself and another trusted IT product authorized IT entities supporting the following capabilities: audit server, [no other capabilities] that is logically distinct from other communication channels and provides assured identification of its end points and protection of the channel data from modification or disclosure and detection of modification of the channel data . FTP_ITC.1.2 The TSF shall permit [the TSF, the authorized IT entities] to initiate communication via the trusted channel. FTP_ITC.1.3 The TSF shall initiate communication via the trusted channel for [ audit server ]. ####### FTP_TRP.1/Admin Trusted Path Page 34 of 54 Dell Technologies Inc. Security Target | FTP_TRP.1.1/Admin | The TSF shall be capable of using [SSH] to provide a communication path between itself and authorized remote Administrators users that is logically distinct from other communication paths and provides assured identification of its end points and protection of the communicated data from disclosure and provides detection of modification of the channel data . | |---------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | FTP_TRP.1.2 /Admin | The TSF shall permit remote Administrators users to initiate communication via the trusted path. | | FTP_TRP.1.3 /Admin | The TSF shall require the use of the trusted path for initial Administrator authentication and all remote administration actions . | Page 35 of 54 Dell Technologies Inc. Security Target ### 5.4 Assurance Requirements - 16 The TOE security assurance requirements are summarized in Table 12. - 17 In accordance with section 7.1 of the NDcPP, the following refinement is made to ASE: - a) ASE_TSS.1.1C Refinement: The TOE summary specification shall describe how the TOE meets each SFR. In the case of entropy analysis, the TSS is used in conjunction with required supplementary information on Entropy. Table 12: Assurance Requirements | Assurance Class | Components | Description | |--------------------------------|--------------|-----------------------------------------------------| | Security Target (ASE) | ASE_CCL.1 | Conformance Claims | | Security Target (ASE) | ASE_ECD.1 | Extended Components Definition | | Security Target (ASE) | ASE_INT.1 | ST Introduction | | Security Target (ASE) | ASE_OBJ.1 | Security Objectives for the operational environment | | Security Target (ASE) | ASE_REQ.1 | Stated Security Requirements | | Security Target (ASE) | ASE_SPD.1 | Security Problem Definition | | Security Target (ASE) | ASE_TSS.1 | TOE Summary Specification | | Development (ADV) | ADV_FSP.1 | Basic Functional Specification | | Guidance Documents (AGD) | AGD_OPE.1 | Operational User Guidance | | Guidance Documents (AGD) | AGD_PRE.1 | Preparative User Guidance | | Life Cycle Support (ALC) | ALC_CMC.1 | Labelling of the TOE | | Life Cycle Support (ALC) | ALC_CMS.1 | TOE CM Coverage | | Tests (ATE) | ATE_IND.1 | Independent Testing - conformance | | Vulnerability Assessment (AVA) | AVA_VAN.1 | Vulnerability survey | Page 36 of 54 Dell Technologies Inc. Security Target ### 6 TOE Summary Specification - 18 The following describes how the TOE fulfils each SFR included in section 5.3. ### 6.1 Security Audit #### 6.1.1 FAU_GEN.1/FAU_GEN.2 - 19 The TOE generates the audit records specified at Table 11. - 20 The following information is logged because of the Security Administrator generating/importing or deleting cryptographic keys: - a) Generate SSH key-pair . Action and implicitly identified key because this is the only SSH host key (RSA). - b) Generate CSR. Action and key reference (certificate and key files names/path). - c) Import Certificate. Action and key reference (certificate common name (CN)). - d) Import CA Certificate. Action and unique reference (certificate common name (CN)). - 21 The TOE includes the user identity in audit events resulting from actions of identified users. #### 6.1.2 FAU_STG_EXT.1 - 22 The TOE is a standalone TOE that stores data locally. - 23 The Security Administrator can configure the TOE to send logs to a syslog server. Log events are sent in real-time via TLS 1.2, see section 6.2.10 for more details on the secure communication with the remote syslog. - 24 The TOE implements log rotation - all log types are rotated at 1GB and 5 copies/rotations of each type of log is stored. The TOE contains two relevant types of log files: - a) Audit Log. For user activity and configuration changes. - b) Event Log. For device events. - 25 The TOE stores all locally generated audit data in persistent log files on the TOE's filesystem. These log files are standard text-based log files, not in-memory buffers or database-backed storage, and they remain available across system reboots. - 26 The TOE maintains 5 rotated log files of 1GB each for each log type (Audit Log and Event Log). When the maximum number of rotated files is reached, the TOE performs log rotation by deleting the oldest log file, ensuring continuous availability of local audit storage. - 27 Only authorized administrators may view audit records and no capability to modify/configure the local audit records is provided. ### 6.2 Cryptographic Support #### 6.2.1 FCS_CKM.1 - 28 The TOE supports key generation for the following asymmetric schemes: Page 37 of 54 Dell Technologies Inc. Security Target - a) RSA 2048-bit, 3072-bit, and 4096-bit. Used in SSH server authentication and TLS client authentication/cipher suites supporting RSA. - b) ECC P-256, ECC P-384, ECC P-521. Used for SSH server authentication and TLS client authentication (ECDSA). #### 6.2.2 FCS_CKM.2 - 29 The TOE supports the following key establishment schemes: - a) Elliptic Curve Diffie-Hellman (ECDH). Used in SSH and TLS for ephemeral key agreement. The TOE uses NIST curves P-256, P-384, and P-521. - 30 Table 13 below identifies the scheme being used by each service. Table 13: Key Agreement Mapping | Scheme | SFR | Service | |----------|----------------------------------------------|---------------------------------------------------------------| | ECC | FCS_SSHS_EXT.1 FCS_TLSC_EXT.1 FCS_TLSC_EXT.2 | Administration Audit Server (including mutual-authentication) | #### 6.2.3 FCS_CKM.4 - 31 Table 15 shows the origin, storage location and destruction details for cryptographic keys. Unless otherwise stated, the keys are generated by the TOE. #### 6.2.4 FCS_COP.1/DataEncryption - 32 The TOE provides symmetric encryption and decryption capabilities using 128- and 256-bit AES in CTR, and GCM mode. AES is implemented in TLS and SSH. - 33 The relevant NIST CAVP certificate numbers are listed Table 4. #### 6.2.5 FCS_COP.1/SigGen - 34 The TOE provides cryptographic signature generation and verification services using: - a) RSA Signature Algorithm with key size of 2048, 3072-bit, and 4096-bit. - b) ECDSA Signature Algorithm with key size of 256, 384 and 521 bits. - 35 The RSA signature verification is used for the TLS and SSH protocols, and for update verification. - 36 The ECDSA signature verification is used in SSH protocols. - 37 The relevant NIST CAVP certificate numbers are listed in Table 4. #### 6.2.6 FCS_COP.1/Hash - 38 The TOE provides cryptographic hashing services using SHA-256, SHA-384, and SHA-512. - 39 SHA is implemented in the following parts of the TSF: - a) TLS and SSH. - b) Hashing of passwords in non-volatile storage. Page 38 of 54 Dell Technologies Inc. Security Target - c) Kernel image digital signature and file integrity checking. - d) Update verification. 3. 40 The relevant NIST CAVP certificate numbers are listed in Table 4. #### 6.2.7 FCS_COP.1/KeyedHash - 41 The TOE provides keyed-hashing message authentication services using HMACSHA2-256, and HMAC-SHA2-512. - 42 HMAC is implemented in TLS and SSH. - 43 The characteristics of the HMACs used in the TOE are given in Table 14. - 44 The relevant NIST CAVP certificate numbers are listed in Table 4. Table 14: HMAC Characteristics | Algorithm | Block Size | Key Size | Digest Size | |--------------|--------------|------------|---------------| | HMAC-SHA-256 | 512 bits | 256 bits | 256 bits | | HMAC-SHA-512 | 1024 bits | 512 bits | 512 bits | #### 6.2.8 FCS_RBG_EXT.1 - 45 The TOE contains a CTR_DRBG that is seeded with 256 bits of full entropy from the CPU Jitter Entropy Source implemented using the jitterentropy-library v3.4.1. The entropy source provides conditioned entropy output suitable for seeding the DRBG and supporting a security strength of 256 bits. - 46 Additional detail is provided in the proprietary Entropy Description. #### 6.2.9 FCS_SSH_EXT.1 and FCS_SSHS_EXT.1 - 47 The TOE implements SSH in compliance with RFCs 4251, 4252, 4253, 4254, 4344, 5647, 5656, 6668, 8308, 8332. - 48 The TOE supports password-based or public key authentication methods for users. (rsa-sha2-256, rsa-sha2-512, ecdsa-sha2-nistp256, ecdsa-sha2-nistp384, ecdsasha2-nistp521). Users are verified when attempting to authenticate via username and public key through the use of the authorized keys file, or by confirming the validity of the username and password presented. - 49 The TOE supports rsa-sha2-256, rsa-sha2-512, ecdsa-sha2-nistp256, ecdsa-sha2nistp384, ecdsa-sha2-nistp521 SSH server's host public key algorithms . - 50 The TOE examines the size of each received SSH packet. If the packet is greater than 256 KB, it is automatically dropped. - 51 The TOE utilises AES-CTR-128, AES-CTR-256, aes128-gcm@openssh.com, aes256-gcm@openssh.com for SSH encryption. - 52 The TOE provides data integrity for SSH connections via HMAC-SHA2-256 and HMAC-SHA2-512. - 53 The TOE supports ecdh-sha2-nistp256, ecdh-sha2-nistp384 and ecdh-sha2nistp521 for SSH key exchanges. - 54 The TOE implements the key derivation function (KDF) as specified in RFC 4253, Section 7.2 and RFC 5656 (section 4). Page 39 of 54 Dell Technologies Inc. Security Target The TOE will re-key SSH connections after 1 hour or an encryption key has been - 55 used to protect 1GB of data (whichever occurs first). #### 6.2.10 FCS_TLSC_EXT.1 and FCS_TLSC_EXT.2 - 56 The TOE operates as a TLS client when establishing the trusted channel to the audit server. The TOE supports mutual authentication by presenting an X.509 client certificate to the server during the TLS handshake. Only TLS 1.2 and TLS 1.3 are permitted for this connection. - 57 The cipher suites supported for TLS client connections are restricted to the following: - a) TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 - b) TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 - c) TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 - d) TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 - e) TLS_AES_128_GCM_SHA256 - f) TLS_AES_256_GCM_SHA384 - 58 Only the suites listed above are enabled; no other cipher suites are supported. Additionally, the TOE does not allow administrators to configure or modify the list of supported ciphersuites. The set of supported suites is fixed in the evaluated configuration. - 59 If certificate validation fails, the TOE does not establish the TLS channel, and no administrator override exists. All validation errors result in termination of the handshake. - 60 The TOE validates the server identity per RFC 6125 section 6. The reference identifier is established automatically based on the audit server configuration. The TOE prefers the Subject Alternative Name (DNS or IP-Address) when present and falls back to the Common Name (CN) field only if the SAN is absent. When the CN contains an IPv4 address, the TOE converts the text representation to binary form in network byte order and enforces canonical format per RFC 3986. IPv6 identifiers are not supported. Wildcard matching is not supported. - 61 The client presents the Supported Groups Extension in the Client Hello, advertising only the following curves and finite field groups: secp256r1, secp384r1, and secp521r1. This behavior is default and not configurable. If the server offers unsupported DHE parameters, the client terminates the handshake. - 62 The client includes the signature_algorithms in the Client Hello. These advertise only the following algorithms and no others: - a) rsa_pkcs1 with sha256(0x0401), - b) rsa_pkcs1with sha384(0x0501), - c) rsa_pkcs1 with sha512(0x0601), - d) ecdsa_secp256r1 with sha256(0x0403), - e) ecdsa_secp384r1 with sha384(0x0503), - f) ecdsa_secp521r1 with sha512(0x0603), - g) rsa_pss_rsae with sha256(0x0804), - h) rsa_pss_rsae with sha384(0x0805), - i) rsa_pss_rsae with sha512(0x0806), Page 40 of 54 Dell Technologies Inc. Security Target - j) rsa_pss_pss with sha256(0x0809), - k) rsa_pss_pss with sha384(0x080a), - l) rsa_pss_pss with sha512(0x080b) 4. 63 This set is fixed and cannot be modified by administrators. The TOE does not advertise deprecated algorithms. 5. 64 The TOE does not implement the signature_algorithms_cert extension in the ClientHello message. This behavior is default and not configurable. 6. 65 The TOE does not support or use pre-shared keys (PSKs) in any TLS connection. The evaluated configuration does not permit out-of-band PSK provisioning. 7. 66 The TOE rejects all TLS 1.2 renegotiation attempts. TLS 1.3 does not support renegotiation; any attempt to initiate renegotiation is rejected. 8. 67 The TOE does not support TLS 1.3 early data and does not perform post-handshake client authentication (RFC 8446 section 4.2.6) 9. 68 The TOE supports presentation of X.509v3 certificates to the TLS server for mutual authentication. Certificates are validated according to the configured trust anchor and revocation checking method. 10. 69 X.509v3 certificates are configured on a certification authority (CA) and installed on the TOE. After installing a certificate on the TOE, an administrator configures an X.509v3 Security Profile and adds the previously installed certificate to the Certificate field of the Security Profile. 11. 70 The TOE chooses which certificate to use during mutual authentication with a TLS server based on the Security Profile. The TOE implements client-certificate handling in accordance with RFC 5246 for TLS 1.2 and RFC 8446 for TLS 1.3. ### 6.3 Identification and Authentication #### 6.3.1 FIA_AFL.1 | 71 | The TOE is capable of tracking authentication failures of remote administrators (those using SSH) by using a counter for each remote user. | |------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | 72 | When a user account has sequentially failed authentication the configured number of times, the account will be locked for a Security Administrator defined time period. | | 73 | After the Security Administrator defined time period passes, account access is restored. | | 74 | The administrator can configure the maximum number of failed attempts between (1-16) using the CLI. | | 75 | The local console does not enforce the lockout mechanism when the TOE is configured and used according to the Dell Networking SmartFabric OS10 Common Criteria Guide. | #### 6.3.2 FIA_PMG_EXT.1 - 76 The TOE supports the local definition of users with corresponding passwords. The passwords can be composed of any combination of upper- and lower-case letters, numbers, and special characters '!', '@', '#', '$', '%', '^', '&', '*', '(', ')'. - 77 The minimum password length is settable by the Administrator. Minimum password length shall be configurable to between [9] and [32] characters. Page 41 of 54 Dell Technologies Inc. Security Target #### 6.3.3 FIA_UIA_EXT.1 - 78 The TOE requires all users to be successfully identified and authenticated. The TOE warning banner is displayed prior to authentication. - 79 No administrative actions are allowed before user identification and authentication. - 80 Access to the TOE is facilitated through the following interfaces: - a) Directly connecting to the TOE appliance (serial over RJ45) using a password based authentication. - b) Remotely connecting to each appliance via SSHv2 using a password or public key based authentication. - 81 Regardless of the interface at which the administrator interacts, the TOE prompts the user for a credential. Only after the administrative user presents the correct authentication credentials will they be granted access to the TOE administrative functionality. No TOE administrative access is permitted until an administrator is successfully identified and authenticated. - 82 The process for authentication is the same for administrative access whether administration is occurring via direct connection or remotely. At initial login, the administrative user is prompted to provide a username. After the user provides the username, the user is prompted to provide the administrative credential associated with the user account (e.g., password or SSH public/private key response). The TOE then either grants administrative access (if the combination of username and credential is correct) or indicates that the login was unsuccessful. The TOE does not provide a reason for failure in the cases of a login failure. #### 6.3.4 FIA_UAU.7 - 83 For all authentication at the local CLI the TOE provides no feedback when the administrative password is entered so that the password is obscured. #### 6.3.5 FIA_X509_EXT.1/Rev - 84 The TOE performs X.509 certificate validation at the following points: - a) TOE TLS client validation of server X.509 certificates. - b) When certificates are loaded into the TOE. - 85 In all scenarios, certificates are checked for several validation characteristics: - a) If the certificate 'notAfter' date is in the past or 'notBefore' is in the future , then this is an expired certificate which is considered invalid. - b) The certificate chain must terminate with a trusted CA certificate. - c) Server certificates consumed by the TOE TLS client must have a 'serverAuthentication' extendedKeyUsage purpose. 86 A trusted CA certificate is defined as any certificate loaded into the TOE trust store that has, at a minimum, a basicConstraints extension with the CA flag set to TRUE. The TOE also supports a 'trusted host' certificate which is a self -signed certificate that can be stored in the trust store. 87 The TOE chooses which TLS client certificate to use during mutual authentication with a TLS server based on the Security Profile. The TOE adheres to RFC 5246 for implementing client certificates in the TLS protocol to present to non-TOE IT entities. - 88 The TOE chooses and validates the server certificate received in response to a TLS client hello message sent by the TOE. Page 42 of 54 Dell Technologies Inc. Security Target - 89 Certificate revocation checking for the above scenarios is performed using a CRL. - 90 CRL-based revocation checking is performed for all certificates in the presented chain during TLS authentication and when certificates are loaded into the TOE. Revocation checking occurs at the time of authentication and is not deferred. - 91 As X.509 certificates are not used for trusted updates, firmware integrity self-tests or client authentication, the code-signing and clientAuthentication purpose is not checked in the extendedKeyUsage for related certificates. The TOE does not support OCSP; therefore, OCSP signing purpose in the extendedKeyUsage is not supported. - 92 The TOE has a trust store where root CA and intermediate CA certificates can be stored. The trust store is not cached: if a certificate is deleted, it is immediately untrusted. If a certificate is added to the trust store, it is immediately trusted for its given scope. - 93 The X.509 certificates for each of the given scenarios are validated using the certificate path validation algorithm defined in RFC 5280, which can be summarized as follows: - a) The public key algorithm and parameters are checked - b) The current date/time is checked against the validity period revocation status is checked - c) Issuer name of X matches the subject name of X+1 - d) Name constraints are checked - e) Policy OIDs are checked - f) Policy constraints are checked; issuers are ensured to have CA signing bits - g) Path length is checked - h) Critical extensions are processed #### 6.3.6 FIA_X509_EXT.2 | 94 | The TOE has a trust store where root CA and intermediate CA certificates can be stored. The trust store is not cached: if a certificate is deleted, it is immediately untrusted. If a certificate is added to the trust store, it is immediately trusted for its given scope. | |------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | 95 | The TOE selects its own client certificate for TLS mutual authentication based on the Security Profile configured by the administrator. | | 96 | Instructions for configuring the trusted IT entities to supply appropriate X.509 certificates are captured in the guidance documents. If a connection cannot be established during a CRL validity check, the TOE will use cached revocation information if available; otherwise, the certificate will be accepted. | | 97 | As part of the verification process, a CRL is used to determine whether the certificate is revoked or not. If the CRL cannot be obtained, then the TOE will use the last cached information available about certificate to reject the certificate. If the CRL cannot be obtained and the information is not available in the cache about the certificate, the TOE will accept the certificate. | | 98 | The behavior when CRL retrieval fails (use cached info or accept if no cache) is fixed and not configurable by the administrator. | Page 43 of 54 Dell Technologies Inc. Security Target #### 6.3.7 FIA_X509_EXT.3 99 For the Certificate Signing Request, a CN is required and may be an IP address or DNS name. SANs are optional and may be IP address, URI, DNS name or directory name. 100 The TOE generates CSRs in compliance with RFC 2986, including the public key and the Common Name (CN) as required by FIA_X509_EXT.3.1. Optional Subject Alternative Names (SANs) may also be included as described above. Upon receiving the CA Certificate Response, the TOE validates the entire certificate chain from the Root CA in accordance with RFC 5280, as required by FIA_X509_EXT.3.2. ### 6.4 Security Management #### 6.4.1 FMT_MOF.1/ManualUpdate 101 The TOE restricts the ability to perform software updates to Security Administrators. #### 6.4.2 FMT_MOF.1/Functions 102 The TOE restricts the ability to modify (enable/disable) transmission of audit records to an external audit server to Security Administrators. The administrator can then configure the TOE to send audit records to an external server. 103 This configuration is performed through the TOE's CLI by issuing the audit forward enable or audit forward disable commands (as documented in the administrative guidance). Only Security Administrators with the appropriate role can execute these commands. #### 6.4.3 FMT_MTD.1/CoreData 104 Users are required to login before being provided with access to any administrative functions. Management of the trust store is an administrative function, which is restricted to authenticated administrators. #### 6.4.4 FMT_MTD.1/CryptoKeys 105 The TOE administrator can generate and delete SSH, TLS, and X.509 keys. The TOE restricts the ability to manage SSH, TLS and any configured X.509 private keys to Security Administrators. 106 The TOE does not support modification or import of cryptographic keys; only generation and deletion are supported. #### 6.4.5 FMT_SMF.1 107 The TOE may be managed via the CLI (console & SSH). The specific management capabilities include: - a) Ability to administer the TOE locally and remotely - b) Ability to configure the access banner - c) Ability to modify the behaviour of the transmission of audit data to an external IT entity - d) Ability to configure the session inactivity time before session termination or locking - e) Ability to manage the cryptographic keys; Page 44 of 54 Dell Technologies Inc. Security Target - f) Ability to update the TOE and to verify the update using digital signature - g) Ability to configure the authentication failure parameters - h) Ability to manage the trusted public keys database - i) Ability to set the time which is used for timestamps - j) Ability to generate Certificate Signing Requests (CSR) and process CA certificate responses - k) Ability to manage the TOE's trust store and designate X509.v3 certificates as trust anchors. #### 6.4.6 FMT_SMR.2 | 108 | The TOE implements role-based access control based on pre-defined profiles that are assigned when creating a user. | |-------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | 109 | The TOE supports the following pre-defined administrative user profiles (collectively these can be considered the Security Administrator role): | | 110 | Network Operator (netoperator). This user role has no privilege to modify any configuration on the switch but can access Exec mode (monitoring) to view the current configuration and status information. | | 111 | Network Administrator (netadmin). This user role can configure, display, and debug the network operations on the switch. Netadmin can access all of the commands that are available from the network operator role. This role does not have access to the commands that are available to the system security administrator for cryptography operations, AAA, or the commands reserved solely for the system administrator. | | 112 | Security Administrator (secadmin). This user role can control the security policy across the systems that are within a domain or network topology. The security administrator commands include FIPS mode enablement, password policies, inactivity timeouts, banner establishment, and cryptographic key operations for secure access paths. | | 113 | System Administrator (sysadmin). This role has full access to all the commands in the system, exclusive access to commands that manipulate the file system formatting, and access to the system shell. This role can also create user IDs and define other user roles. | | 114 | Management of TSF data via the CLI is restricted to System Administrators and Security Administrators. | ### 6.5 Protection of the TSF #### 6.5.1 FPT_SKP_EXT.1 - 115 Keys are protected as described in Table 15. In all cases, plaintext keys cannot be viewed through an interface designed specifically for that purpose. Table 15: Keys | Key | Algorithm | Storage | Zeroization | |-----------------|-------------|-------------------|------------------------------------------------------------------------------------------------| | TLS Private Key | RSA, ECC | NVRAM - plaintext | Overwritten with zeroes by Security Administrator CLI command which invokes a proprietary API. | Page 45 of 54 Dell Technologies Inc. Security Target | Key | Algorithm | Storage | Zeroization | |------------------|-------------|-------------------|-------------------------------------------------------------------------------------------------------------------| | TLS Session Keys | TLS KDF | RAM - plaintext | Overwritten with zeroes upon termination of the session or reboot of the appliance | | SSH Private Key | RSA, ECC | NVRAM - plaintext | Overwritten with zeroes by Security Administrator CLI command which invokes a proprietary API. | | SSH Session Keys | SSH KDF | RAM - plaintext | The keys (including re-keyed keys) are overwritten with zeroes when no longer required or reboot of the appliance | #### 6.5.2 FPT_APW_EXT.1 - 116 Passwords are protected as describe in Table 16. In all cases plaintext passwords cannot be viewed through an interface designed specifically for that purpose. Table 16: Passwords | Key/Password | Generation/ Algorithm | Storage | Zeroization | |----------------------------------------|-------------------------|----------------------|----------------------------| | Locally stored administrator passwords | User generated | NVRAM - SHA-256 hash | Overwritten with new data. | #### 6.5.3 FPT_TST_EXT.1 - 117 The TOE performs diagnostic self-tests during start-up and generates audit records to record a failure. - 118 The TOE performs diagnostic power-up and conditional self-tests. Self-tests comply with the FIPS 140-2 requirements, as outlined below. - 119 Power-up self-tests are executed automatically when the module is loaded into memory. The power-up self-tests include the FIPS140-2 required Software Integrity Test and a set of Cryptographic Algorithms tests. The following Cryptographic Algorithm tests are implemented in the module: - AES in CTR, and GCM mode, encrypt and decrypt KATs - CTR DRBG KAT and SP800-90A health tests - HMAC SHA-2 (256, and 512) KATs - RSA encrypt and decrypt KATs - RSA sign and verify KATs - SHA-2 (256, 384, 512) KATs - Software integrity test using HMAC verification. - ECDSA Pairwise Consistency Test - 120 The module performs the following conditional self-tests: Page 46 of 54 Dell Technologies Inc. Security Target - A Continuous Random Number Generation (CRNG) test each time the toolkit produces random data, as per the FIPS 140-2 standard. The CRNG test is performed for the CTR DRBG and NDRNG (Entropy). - A repetition count test and adaptive proportion test for the NDRNG (Entropy), as defined in SP 800-90B. - A pair-wise consistency test each time the module generates an RSA or ECDSA public/private key pair. - 121 The TOE generates audit records to record a failure; the messages are displayed on the console and audit records generated for both successful and failed tests. Some low-level critical failure modes can prevent TOE start-up and as a result will not generate audit records. In such cases, the TOE appliance will enter failure mode displaying error codes, typically displayed on the console. The TOE can be configured to reboot or to stop with errors displayed when non-critical errors are encountered. Failure of any of the FIPS mode tests during boot process will stop start-up process and prompt the user to reload. - 122 The TOE implements a secure boot process which performs verification of the kernel image digital signature (RSA2048/SHA256) prior to booting the kernel (a failure results in the TOE halting at the boot loader). The kernel and TOE OS are subsequently booted, and a further hash file integrity test is performed on OS10 system binaries (a failure of file integrity results in Exec mode access only and upgrade to a valid image is required to proceed further). Secure boot must be enabled during configuration. - 123 By verifying the correct operation of the platform hardware components and ensuring the integrity of software components, the TOE self-tests are sufficient to demonstrate that the security functions are operating correctly. #### 6.5.4 FPT_TUD_EXT.1 | 124 | Upgrading the TOE is a multi-step process performed by a Security Administrator. An authorized user must authenticate to the secure Dell Support website where the software downloads are available. The downloaded image must be transferred to the appliance using a secure method such as Secure Copy or SFTP. | |-------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | 125 | Before performing a trusted update, the administrator must check whether Secure Boot is enabled. If Secure Boot is not enabled, it must be enabled using secure-boot enable to comply with the evaluated configuration and be able to use the ' image secure-install ' command. Some platforms have Secure Boot enabled by default and cannot disable it. | | 126 | To validate the software image before installing the image, use the ' image secure-install ' command. It verifies the signature of the image files using hash-based authentication. Upgraded image files are installed after they are successfully validated. This validation procedure prevents the installation of corrupted or modified images. | | 127 | GPG digital signatures can also be used to verify the updates using ' image secure-install ' command . If the command reports a bad signature, the image should not be used. Instead, download the file again and start over. | | 128 | The TOE also implements 'show version' CLI command that displays information about firmware version running on the TOE. The TOE also has 'show boot detail' which shows versions of both active image and standby image. The ' show boot detail ' command will immediately recognize and display the new version after it was downloaded, installed, and verified by the administrator. | - 129 The activation process involves the following: Page 47 of 54 Dell Technologies Inc. Security Target - a) The user to issue the 'boot system standby' command . - b) The user issues the 'reload' command. 3. 130 After the reboot, what used to be the standby version is now the active image, and what used to be the active image is now the standby. The user can activate the standby version in the same manner as outlined above. 4. 131 Note: After rebooting, the update becomes active only if the 'boot system standby' was issued before rebooting. If the 'reload' command is issued without the 'boot system standby', the system will reload the same image it was just running. #### 6.5.5 FPT_STM_EXT.1 132 The TOE incorporates an internal clock. The TOE uses an internal battery-backed hardware clock for reliability. The Security Administrator configures date and time settings during initial TOE configuration. 133 The TOE makes use of time for the following: - a) Audit record timestamps - b) Session timeouts (lockout enforcement) - c) Certificate validation ### 6.6 TOE Access #### 6.6.1 FTA_SSL_EXT.1 134 The Security Administrator may configure the TOE to terminate an inactive local interactive session (CLI) following a specified period. An administrator may terminate local and remote sessions by enabling re-authentication, which is disabled by default. The settings can be configured in INTERFACE mode, from 1 to 65535 seconds, default 30 seconds. #### 6.6.2 FTA_SSL.3 135 The Security Administrator may configure the TOE to terminate an inactive remote interactive session following a specified period. The settings can be configured in INTERFACE mode, from 1 to 65535 seconds, default 30 seconds. #### 6.6.3 FTA_SSL.4 136 Administrative users may terminate their own sessions at any time. The session can be terminated using ' exit ' command. #### 6.6.4 FTA_TAB.1 137 The TOE displays an administrator configurable message to users prior to login at the CLI and when logging in remotely. 138 Administrative access to the TOE is facilitated through the following interfaces: - a) Directly connecting to the TOE appliance (serial over RJ45) using a password. - b) Remotely connecting to each appliance via SSHv2 using a password or public key Page 48 of 54 Dell Technologies Inc. Security Target ### 6.7 Trusted Path/Channels #### 6.7.1 FTP_ITC.1 - 139 The TOE supports secure communication with the following IT entities: - a) Audit server via TLS. The TOE acts as a TLS client and is conformant to FCS_TLSC_EXT.1 and FCS_TLSC_EXT.2. #### 6.7.2 FTP_TRP.1/Admin - 140 The TOE provides the following trusted paths for remote administration: - a) CLI over SSH per FCS_SSHS_EXT.1. Page 49 of 54 Dell Technologies Inc. Security Target ### 7 Rationale ### 7.1 Conformance Claim Rationale - 141 The following rationale is presented with regard to the PP conformance claims: - a) TOE type. As identified in section 2.1, the TOE is network device, consistent with the NDcPP. - b) Security problem definition. As shown in section 3, the threats, OSPs and assumptions are reproduced directly from the NDcPP. - c) Security objectives. As shown in section 4, the security objectives are reproduced directly from the NDcPP. - d) Security requirements. As shown in section 5, the security requirements are reproduced directly from the NDcPP. No additional requirements have been specified. ### 7.2 Security Objectives Rationale - 142 All security objectives are drawn directly from the NDcPP. ### 7.3 Security Requirements Rationale - 143 All security requirements are drawn directly from the NDcPP. Table 17 presents a mapping between threats and SFRs as presented in the NDcPP. Table 17: NDcPP SFR Rationale | Identifier | SFR Rationale | |--------------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | T.UNAUTHORIZED_ADMINIS TRATOR_ACCESS | • The Administrator role is defined in FMT_SMR.2 and the relevant administration capabilities are defined in FMT_SMF.1 and FMT_MTD.1/CoreData, with optional additional capabilities in FMT_MOF.1/Services and FMT_MOF.1/Functions • The actions allowed before authentication of an Administrator are constrained by FIA_UIA_EXT.1, and include the advisory notice and consent warning message displayed according to FTA_TAB.1 • The requirement for the Administrator authentication process is described in FIA_UIA_EXT.1 • Locking of Administrator sessions is ensured by FTA_SSL_EXT.1 (for local sessions), FTA_SSL.3 (for remote sessions), and FTA_SSL.4 (for all interactive sessions) • The secure channel used for remote Administrator connections is specified in FTP_TRP.1/Admin • (Malicious actions carried out from an Administrator session are separately addressed by T.UNDETECTED_ACTIVITY) | Page 50 of 54 Dell Technologies Inc. Security Target | Identifier | SFR Rationale | |-------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | | • 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. | | T.WEAK_CRYPTOGRAPHY | • Requirements for key generation and key distribution are set in FCS_CKM.1 and FCS_CKM.2 respectively • Requirements for use of cryptographic schemes are set in FCS_COP.1/DataEncryption, FCS_COP.1/SigGen, FCS_COP.1/Hash, and FCS_COP.1/KeyedHash • Requirements for random bit generation to support key generation and secure protocols (see SFRs resulting from T.UNTRUSTED_COMMUNICATION_CHANNELS) are set in FCS_RBG_EXT.1 • Management of cryptographic functions is specified in FMT_SMF.1 | | T.UNTRUSTED_COMMUNI CATION_CHANNELS | • The general use of secure protocols for identified communication channels is described at the top level in FTP_ITC.1 and FTP_TRP.1/Admin; for distributed TOEs the requirements for inter-component communications are addressed by the requirements in FPT_ITT.1 • Requirements for the use of secure communication protocols are set for allowed protocols in FCS_DTLSC_EXT.1, FCS_DTLSC_EXT.2, FCS_DTLSS_EXT.1, FCS_DTLSS_EXT.2, FCS_HTTPS_EXT.1, FCS_IPSEC_EXT.1, FCS_TLSC_EXT.1, FCS_TLSC_EXT.2, FCS_TLSS_EXT.1, FCS_TLSS_EXT.2 • Optional and selection-based requirements for use of public key certificates to support secure protocols are defined in FIA_X509_EXT.1, FIA_X509_EXT.2, FIA_X509_EXT.3 | | T.WEAK_AUTHENTICATIO N_ENDPOINTS | • The use of appropriate secure protocols to provide authentication of endpoints (as in the SFRs addressing T.UNTRUSTED_COMMUNICATION_CHANNELS) are ensured by the requirements in FTP_ITC.1 and FTP_TRP.1/Admin; for distributed TOEs the authentication requirements for endpoints in inter-component communications are addressed by the requirements in FPT_ITT.1 • Additional possible special cases of secure authentication during registration of distributed TOE components are addressed by FCO_CPC_EXT.1 and FTP_TRP.1/Join. | Page 51 of 54 Dell Technologies Inc. Security Target | Identifier | SFR Rationale | |--------------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | T.UPDATE_COMPROMISE | • Requirements for protection of updates are set in FPT_TUD_EXT.1 • Additional optional use of certificate-based protection of signatures can be specified using FPT_TUD_EXT.2, supported by the X.509 certificate processing requirements in FIA_X509_EXT.1, FIA_X509_EXT.2 and FIA_X509_EXT.3 • Requirements for management of updates are defined in FMT_SMF.1 and (for manual updates) in FMT_MOF.1/ManualUpdate, with optional requirements for automatic updates in FMT_MOF.1/AutoUpdate | | T.UNDETECTED_ACTIVITY | • Requirements for basic auditing capabilities are specified in FAU_GEN.1 and FAU_GEN.2, with timestamps provided according to FPT_STM_EXT.1 and if applicable, protection of NTP channels in FCS_NTP_EXT.1 • Requirements for protecting audit records stored on the TOE are specified in FAU_STG.1 • Requirements for secure storage and transmission of local audit records to an external IT entity via a secure channel are specified in FAU_STG_EXT.1 and FAU_STG_EXT.1. • Optional additional requirements for dealing with potential loss of locally stored audit records are specified in FAU_STG_EXT.2, and FAU_STG_EXT.3 • If (optionally) configuration of the audit functionality is provided by the TOE then this is specified in FMT_SMF.1, and confining this functionality to Security Administrators is required by FMT_MOF.1/Functions. | | T.SECURITY_FUNCTIONAL ITY_COMPROMISE | • Protection of secret/private keys against compromise is specified in FPT_SKP_EXT.1 • Secure destruction of keys is specified in FCS_CKM.4 • If (optionally) management of keys is provided by the TOE then this is specified in FMT_SMF.1 and confining this functionality to Security Administrators is required by FMT_MTD.1/CryptoKeys • If optional local administration using a password-based authentication mechanism is provided by the TOE, FIA_UAU.7 provides protection of password entry by providing only obscured feedback at the local console. • If the TOE provides password-based authentication mechanisms, requirements for password lengths and available characters are set in FIA_PMG_EXT.1. Requirements for secure storage of passwords are set in FPT_APW_EXT.1 | Page 52 of 54 Dell Technologies Inc. Security Target | Identifier | SFR Rationale | |-----------------------------------|-------------------------------------------------------------------------------------------| | T.SECURITY_FUNCTIONAL ITY_FAILURE | • Requirements for running self-test(s) are defined in FPT_TST_EXT.1 | | P.ACCESS_BANNER | • An advisory notice and consent warning message is required to be displayed by FTA_TAB.1 | Page 53 of 54 Dell Technologies Inc. Security Target ## Annex A: Extended Components Definition 144 Refer to the Extended Components Definition of the claimed Protection Profile and Functional Package in Section 1.3 of this document. Page 54 of 54