Assurance Activity Report for Dell Networking Platforms
NDcPP v2.1 Assurance Activity Report for Dell Networking Platforms
Version 1.5 December 10, 2019
Produced by:
7925 Jones Branch Dr. #5200, McLean, VA 22102
Prepared for:
National Information Assurance Partnership Common Criteria Evaluation and Validation Scheme
Dell Networking Platforms Assurance Activity Report
The Developer of the TOE: Dell USA L.P.
The Security Target developed by: CygnaCom Solutions Inc. 7925 Jones Branch Dr. #5200, McLean, VA 22102
The TOE Evaluation sponsored by: Dell USA L.P. One Dell Way, Round Rock, TX 78682
2 of 91 Dell Networking Platforms Assurance Activity Report
Table of Contents
1 INTRODUCTION ...... 8 1.1 REFERENCES ...... 8 1.2 TARGET OF EVALUATION ...... 8 1.3 PLATFORM EQUIVALENCE ...... 9 1.4 TESTING TOPOLOGY ...... 12 2 SECURITY FUNCTIONAL REQUIREMENTS ...... 14 2.1 SECURITY AUDIT (FAU) ...... 14 2.1.1 FAU_GEN.1 Audit Data Generation and FAU_GEN.2 User Identity association ...... 14 2.1.1.1 TSS Assurance Activities ...... 14 2.1.1.2 Guidance Assurance Activities ...... 14 2.1.1.3 Testing Assurance Activities ...... 20 2.1.2 FAU_STG_EXT.1 Protected audit event Storage ...... 21 2.1.2.1 TSS Assurance Activities ...... 21 2.1.2.2 Guidance Assurance Activities ...... 22 2.1.2.3 Testing Assurance Activities ...... 23 2.2 CRYPTOGRAPHIC SUPPORT (FCS) ...... 25 2.2.1 FCS_CKM.1 Cryptographic Key Generation ...... 25 2.2.1.1 TSS Assurance Activities ...... 25 2.2.1.2 Guidance Assurance Activities ...... 25 2.2.1.3 Testing Assurance Activities ...... 25 2.2.2 FCS_CKM.2 Cryptographic Key Establishment ...... 27 2.2.2.1 TSS Assurance Activities ...... 27 2.2.2.2 Guidance Assurance Activities ...... 28 2.2.2.3 Testing Assurance Activities ...... 28 2.2.3 FCS_CKM.4 Cryptographic Key Destruction ...... 29 2.2.3.1 TSS Assurance Activities ...... 29 2.2.3.2 Guidance Assurance Activities ...... 31 2.2.3.3 Testing Assurance Activities ...... 31 2.2.4 FCS_COP.1/DataEncryption Cryptographic Operation (AES Data Encryption/Decryption) 31 2.2.4.1 TSS Assurance Activities ...... 31 2.2.4.2 Guidance Assurance Activities ...... 31 2.2.4.3 Testing Assurance Activities ...... 31 2.2.5 FCS_COP.1/SigGen Cryptographic Operation (Signature Generation and Verification ...32 2.2.5.1 TSS Assurance Activities ...... 32 2.2.5.2 Guidance Assurance Activities ...... 32 2.2.5.3 Testing Assurance Activities ...... 32 2.2.6 FCS_COP.1/Hash Cryptographic Operation (Hash Algorithm) ...... 32 2.2.6.1 TSS Assurance Activities ...... 32 2.2.6.2 Guidance Assurance Activities ...... 33 2.2.6.3 Testing Assurance Activities ...... 33 2.2.7 FCS_COP.1/KeyedHash Cryptographic Operation (Keyed Hash Algorithm) ...... 33 2.2.7.1 TSS Assurance Activities ...... 33 2.2.7.2 Guidance Assurance Activities ...... 33 2.2.7.3 Testing Assurance Activities ...... 33 2.2.8 FCS_RBG_EXT.1 Extended: Cryptographic Operation (Random Bit Generation) ...... 34 2.2.8.1 TSS Assurance Activities ...... 34 2.2.8.2 Guidance Assurance Activities ...... 34 2.2.8.3 Testing Assurance Activities ...... 34 2.3 FCS_SSHS_EXT.1 SSH SERVER ...... 35 2.3.1 FCS_SSHS_EXT.1.2 ...... 35 2.3.1.1 TSS Assurance Activities ...... 35 2.3.1.2 Guidance Assurance Activities ...... 35 2.3.1.3 Testing Assurance Activities ...... 35 2.3.2 FCS_SSHS_EXT.1.3 ...... 35
3 of 91 Dell Networking Platforms Assurance Activity Report
2.3.2.1 TSS Assurance Activities ...... 35 2.3.2.2 Guidance Assurance Activities ...... 36 2.3.2.3 Testing Assurance Activities ...... 36 2.3.3 FCS_SSHS_EXT.1.4 ...... 36 2.3.3.1 TSS Assurance Activities ...... 36 2.3.3.2 Guidance Assurance Activities ...... 36 2.3.3.3 Testing Assurance Activities ...... 37 2.3.4 FCS_SSHS_EXT.1.5 ...... 37 2.3.4.1 TSS Assurance Activities ...... 37 2.3.4.2 Guidance Assurance Activities ...... 38 2.3.4.3 Testing Assurance Activities ...... 38 2.3.5 FCS_SSHS_EXT.1.6 ...... 39 2.3.5.1 TSS Assurance Activities ...... 39 2.3.5.2 Guidance Assurance Activities ...... 39 2.3.5.3 Testing Assurance Activities ...... 39 2.3.6 FCS_SSHS_EXT.1.7 ...... 40 2.3.6.1 TSS Assurance Activities ...... 40 2.3.6.2 Guidance Assurance Activities ...... 40 2.3.6.3 Testing Assurance Activities ...... 40 2.3.7 FCS_SSHS_EXT.1.8 ...... 41 2.3.7.1 TSS Assurance Activities ...... 41 2.3.7.2 Guidance Assurance Activities ...... 41 2.3.7.3 Testing Assurance Activities ...... 41 2.4 FCS_TLSC_EXT.2 EXTENDED: TLS CLIENT PROTOCOL WITH AUTHENTICATION ...... 43 2.4.1 FCS_TLSC_EXT.2.1 ...... 43 2.4.1.1 TSS Assurance Activities ...... 43 2.4.1.2 Guidance Assurance Activities ...... 43 2.4.1.3 Testing Assurance Activities ...... 43 2.4.2 FCS_TLSC_EXT.2.2 ...... 46 2.4.2.1 TSS Assurance Activities ...... 46 2.4.2.2 Guidance Assurance Activities ...... 46 2.4.2.3 Testing Assurance Activities ...... 46 2.4.3 FCS_TLSC_EXT.2.3 ...... 49 2.4.3.1 TSS Assurance Activities ...... 49 2.4.3.2 Guidance Assurance Activities ...... 49 2.4.3.3 Testing Assurance Activities ...... 49 2.4.4 FCS_TLSC_EXT.2.4 ...... 50 2.4.4.1 TSS Assurance Activities ...... 50 2.4.4.2 Guidance Assurance Activities ...... 50 2.4.4.3 Testing Assurance Activities ...... 50 2.4.5 FCS_TLSC_EXT.2.5 ...... 50 2.4.5.1 TSS Assurance Activities ...... 50 2.4.5.2 Guidance Assurance Activities ...... 51 2.4.5.3 Testing Assurance Activities ...... 51 2.5 FCS_NTP_EXT.1 NTP PROTOCOL ...... 51 2.5.1 FCS_NTP_EXT.1.1 ...... 51 2.5.1.1 TSS Assurance Activities ...... 51 2.5.1.2 Guidance Assurance Activities ...... 52 2.5.1.3 Testing Assurance Activities ...... 52 2.5.2 FCS_NTP_EXT.1.2 ...... 52 2.5.2.1 TSS Assurance Activities ...... 52 2.5.2.2 Guidance Assurance Activities ...... 52 2.5.2.3 Testing Assurance Activities ...... 53 2.5.3 FCS_NTP_EXT.1.3 ...... 53 2.5.3.1 TSS Assurance Activities ...... 53 2.5.3.2 Guidance Assurance Activities ...... 53 2.5.3.3 Testing Assurance Activities ...... 54 2.5.4 FCS_NTP_EXT.1.4 ...... 54 2.5.4.1 TSS Assurance Activities ...... 54 2.5.4.2 Guidance Assurance Activities ...... 54
4 of 91 Dell Networking Platforms Assurance Activity Report
2.5.4.3 Testing Assurance Activities ...... 54 2.6 IDENTIFICATION AND AUTHENTICATION (FIA) ...... 54 2.6.1 FIA_AFL.1 Authentication Failure Management ...... 54 2.6.1.1 TSS Assurance Activities ...... 54 2.6.1.2 Guidance Assurance Activities ...... 55 2.6.1.3 Testing Assurance Activities ...... 56 2.6.2 FIA_PMG_EXT.1 Password Management ...... 56 2.6.2.1 TSS Assurance Activities ...... 56 2.6.2.2 Guidance Assurance Activities ...... 57 2.6.2.3 Testing Assurance Activities ...... 57 2.6.3 FIA_UIA_EXT.1 User Identification and Authentication ...... 58 2.6.3.1 TSS Assurance Activities ...... 58 2.6.3.2 Guidance Assurance Activities ...... 59 2.6.3.3 Testing Assurance Activities ...... 59 2.6.4 FIA_UAU_EXT.2 Password-based Authentication Mechanism ...... 60 2.6.5 FIA_UAU.7 Protected Authentication Feedback ...... 60 2.6.5.1 TSS Assurance Activities ...... 60 2.6.5.2 Guidance Assurance Activities ...... 60 2.6.5.3 Testing Assurance Activities ...... 60 2.6.6 FIA_X509_EXT.1/Rev X.509 Certificate Validation ...... 60 2.6.6.1 TSS Assurance Activities ...... 60 2.6.6.2 Guidance Assurance Activities ...... 61 2.6.6.3 Testing Assurance Activities ...... 61 2.6.7 FIA_X509_EXT.2 X.509 Certificate Authentication...... 64 2.6.7.1 TSS Assurance Activities ...... 64 2.6.7.2 Guidance Assurance Activities ...... 64 2.6.7.3 Testing Assurance Activities ...... 65 2.6.8 FIA_X509_EXT.3 Extended: X509 Certificate Requests ...... 65 2.6.8.1 TSS Assurance Activities ...... 65 2.6.8.2 Guidance Assurance Activities ...... 65 2.6.8.3 Testing Assurance Activities ...... 66 2.7 SECURITY MANAGEMENT (FMT) ...... 67 2.7.1 FMT_MOF.1/ManualUpdate ...... 67 2.7.1.1 TSS Assurance Activities ...... 67 2.7.1.2 Guidance Assurance Activities ...... 67 2.7.1.3 Testing Assurance Activities ...... 67 2.7.2 FMT_MTD.1/CoreData Management of TSF Data ...... 68 2.7.2.1 TSS Assurance Activities ...... 68 2.7.2.2 Guidance Assurance Activities ...... 68 2.7.2.3 Testing Assurance Activities ...... 69 2.7.3 FMT_MTD.1/CryptoKeys Management of TSF Data ...... 69 2.7.3.1 TSS Assurance Activities ...... 69 2.7.3.2 Guidance Assurance Activities ...... 70 2.7.3.3 Testing Assurance Activities ...... 70 2.7.4 FMT_SMF.1 Specification of Management Functions ...... 70 2.7.4.1 TSS Assurance Activities ...... 70 2.7.4.2 Guidance Assurance Activities ...... 70 2.7.4.3 Testing Assurance Activities ...... 71 2.7.5 FMT_SMR.2 Restrictions on security roles ...... 71 2.7.5.1 TSS Assurance Activities ...... 71 2.7.5.2 Guidance Assurance Activities ...... 71 2.7.5.3 Testing Assurance Activities ...... 71 2.8 PROTECTION OF THE TSF (FPT) ...... 72 2.8.1 FPT_SKP_EXT.1 Protection of TSF Data (for reading of all symmetric keys) ...... 72 2.8.1.1 TSS Assurance Activities ...... 72 2.8.1.2 Guidance Assurance Activities ...... 72 2.8.1.3 Testing Assurance Activities ...... 72 2.8.2 FPT_APW_EXT.1 Protection of Administrator Passwords ...... 72 2.8.2.1 TSS Assurance Activities ...... 72 2.8.2.2 Guidance Assurance Activities ...... 72
5 of 91 Dell Networking Platforms Assurance Activity Report
2.8.2.3 Testing Assurance Activities ...... 72 2.8.3 FPT_TST_EXT.1 TSF Testing ...... 73 2.8.3.1 TSS Assurance Activities ...... 73 2.8.3.2 Guidance Assurance Activities ...... 73 2.8.3.3 Testing Assurance Activities ...... 73 2.8.4 FPT_TUD_EXT.1 Trusted Update ...... 74 2.8.4.1 TSS Assurance Activities ...... 74 2.8.4.2 Guidance Assurance Activities ...... 75 2.8.4.3 Testing Assurance Activities ...... 76 2.8.5 FPT_STM_EXT.1 Reliable Time Stamps ...... 77 2.8.5.1 TSS Assurance Activities ...... 77 2.8.5.2 Guidance Assurance Activities ...... 78 2.8.5.3 Testing Assurance Activities ...... 78 2.9 TOE ACCESS (FTA) ...... 79 2.9.1 FTA_SSL_EXT.1 TSF-initiated Session Locking ...... 79 2.9.1.1 TSS Assurance Activities ...... 79 2.9.1.2 Guidance Assurance Activities ...... 79 2.9.1.3 Testing Assurance Activities ...... 79 2.9.2 FTA_SSL.3 TSF-initiated Termination ...... 80 2.9.2.1 TSS Assurance Activities ...... 80 2.9.2.2 Guidance Assurance Activities ...... 80 2.9.2.3 Testing Assurance Activities ...... 80 2.9.3 FTA_SSL.4 User-initiated Termination ...... 80 2.9.3.1 TSS Assurance Activities ...... 80 2.9.3.2 Guidance Assurance Activities ...... 80 2.9.3.3 Testing Assurance Activities ...... 81 2.9.4 FTA_TAB.1 Default TOE Access Banners ...... 81 2.9.4.1 TSS Assurance Activities ...... 81 2.9.4.2 Guidance Assurance Activities ...... 81 2.9.4.3 Testing Assurance Activities ...... 82 2.10 TRUSTED PATH/CHANNELS (FTP) ...... 83 2.10.1 FTP_ITC.1 Inter-TSF Trusted Channel ...... 83 2.10.1.1 TSS Assurance Activities ...... 83 2.10.1.2 Guidance Assurance Activities ...... 83 2.10.1.3 Testing Assurance Activities ...... 83 2.10.2 SFR: FTP_TRP.1/Admin Trusted Path ...... 84 2.10.2.1 TSS Assurance Activities ...... 84 2.10.2.2 Guidance Assurance Activities ...... 85 2.10.2.3 Testing Assurance Activities ...... 85 3 SECURITY ASSURANCE REQUIREMENTS ...... 86 3.1 ASE: SECURITY TARGET EVALUATION ...... 86 3.1.1 General ASE ...... 86 3.2 ADV: DEVELOPMENT ...... 86 3.2.1 ADV_FSP.1 Basic Functional Specification ...... 86 3.3 AGD: GUIDANCE DOCUMENTS ...... 87 3.3.1 AGD_OPE.1 Operational User Guidance ...... 87 3.3.2 AGD_PRE.1 Preparative Procedures ...... 89 3.4 ALC: LIFE-CYCLE SUPPORT ...... 90 3.4.1 ALC_CMC.1 Labelling of the TOE ...... 90 3.4.2 ALC_CMS.1 TOE CM coverage ...... 90 3.5 ATE: TESTS ...... 90 3.5.1 ATE_IND.1 Independent Testing - Conformance ...... 90 3.6 AVA: VULNERABILITY ASSESSMENT ...... 91 3.6.1 AVA_VAN.1 Vulnerability Survey ...... 91
Table of Figures
FIGURE 1: TESTING TOPOLOGY ...... 13
6 of 91 Dell Networking Platforms Assurance Activity Report
7 of 91 Dell Networking Platforms Assurance Activity Report
1 Introduction
This document summarizes the evaluation results of a specific Target of Evaluation (TOE), Dell Networking Platforms running Dell Networking OS v9.14.1.9 conforming to the Collaborative Protection Profile for Network Devices, Version 2.1, 24 September 2018, by listing the assurance activities and associated results as performed by the evaluators.
1.1 References
The following table provides information needed to identify and to control the Security Target (ST), the Target of Evaluation (TOE), and other evidence used in this evaluation. Table 1-1: Guidance and Reference Documents
Item Identifier Short Form Security Target Dell Networking Platforms Security Target v2.9 [ST] Protection Profile Collaborative Protection Profile for Network Devices, Version 2.1, [PP] 24 September 2018 Supporting Document Evaluation Activities for Network Device cPP Version 2.1, [SD] September 2018 User Guidance Configuration for Common Criteria Network Device Collaborative [CC Guide] Protection Profile (NDcPP) version 2.1 Dell Networking Platforms running Dell EMC Networking OS 9.14.1 Dell Command Line Reference Guide for the * System 9.14.1.0 [ADMIN1] Dell Configuration Guide for the * System 9.14.1.0 [ADMIN2] Test Report Test Report v0.6, December 10, 2019 [TEST] ETR Report Evaluation Technical Report For Dell Networking Switches Volume [ETR] 2: Evaluation of the TOE v0.6 Evaluation Technical Report for Dell Networking Switches Volume 1: Evaluation of the ST v0.3
1.2 Target of Evaluation
The TOE is the Dell Networking Platforms running Dell Networking OS v9.14.1.9, which consist of S- Series, C-Series, and Z-Series switches and includes the following appliances:
Dell Networking S-Series S3124 Dell Networking S-Series S3124P Dell Networking S-Series S3124F Dell Networking S-Series S3148 Dell Networking S-Series S3148P Dell Networking S-Series S3048-ON Dell Networking S-Series S4048-ON Dell Networking S-Series S4048T-ON Dell Networking S-Series S5048F-ON Dell Networking S-Series S6010-ON
8 of 91 Dell Networking Platforms Assurance Activity Report
Dell Networking S-Series S6100-ON Dell Networking C-Series C9010 and C1048P port extender Dell Networking Z-Series Z9100-ON
1.3 Platform Equivalence
Rationale for selection of platform for testing The TOE is a hardware network appliance. The underlying architecture of each TOE appliance consists of hardware that supports physical network connections, memory, processor, non-volatile storage and software that implements routing and switching functionality, device drivers, maintains the configuration for the appliance, the audit settings and other user information. While the hardware varies between the different appliance models, the software (Dell EMC Networking OS v9.14.1.9) is shared across all platforms. The software implements two distinct types of functionality – switching (or the data plane) and management (or the control plane). Only the control plane contains functionality that is relevant to this evaluation. The software responsible for implementing control plane is composed of subsystems designed to implement all of the claimed Security Functionality (SF). Validating the correct operation of the Security-relevant functions on all available hardware would provide complete assurance. However, most of the differences between the individual appliances are not security relevant for this evaluation. Therefore, it was determined that all platforms representing each supported CPU instruction set are equivalent and it is sufficient to test one appliance representing each CPU architecture: ARMv7 and IA- 32. See below for additional justification and explanation.
Hardware dependencies While different appliance models use different enclosures and have a different number and types of ports, power supplies, and so on, the functional differences are: the bridge to switching fabric microprocessor(s) network port layouts CPU architecture
Switching functionality and the operation of switching fabric microprocessors is exclusively a data plane functionality and is not security relevant for this evaluation.
The TOE appliances utilizes one of the following CPUs types: ARM Cortex A9 or Intel Atom C Series. The ARM Cortex A9 implements the ARMv7-A instruction set, and the Intel Atom C Series implements IA-32 instructions set. While specific sub-versions of these CPUs may vary in clock rate, cache size, FSB speed, the number and type of host adapters, and so on, these are not security-relevant distinctions. In simple terms, these differences determine how fast the binary code is shuffled, how much of it is accessed at the same time, and how the CPU’s scheduler prioritizes individual instructions in the pipeline. However, this does not change the results of executing compiled code and the logical code path stays the same. This is relevant distinction, as it means that the TOE’s common code base, by virtue of being deterministic code, will execute in the same way on all claimed platforms. The only relevant distinction is when completely different CPU architectures (i.e. ARM vs x86) are used the compiler would produce different binary code.
Difference in TOE binaries The TOE binaries (source code complied for the target architecture) implement all data plane and control plane functionality. The software is based on a common code base of a modular nature. The key difference between the binaries for the various appliance models is the target instruction set (i.e. CPU architecture) and the set of hardware-specific drivers for the switching fabric microprocessors. All of the TOE platforms implement a uniform control plane architecture. For the data plane, configuration code controls platform-specific features. While all modules and drivers are part of the binary code, only those modules applicable to the specific platform’s hardware are enabled on the specific appliance. Each
9 of 91 Dell Networking Platforms Assurance Activity Report instance of Dell EMC Networking OS v9.14.1.9 is produced from the same source code and compiled into a binary targeting a specific CPU architecture.
Difference in libraries There is no difference in the libraries between appliances. The TOE uses a consistent set of libraries and third-party software that is universally implemented across all platforms.
Difference in compiler The same version of the compiler and equivalent compiler flags are used to compile the source code targeting each platform. The compiler, gcc, supports all claimed CPU architectures. The production of machine binary code (compiled code) targeting a specific CPU architecture is abstracted from the developers who only maintain one set of source code.
Management interface The management interface is implemented as a Command Line Interface (CLI) available remotely over SSH and locally over console ports. The TOE offers a consistent set of predetermined CLI commands for all appliances. The only appliance-specific commands are related to data plane functionality, such as configuring PoE or data link layer protocols. That is, all CLI functionality that is relevant to this evaluation is identical across all appliances. Functional differences There are no SF-related functional differences between appliance models. The only difference is switching functionality – the number and type of ports, the switching fabric bandwidth, and an enclosure to support physical network ports.
SF differences There are no SF-related functional differences between appliances. The TOE implements the following Security Functionality: Security Audit Cryptographic Support Identification and Authentication Security Management Protection of the TOE Security Function (TSF) TOE Access Trusted Path/Channels
The TOE’s Security Functionality is associated with the following modules: CLI (Identification and Authentication, Security Management, TOE Access, Trusted Path/Channels) Management Interface (Security Audit, Security Management) Operating System (Protection of TSF) Cryptographic Library (Cryptographic Support, Trusted Path/Channels)
All of these modules are part of the Control Plane and are consistent across all evaluated appliances. Each SF is implemented by Dell EMC Networking OS v9.14.1.9 that is based on consistent source code combined with a known set of libraries and compiled for target architecture.
Cryptographic Module The Dell Networking Platforms relies exclusively on the Dell OpenSSL Cryptographic Library Version 2.4 operating in FIPS mode to implement all cryptographic security functionality. Both platforms (Intel and ARM) have a full set of CAVP certificates (table 1-2: Dell networking platforms cryptography) covering all relevant cryptographic primitives.
10 of 91 Dell Networking Platforms Assurance Activity Report
Table 1-2: Dell Networking Platforms Cryptography Requirement Requirement Component Dell Networking Platforms Implementation Certificate # Class FCS: FCS_CKM.1 Cryptographic Generating 2048-bit and 3072-bit RSA keypairs RSA # C213 Cryptographic Key Generation validated conforming to FIPS186-4. Support FCS_CKM.2 RSA-based key establishment that meet NIST SHS # C213 Cryptographic Key Special Publication 800-56B, Vendor Affirmation DRBG # Establishment according to FIPS 140-2 I.G. D.4 C213 RSA # C213 Hashing using SHA-1, SHA-256, SHA-512 validated conforming to FIPS 180-3, Secure Hash Standard (SHS).
CTR_DRBG (AES-256) random bit generation validated conforming to NIST SP PUB 800-90.
2048-bit and 3072-bit RSA keypairs validated conforming to FIPS186-4. Finite field-based key establishment schemes CVL # C213 that meet NIST Special Publication 800-56A
FCS_CKM.4 Cryptographic Destruction of all keys is performed by single direct n/a Key Destruction overwrite followed by a read-verify action. FCS_COP.1/DataEncryption AES encryption and decryption used in CBC mode AES # C213 Cryptographic Operation with 128-bit, 192-bit, and 256-bit key sizes validated (AES Data conforming to FIPS PUB 197. Encryption/Decryption) FCS_COP.1/SigGen RSA signature generation and verification according RSA # C213 Cryptographic Operation to RSASSA-PKCS1v1_5 with 2048-bit and 3072-bit (Signature Generation and key sizes utilizing SHA-1 (protocol only), SHA-256, Verification) SHA-512.
RSA signature generation and verification according to RSASSA-PSS with 2048-bit and 3072-bit key sizes SHA-1 (protocol only), SHA-256, SHA-512 and salt. FCS_COP.1/Hash Hashing using SHA-1, SHA-256, SHA-512 validated SHS # C213 Cryptographic Operation conforming to FIPS 180-3, Secure Hash Standard (Hash Algorithm) (SHS). FCS_COP.1/KeyedHash Keyed hash HMAC-SHA1, HMAC-SHA256, HMAC # Cryptographic Operation validated conforming to FIPS 198, Keyed-Hash C213 (Keyed Hash Algorithm) Message Authentication Code (HMAC).
Supported cryptographic key sizes: 160, 256 bits and message digest sizes: 160, 256 bits.
Keyed hash use matches validated hash algorithms implemented by the module. FCS_RBG_EXT.1 CTR_DRBG (AES-256) random bit generation DRBG # validated conforming to NIST SP PUB 800-90. C213
11 of 91 Dell Networking Platforms Assurance Activity Report
Cryptographic Operation (Random Bit Generation) FCS_SSHS_EXT.1 TOE implements SSHv2 protocol and supports CVL# 1047 SSH Server Protocol password-based authentication with following ciphers:
AES-CBC-128, AES-CBC-256 for data encryption SSH_RSA, RSA-SHA2-256, RSA-SHA2- 512 for public-key authentication HMAC-SHA1, HMAC-SHA1-96, HMAC- SHA2-256 for data integrity diffie-hellman-group14-sha1 for key exchange
SSH KDF conformant to SP 800-135 FCS_TLSC_EXT.2 TOE implements TLS 1.2 and supports certificate- CVL# 1047 TLS Client Protocol based authentication with the following ciphers:
TLS_RSA_WITH_AES_128_CBC_SHA TLS_RSA_WITH_AES_256_CBC_SHA TLS_RSA_WITH_AES_128_CBC_SHA256 TLS_RSA_WITH_AES_256_CBC_ SHA256 TLS_DHE_RSA_WITH_AES_128_CBC_SHA TLS_DHE_RSA_WITH_AES_256_CBC_SHA TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
TLS KDF conformant to SP 800-135
The [CC Guide] is a comprehensive configuration guide that is applicable to all of the appliances identified in section 1.2. This document contains explanations of security-relevant features and details how to securely configure each appliance identified in section 1.2. This guide was closely followed during product testing and was found to be an accurate and useful source of information about the TOE.
Tested Platforms Testing was conducted using the S5048F-ON (CPU Intel Atom C) and S3124 (CPU ARM Cortex A9).
1.4 Testing topology
The test topology is shown and described in Figure 1: Testing Topology. Both the TOE and its test network / LAN were located in the Common Criteria lab, at 1000 Innovation drive, Kanata, Ontario, Canada, with all OE Servers and the TOE connected to an isolated 'Test' LAN that was dedicated to this project. This LAN is physically isolated via a core switch dedicated to in-lab testing and logically separated by a dedicated VLAN, preventing general access while still granting testers direct access to the TOE. The setup consists of a ‘Test’ LAN – 192.168.0.x/24 IPv4 network with all servers assigned static IPv4 addresses within that class. OE servers were installed in Virtual Machines (VMs) running on a VMware VSphere v6.7 server and included: Audit Server and CA/OCSP servers. Packet capture was performed using a dedicated laptop connected to a SPAN (traffic mirroring) port on the core switch.
12 of 91 Dell Networking Platforms Assurance Activity Report
Figure 1: Testing Topology
13 of 91 Dell Networking Platforms Assurance Activity Report
2 Security Functional Requirements
2.1 Security Audit (FAU)
2.1.1 FAU_GEN.1 Audit Data Generation and FAU_GEN.2 User Identity association
2.1.1.1 TSS Assurance Activities
TSS Assurance Activities: (1) For the administrative task of generating/import of, changing, or deleting of cryptographic keys as defined in FAU_GEN.1.1c, the TSS should identify what information is logged to identify the relevant key. TSS Implementation Details/Results: (1) The evaluator examined ST, Section 6.1 and noted it identifies the following cryptographic protocols and uses: SSH Server, TLS Client. SSH Server is used to secure CLI administrative access with RSA keys, keys used for this purpose are identified with “RSA key generated for SSH”. Mutually- authenticated TLS client is used to secure connection to an external audit server, as part of this functionality X509 CA and endpoint certificates that contain RSA keys are used. These keys are always associated with X509 certificates, with CA certificate identified in the audit records by CN, and TOE’s client certificate is identified as “host certificate”. This is described in further detail in the ST Section 7.1.
2.1.1.2 Guidance Assurance Activities
Guidance Assurance Activities: (1) The evaluator shall check the guidance documentation and ensure that it provides an example of each auditable event required by FAU_GEN.1 (i.e. at least one instance of each auditable event – comprising the mandatory, optional and selection-based SFR sections as applicable – shall be provided from the actual audit record). (2) The evaluator shall also make a determination of the administrative actions related to TSF data related to configuration changes. (3) The evaluator shall examine the guidance documentation and make a determination of which administrative commands, including subcommands, scripts, and configuration files, are related to the configuration (including enabling or disabling) of the mechanisms implemented in the TOE that are necessary to enforce the requirements specified in the cPP. The evaluator shall document the methodology or approach taken while determining which actions in the administrative guide are related to TSF data related to configuration changes. (4) The evaluator may perform this activity as part of the activities associated with ensuring that the corresponding guidance documentation satisfies the requirements related to it.
Note: TD0410 (https://www.niap-ccevs.org/Documents_and_Guidance/view_td.cfm?td_id=410) was applied
14 of 91 Dell Networking Platforms Assurance Activity Report
Guidance Implementation Details/Results: (1) The evaluator checked the CC Guide, Appendix D- Auditable Events and noted a list of all mandatory auditable events along with a number of examples. The guidance also explains audit record format and provides a brief description of each field.
Audit records, when stored and displayed by the TOE, follow the following format:
Timestamp | HostName | Type of the event | ProcID | MSGID | Strucured-Data | MSG |
For example, here is how successful login of ‘sysadmin’ administrator is recorded:
Oct 6 16:33:43: dv-fedgov-s4810-4: %SEC-6-LOGIN_SUCCESS:Login successful for user netad on line vty0 ( 10.11.8.67 ))
The evaluator verified that every audit event type mandated by the cPP is described and that the description of the fields contains all the necessary information. The CC Guide, Appendix D, Auditable Events (p.74 – p.84) list all relevant audit records. See the mapping table below for details.
Additional Audit Requirement Auditable Events Guidance Location Record Contents FAU_GEN.1 Start-up and shut down if the audit None CC Guide, Appendix D, functions Auditable Events, p.76 - 77 FAU_GEN.2 None None n/a FAU_STG_EXT.1 None None n/a FCS_CKM.1 None None n/a FCS_CKM.2 None None n/a FCS_CKM.4 None None n/a FCS_COP.1/DataEncryption None None n/a FCS_COP.1/SigGen None None n/a FCS_COP.1/Hash None None n/a FCS_COP.1/KeyedHash None None n/a
FCS_RBG_EXT.1 None None n/a FCS_NTP_EXT.1 Configuration of a new time server Identity if new/removed time CC Guide, Appendix F, Removal of configured time server server NTP FIA_AFL.1 Unsuccessful login attempts limit is Origin of the attempt (e.g., CC Guide, Appendix D, met or exceeded. IP address). Auditable Events p.77 FCS_SSHS_EXT.1 Failure to establish an SSH session Reason for failure CC Guide, Appendix D, Auditable Events p.84 FCS_TLSC_EXT.2 Failure to establish a TLS Session Reason for failure CC Guide, Appendix D, Auditable Events p.84 FIA_PMG_EXT.1 None None n/a FIA_UIA_EXT.1 All use of identification and Provided user identity, CC Guide, Appendix D, authentication mechanism. origin of the attempt (e.g., Auditable Events, p.77 IP address) FIA_UAU_EXT.2 All use of identification and Origin of the attempt (e.g., CC Guide, Appendix D, authentication mechanism. IP address). Auditable Events, p.77 FIA_UAU.7 None None n/a FIA_X509_EXT.1/Rev Unsuccessful attempt to validate a Reason for failure of CC Guide, Appendix D, certificate certificate validation Auditable Events, p.77 - 78
15 of 91 Dell Networking Platforms Assurance Activity Report
Any addition, replacement or Identification of certificates removal of trust anchors in the added, replaced or removed TOE's trust store as trust anchor in the TOE's trust store FIA_X509_EXT.2 None None n/a FIA_X509_EXT.3 None None n/a FMT_MOF.1/ManualUpdate Any attempt to initiate a manual None CC Guide, Appendix D, update Auditable Events, p.78 FMT_MTD.1/CoreData None None n/a FMT_MTD.1/CryptoKeys None None n/a FMT_SMF.1 All management activities of TSF None CC Guide, Appendix D, data. Auditable Events, p.82 FMT_SMR.2 None None n/a FPT_SKP_EXT.1 None None n/a FPT_APW_EXT.1 None None n/a FPT_TST_EXT.1 None None n/a FPT_TUD_EXT.1 Initiation of update None CC Guide, Appendix D, Auditable Events, p.83 result of the update attempt (success or failure) FPT_STM_EXT.1 Discontinuous changes to time - For discontinuous changes CC Guide, Appendix D, either Administrator actuated or to time: The old and new Auditable Events, p.83 changed via an automated process. values for the time. Origin of the attempt to change time for success and failure (e.g., IP address). FTA_SSL_EXT.1 The termination of a local session by None CC Guide, Appendix D, (if “terminate the session” is the session locking mechanism. Auditable Events p.84 selected) FTA_SSL.3 The termination of a remote session None CC Guide, Appendix D, by the session locking mechanism. Auditable Events p.84. FTA_SSL.4 The termination of an interactive None CC Guide, Appendix D, session. Auditable Events p.84 FTA_TAB.1 None None n/a FTP_ITC.1 Initiation of the trusted channel. Identification of the initiator CC Guide, Appendix D, and target of failed trusted Auditable Events p.84 Termination of the trusted channel. channels establishment Failure of the trusted channel attempt. functions. FTP_TRP.1/Admin Initiation of the trusted path. None CC Guide, Appendix D, Auditable Events p.84 Termination of the trusted path. Failure of the trusted path functions.
(2) The evaluator determined that the administrative actions that are relevant in the context of the cPP are defined by FMT_SMF.1 and the administrative actions necessary to put the TOE into evaluated configuration.
(3) The evaluator examined the CC Guide, Appendix D and made the determination that administrative commands meet the requirements outlines in the cPP. The evaluator determined that configuration of the TOE into the evaluated configuration generates appropriate level of audit records. See the following table for details.
16 of 91 Dell Networking Platforms Assurance Activity Report
Access Administrative Command executed Mapping to Guidance Privilege Actions Administrator Start-up and shut- The local console always displays current audit events Section 5 – Setting Up the down of audit when the TOE is powered on. Common Criteria functions Configuration, Configuring However, to enable logging of audit records the logging Logging p.38 extended command must be issued. This command generates appropriate audit record. See example below: Dell#show logging auditlog May 12 12:20:25: Dell#: %CLI-6-logging extended by admin from vty0 (10.14.1.98) Administrator Shut-down of audit The audit functions operate at all times. However, it is Appendix D, Audit log functions possible to manually shut it down by issuing no logging Records p.75 extended (and take the TOE out of evaluated configuration). The event generates the following audit record: Jul 23 14:25:02: S3124: %CLI-6-no logging extended by ccadmin from console
Administrator Configure RBAC To enable RBAC mode both AAA Authentication and Section 5 – Setting Up the mode Authorization must be configured: Common Criteria Configuration, Configure (conf)#aaa authentication login default local AAA Authentication and (conf)#aaa authorization exec default local Authorization, p.36 (conf)#aaa authorization role-only Appendix A – Role -Based Access Control, p.52 Administrator Configure password To configure password policy: Section 5 -Setting Up the complexity Common Criteria (conf)# password-attributes min-length 15 Configuration, P.32 (conf)# password-attributes character- restriction lower 1 (conf)# password-attributes character- restriction upper 1 (conf)# password-attributes character- restriction numeric 1 (conf)# password-attributes character- restriction special-char 1 Administrator TLS configuration When operating in FIPS mode, the system is restricted to B Appendix B — X.509v3, only the TLS 1.2 protocol version and support the following p. 62 cipher suites in line with the NIST SP800-131A Rev 2 policy document Administrator SSH configuration When FIPS mode is enabled, the system uses SSHv2. Section 5 -Setting Up the (conf)# ip ssh server enable Common Criteria Configuration, p.34 Administrator FIPS mode To enable FIPS mode, issue the following command: Section 5 -Setting Up the Common Criteria (conf)#fips mode enable Configuration, Configuring Security, Enabling FIPS Mode, p.28 Administrator Audit server To configure audit server (syslog), mutual trust based on Appendix D, Audit log configuration X509v3 certificates must be issued to the TOE and the Records p.75 remote audit server. The command to enable logging to a remote syslog server is as follows: (conf)#logging
17 of 91 Dell Networking Platforms Assurance Activity Report
Administrator Audit levels The TOE supports multiple audit levels. In the evaluated Section 5 -Setting Up the configurations configuration, the logging level must be set at 7. Common Criteria Configuration, Configuring The command is as follows: Logging, p.39 (conf)#logging monitor 7 Administrator X.509 certificate The TOE implements mutually authenticated secure management channel based on TLS protocol. The following relevant X509 functionality can be managed by the TOE
administrator:
Install/Trust Certificate Authority (CA) The TOE is capable of adding CAs individually or concatenated in order from the lowest to the Root CA (i.e. certificate chain).
To install a trusted CA certificate(s), enter the following command:
#crypto ca-cert install {path to .pem file} Appendix D, Audit log Delete/Remove Trust Certificate Authority (CA) Records p.77, To remove trusted CA certificate(s), enter the following command: Appendix D, Audit log Records p.80, #crypto ca-cert delete {index}
Generate Keys and Certificate Signing Request (CSR) To generate key pair and a Certificate Signing Request (CSR), enter the following command: Section 5- Creating #crypto cert generate request {file name} Certificate Signing Requests (CSR), p.48 Install Host Certificate To install signed TOE’s identity certificate (also host certificate or signed CSR), enter the following command: Appendix D, Audit log #crypto cert install {path to .pem file} Records p.80
Administrator Verifying and To upgrade or downgrade the Dell Networking OS to the applying updates certified release:
1. Verify the Dell Networking OS version running on the switch, use the show version command in EXEC Privilege mode. This command displays the current Dell Networking OS version information on the system.
2. Validate the software image on the USB flash drive (after the image has been transferred to the system using do copy command, but before the image has
been installed), use the verify command in EXEC Privilege mode. This command calculates a hash value of the image file and the output must be manually compared to the published hash. 3. Upgrade Dell Networking OS using the following command: Appendix D, Audit log upgrade system flash://
Administrator Configuring system To set the time and date for the switch hardware clock, use Section 5 - Setting Up the time the following command: Common Criteria Configuration, Configuring #calendar set time month day year the System Date and Time p.43 Administrator Configuring and To configure the banner use the following command: Section 5 - Setting Up the modifying access Common Criteria (conf)#banner login C
18 of 91 Dell Networking Platforms Assurance Activity Report
Administrator Termination of To configure the login lockout period, use Section 5 - Setting Up the interactive remote Common Criteria (conf)#password-attributes max-retry number session Configuration, Configuring lockout-period minutes Password Attributes, configuring the Login Lockout period, p.33 Administrator Generating/import of Command for enabling RSA Authentication: Section 5 – Configuring cryptographic keys security, Generate SSH (conf)#ip ssh rsa-authentication enable Server RSA Host Keys, Command for generating SSH-RSA host key: p.29
(conf)#crypto key generate rsa Section 5 – Configuring Command for displaying SSH authorized keys for logged-in Security, Enabling RSA user: Authentication, p.31 #show ip ssh rsa-authentication my- authorized-keys
Administrator Changing of This is done automatically by the TOE when new keys are n/a cryptographic keys generated or loaded. Administrator Deletion of Deleting the system (host) certificate and private key : Appendix B — X.509v3, cryptographic keys #crypto cert delete p.62 to p.70 Deleting all trusted CA certificates: #crypto ca-cert delete all Deleting specific trusted CA certificates: #crypto ca-cert delete {index}
Administrator Administrative login When a system is configured using the factory default Section 5 - Setting Up the configuration, there is only one userid created on the Common Criteria system. Configuration, Create UserIDs on TOE, p.36 This is the “admin” userid; it has no user role associated with it by default. You must create any additional userids you may want with associated user roles. To create a userid on the TOE, use the following command: (conf)# username ccadmin sha-256 password role sysadmin Administrator User Password User passwords cannot be “reset” only regenerated as new Section 3 - Configuring a Reset password by authorized administrator. Username and Password Administrator On-demand self- The TOE includes a suite of FIPS self-tests that validate the Appendix E – FIPS Self- tests integrity of the Dell OpenSSL Cryptographic Library and tests, p.87 verify the implementation of the FIPS DRBG and the cryptographic algorithms. Self-test passed: 00:00:11: %STKUNIT0-M:CP %CRYPTO-5- FIPS_SELF_TEST_PASSED: [sysd] FIPS crypto module self-test passed Self-test failure: 00:00:11: %STKUNIT0-M:CP %CRYPTO-5- FIPS_SELF_TEST_FAILED: [sysd] FIPS crypto module self-test failed
(4) The CC Guide document was closely followed during product testing and it was determined that all administrative commands used during testing were adequately described.
19 of 91 Dell Networking Platforms Assurance Activity Report
2.1.1.3 Testing Assurance Activities
Testing Assurance Activities: (1) The evaluator shall test the TOE’s ability to correctly generate audit records by having the TOE generate audit records for the events listed in the table of audit events and administrative actions listed above. This should include all instances of an event: for instance, if there are several different I&A mechanisms for a system, the FIA_UIA_EXT.1 events must be generated for each mechanism. (2) The evaluator shall test that audit records are generated for the establishment and termination of a channel for each of the cryptographic protocols contained in the ST. If HTTPS is implemented, the test demonstrating the establishment and termination of a TLS session can be combined with the test for an HTTPS session. (3) When verifying the test results, the evaluator shall ensure the audit records generated during testing match the format specified in the guidance documentation, and that the fields in each audit record have the proper entries. Note that the testing here can be accomplished in conjunction with the testing of the security mechanisms directly. Testing Implementation Details/Results: (1) The evaluation team confirmed throughout testing activities that appropriate audit records were generated, and that each audit record contained appropriate and accurate information. See the following table detailing SFR- mandated audit records mapped to a specific test case within the Test Report where it was generated. SFR Auditable Events Test Case FAU_GEN.1 Start-up and shut-down of the audit functions. PP-8A FCS_NTP_EXT.1 Configuration of a new time server PP-2 Removal of configured time server PP-18 FIA_AFL.1 Unsuccessful login attempts limit is met or exceeded. PP-15 FCS_SSHS_EXT.1 Failure to establish an SSH session PP-14[A-I] FCS_TLSC_EXT.2 Failure to establish a TLS Session PP-17[A-P] FIA_UIA_EXT.1 All use of identification and authentication mechanism. PP-14[A-B], PEN-3 FIA_UAU_EXT.2 All use of identification and authentication mechanism. PP-14[A-B], PEN-3 FIA_X509_EXT.1/Rev Unsuccessful attempt to validate a certificate PP-10[A-J] Any addition, replacement or removal of trust anchors in the TOE’s trust store FMT_MOF.1/ManualUpdate Any attempt to initiate a manual update. PP-1B FMT_SMF.1 All management activities of TSF data. PP-1[A-C]; PP-[2-5]; PP-[7-8A]; PP-9[A-B]; PP-10A; PP-12; PP-13 PP-14A; PP-14H; PP-15 FPT_TUD_EXT.1 Initiation of update IT-1.2 Result of the update attempt (success or failure) PP-1[A-B] FPT_STM_EXT.1 Discontinuous changes to time PP-2 FTA_SSL_EXT.1 The termination of a local session by the session locking mechanism. PP-4 FTA_SSL.3 The termination of a remote session by the session locking mechanism. PP-4 FTA_SSL.4 The termination of an interactive session. PP-4
20 of 91 Dell Networking Platforms Assurance Activity Report
FTP_ITC.1 Initiation of the trusted channel. Termination of the trusted channel. PP-8B Failure of the trusted channel functions. PP-9 PP-14A, PP-14I PP-15 PP-17A FTP_TRP.1/Admin Initiation of the trusted path. PP-14A, Termination of the trusted path. PP-14B Failure of the trusted path functions. Administrative actions Administrative login and logout (name of user account shall be logged if individual See: NDcPP Dell OS user accounts are required for Administrators). 9.14.1.9 Audit Events Changes to TSF data related to configuration changes (in addition to the Report. information that a change occurred it shall be logged what has been changed). Generating/import of, changing, or deleting of cryptographic keys (in addition to the action itself a unique key name or key reference shall be logged). Resetting passwords (name of related user account shall be logged).
(2) The evaluator confirmed that the audit records are generated during establishment and termination of a secure channel for the following claimed protocol(s): TLS, SSH. HTTPS is not implemented.
(3) During testing, the evaluator confirmed that audit records follow expected audit record format as described in the CC Guide, Appendix D – Auditable Events, ‘Log Record Format’.
2.1.2 FAU_STG_EXT.1 Protected audit event Storage
2.1.2.1 TSS Assurance Activities
TSS Assurance Activities: (1) The evaluator shall examine the TSS to ensure it describes the means by which the audit data are transferred to the external audit server, and how the trusted channel is provided. (2) The evaluator shall examine the TSS to ensure it describes the amount of audit data that are stored locally; what happens when the local audit data store is full; and how these records are protected against unauthorized access. (3) The evaluator shall examine the TSS to ensure it describes whether the TOE is a standalone TOE that stores audit data locally or a distributed TOE that stores audit data locally on each TOE component or a distributed TOE that contains TOE components that cannot store audit data locally on themselves but need to transfer audit data to other TOE components that can store audit data locally. The evaluator shall examine the TSS to ensure that for distributed TOEs it contains a list of TOE components that store audit data locally. The evaluator shall examine the TSS to ensure that for distributed TOEs that contain components which do not store audit data locally but transmit their generated audit data to other components it contains a mapping between the transmitting and storing TOE components. (4) The evaluator shall examine the TSS to ensure that it details the behaviour of the TOE when the storage space for audit data is full. When the option ‘overwrite previous audit record’ is selected this description should include an outline of the rule for overwriting audit data. If ‘other actions’ are chosen such as sending the new audit data to an external IT entity, then the related behaviour of the TOE shall also be detailed in the TSS. (5) The evaluator shall examine the TSS to ensure that it details whether the transmission of audit information to an external IT entity can be done in real-time or periodically. In case the TOE does not perform transmission in real-time the evaluator needs to verify that the TSS provides details about
21 of 91 Dell Networking Platforms Assurance Activity Report
what event stimulates the transmission to be made as well as the possible as well as acceptable frequency for the transfer of audit data. TSS Implementation Details/Results: (1) The ST, Section 7.1 explains that audit records are transferred in real-time mode to the external audit server using the TLS protocol. (2) The ST, Section 7.1 explains that the TOE is designed to store up to 512 audit records. When the TOE’s local audit storage becomes full, by default the oldest audit records are overwritten. Only authorized administrators can monitor this default behavior through the management interface that enforces access-control and action logging at all times thus preventing unauthorized access. There is no direct access to the local audit storage. (3) The ST, Section 7.5 describes the TOE as a standalone appliance designed to function independently. In addition, the section 7.1, states that “Up to 512 audit records can be stored locally on the appliance, or all logs can be sent to an external audit server.”
(4) The ST, Section 7.1 describes that the following actions are possible when the TOE’s local storage for audit data is full: Overwrite Oldest Audit Records This behavior is the default behavior according to the ST. (5) The ST, Section 7.1 describes that the TOE uploads audit records in syslog (RFC 5424) format as they are generated without any delay.
2.1.2.2 Guidance Assurance Activities
Guidance Assurance Activities: (1) The evaluator shall also examine the guidance documentation to ensure it describes how to establish the trusted channel to the audit server, as well as describe any requirements on the audit server (particular audit server protocol, version of the protocol required, etc.), as well as configuration of the TOE needed to communicate with the audit server. (2) The evaluator shall also examine the guidance documentation to determine that it describes the relationship between the local audit data and the audit data that are sent to the audit log server. For example, when an audit event is generated, is it simultaneously sent to the external server and the local store, or is the local store used as a buffer and “cleared” periodically by sending the data to the audit server. (3) The evaluator shall also ensure that the guidance documentation describes all possible configuration options for FAU_STG_EXT.1.3 and the resulting behaviour of the TOE for each possible configuration. The description of possible configuration options and resulting behaviour shall correspond to those described in the TSS. Guidance Implementation Details/Results: (1) The CC Guide, Section 5, Setting Up the Common Criteria Configuration, Configuring SYSLOG Servers, pages 42-43, describes how to establish a trusted channel to the audit server using TLS protocol. The guidance also describes requirements as “conform to the requirements in RFC 5424 including the support of TLS version 1.2 for transport.” (2) The CC Guide, Section 5, Setting Up the Common Criteria Configuration, Configuring SYSLOG Servers, page 42 describes how audit data is synchronized with the external audit server. The guidance states that when an audit event is generated, it is simultaneously sent to the external server and the local store. (3) The CC Guide, Section 5, Setting Up the Common Criteria Configuration, Configuring Logging Buffer Size, describes TOE behavior when the TOE’s local audit storage is full. The internal buffer is circular and once it fills up, it stores new log messages by overwriting the oldest message first. Because the buffer is circular, it is not possible for the system to exhaust the buffer space.
22 of 91 Dell Networking Platforms Assurance Activity Report
2.1.2.3 Testing Assurance Activities
Testing Assurance Activities: Testing of the trusted channel mechanism for audit will be performed as specified in the associated assurance activities for the particular trusted channel mechanism. The evaluator shall perform the following additional test for this requirement: Test 1: (1) The evaluator shall establish a session between the TOE and the audit server according to the configuration guidance provided. (2) The evaluator shall then examine the traffic that passes between the audit server and the TOE during several activities of the evaluator’s choice designed to generate audit data to be transferred to the audit server. The evaluator shall observe that these data are not able to be viewed in the clear during this transfer, and that they are successfully received by the audit server. (3) The evaluator shall record the particular software (name, version) used on the audit server during testing. (4) The evaluator shall verify that the TOE is capable of transferring audit data to an external audit server automatically without administrator intervention. Test 2: (1) The evaluator shall perform operations that generate audit data and verify that this data is stored locally. (2) The evaluator shall perform operations that generate audit data until the local storage space is exceeded and verifies that the TOE complies with the behaviour defined in FAU_STG_EXT.1.3. Depending on the configuration this means that the evaluator has to check the content of the audit data when the audit data is just filled to the maximum and then verifies that 1) The audit data remains unchanged with every new auditable event that should be tracked but that the audit data is recorded again after the local storage for audit data is cleared (for the option ‘drop new audit data’ in FAU_STG_EXT.1.3). 2) The existing audit data is overwritten with every new auditable event that should be tracked according to the specified rule (for the option ‘overwrite previous audit records’ in FAU_STG_EXT.1.3) 3) The TOE behaves as specified (for the option ‘other action’ in FAU_STG_EXT.1.3). Testing Implementation Details/Results: The evaluator followed the procedures outlined in the guidance to configure TOE audit functionality. Test 1: (1) The evaluator followed the CC Guide, Section 5, Setting up the Common Criteria Configuration, Configuring SYSLOG Servers to establish a secure session between the TOE and the audit server. (2) The evaluator examined network traffic, observed a successful TLS protocol handshake followed by encrypted traffic, and concluded that a secure channel was successfully established between the TOE and the remote audit server. During this period, the evaluator observed audit records updated on the remote audit server and concluded that these audit records were sent as part of encrypted traffic. See test case PP-7 for details. (3) The evaluator used Wireshark software and a mirroring port on a core switch to view and capture relevant network traffic exchange between the TOE and the remote audit server running syslog-ng.
23 of 91 Dell Networking Platforms Assurance Activity Report
(4) Upon finishing setting up the syslog server on the operational environment and issuing the CLI logging command on the TOE, the evaluator instantly started seeing audit events messages showing up on the audit server event’s log file. Test 2: (1) The evaluator used a script to repeatedly open administrative sessions using incorrect login credentials in order to fill the local audit log with records of failed login attempts. Prior to running the script, the evaluator issued a command to clear the local audit log. (2) The evaluator took note of the timestamp for the “clear log” audit log entry and observed its deletion when the local log filled with approximately 500 records. This observation confirmed that the oldest audit record was deleted first, which is consistent to how it is described in the ST. See test case PP-8C for details.
24 of 91 Dell Networking Platforms Assurance Activity Report
2.2 Cryptographic Support (FCS)
2.2.1 FCS_CKM.1 Cryptographic Key Generation
2.2.1.1 TSS Assurance Activities
TSS Assurance Activities: 1. The evaluator shall ensure that the TSS identifies the key sizes supported by the TOE. 2. If the ST specifies more than one scheme, the evaluator shall examine the TSS to verify that it identifies the usage for each scheme. TSS Implementation Details/Results: The TOE performs cryptographic key generation via the OpenSSL Cryptographic Library Version 2.4, which was tested according to the Cryptographic Algorithm Validation Program (CAVP) and was awarded a certificate covering RSA-based key establishment.
The ST, Section 6.1.2.1 (FCS_CKM.1) states that the TOE generates asymmetric cryptographic keys in accordance with a specific cryptographic key generation algorithm:
RSA schemes using cryptographic key sizes of 2048-bit or greater that meet the following: FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Appendix B.3 FFC Schemes using Diffie-Hellman group 14 that meet the following: RFC 3526, Section 3
(1) The Evaluator checked the TSS section 7.2, and confirmed that the table 15, section for FCS_CKM.1, identifies the RSA key sizes supported by the TOE. (2) As well, the evaluator confirmed that the TSS stated that the TOE uses standard 2048-bit MODP group that described in RFC 3526, Section 3.
2.2.1.2 Guidance Assurance Activities
Guidance Assurance Activities: The evaluator shall verify that the AGD guidance instructs the administrator how to configure the TOE to use the selected key generation scheme(s) and key size(s) for all cryptographic protocols defined in the Security Target. Guidance Implementation Details/Results: The CC Guide, Section 5, Setting Up Common Criteria Configuration, Generate SSH Server RSA Host Keys, page 29 instructs the administrator how to configure the TOE to use RSA keys with a cryptographic key size of 2048 bits.
2.2.1.3 Testing Assurance Activities
Testing Assurance Activities: Note: The following tests require the developer to provide access to a test platform that provides the evaluator with tools that are typically not found on factory products. Generation of long-term cryptographic keys (i.e. keys that are not ephemeral keys/session keys) might be performed automatically (e.g. during initial start-up). Testing of key generation must cover not only administrator invoked key generation but also automated key generation (if supported).
25 of 91 Dell Networking Platforms Assurance Activity Report
1. Key Generation for FIPS PUB 186-4 RSA Schemes The evaluator shall verify the implementation of RSA Key Generation by the TOE using the Key Generation test. This test verifies the ability of the TSF to correctly produce values for the key components including the public verification exponent e, the private prime factors p and q, the public modulus n and the calculation of the private signature exponent d. Key Pair generation specifies 5 ways (or methods) to generate the primes p and q. These include: a) Random Primes: Provable primes Probable primes b) Primes with Conditions: Primes p1, p2, q1,q2, p and q shall all be provable primes Primes p1, p2, q1, and q2 shall be provable primes and p and q shall be probable primes Primes p1, p2, q1,q2, p and q shall all be probable primes
To test the key generation method for the Random Provable primes method and for all the Primes with Conditions methods, the evaluator must seed the TSF key generation routine with sufficient data to deterministically generate the RSA key pair. This includes the random seed(s), the public exponent of the RSA key, and the desired key length. For each key length supported, the evaluator shall have the TSF generate 25 key pairs. The evaluator shall verify the correctness of the TSF’s implementation by comparing values generated by the TSF with those generated from a known good implementation. 2. Diffie-Hellman Group 14 Testing for FFC Schemes using Diffie-Hellman group 14 is done as part of testing in CKM.2.1. Testing Implementation Details/Results:
1. The TOE performs cryptographic RSA-Based key generation via the OpenSSL Cryptographic Library Version 2.4, which was tested according to the Cryptographic Algorithm Validation Program (CAVP) and was awarded the certificate number C213 covering RSA-based key generation test.
2. See section 2.2.2.3.
26 of 91 Dell Networking Platforms Assurance Activity Report
2.2.2 FCS_CKM.2 Cryptographic Key Establishment
2.2.2.1 TSS Assurance Activities
TSS Assurance Activities: The evaluator shall ensure that the supported key establishment schemes correspond to the key generation schemes identified in FCS_CKM.1.1. If the ST specifies more than one scheme, the evaluator shall examine the TSS to verify that it identifies the usage for each scheme. It is sufficient to provide the scheme, SFR, and service in the TSS. If Diffie-Hellman group 14 is selected from FCS_CKM.2.1, the TSS shall claim the TOE meets RFC 3526 Section 3. The intent of this activity is to be able to identify the scheme being used by each service. This would mean, for example, one way to document scheme usage could be:
Scheme SFR Service RSA FCS_TLSS_EXT.1 Administration ECDH FCS_SSHC_EXT.1 Audit Server Diffie- FCS_SSHC_EXT.1 Backup Server Hellman (Group 14) ECDH FCS_IPSEC_EXT.1 Authentication Server
Note: TD0449 https://www.niap-ccevs.org/Documents_and_Guidance/view_td.cfm?TD=0449 was applied. Note: TD0448 https://www.niap-ccevs.org/Documents_and_Guidance/view_td.cfm?TD=0448 was applied.
TSS Implementation Details/Results: The evaluator looked at the ST section 6.1.2.2, FCS_CKM.2, and confirmed that it correspond to the selected Key generation scheme, in the ST section 6.1.2.1, FCS_CKM.1. The TOE implements the following RFC-compliant protocols: SSH, TLS supporting RSA-based (RSA CAVP #C213) key derivation. The ST, Section 6.1.2.2 (FCS_CKM.2) states that the TOE performs cryptographic key establishment in accordance with a specific cryptographic key establishment method: • RSA-based key establishment schemes that meet the following: RSAES-PKCS1-v1_5 as specified in Section 7.2 of RFC 8017, “Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1”; • Key establishment scheme using Diffie-Hellman group 14 that meets the following: RFC 3526, Section 3
As the ST specifies more than one scheme, the evaluator checked the TSS section 7.2, and verified that it identifies the usage of each scheme, in the statement that says “The TOE follows recommendations outlined in the RSAES-PKCS1-v1_5 as specified in Section 7.2 of RFC 8017, “Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1 requirements as part of RSA-based key establishment. However, to support RFC-compliant secure channel protocols the TOE implements NIST SP 800-135 TLS and SSH key derivation functions (KDF). TOE acts as a sender of secret keying material for RSA key establishment. The TOE uses standard 2048-bit MODP group that is described in RFC 3526 Section 3. Diffie-Hellman group 14 is used as part of SSH and TLS implementations.”
The key derivation is validated by SP 800-135 KDF (CVL #1047)
27 of 91 Dell Networking Platforms Assurance Activity Report
2.2.2.2 Guidance Assurance Activities
Guidance Assurance Activities: The evaluator shall verify that the AGD guidance instructs the administrator how to configure the TOE to use the selected key establishment scheme(s). Guidance Assurance Activities Details/Results: The key derivation schema supported by the TOE is not directly configurable by the administrator; instead, it is tied to FIPS mode. The CC Guide, Section 5, Setting Up the Common Criteria Configuration, Verifying the SSHv2 Server Configuration, page 30 describes this in the following way: “After you have enabled FIPS mode, there is only one key exchange method allowed: diffie-hellman-group14-sha1”. The CC Guide, Appendix B, Transport layer security (TLS) page 69, states, “As the encryption algorithms are restricted to match the FIPS mode correctly, TLS version 1.2 does not require configuration. In FIPS mode, the ciphers are: DHE RSA key exchange with aes128-cbc RSA key exchange with aes128-cbc DHE RSA key exchange with aes256-cbc RSA key exchange with aes256-cbc As the HMAC algorithms are restricted to match the FIPS mode correctly, TLS version 1.2 does not require configuration. SHA-1 and SHA–256 cipher is used in FIPS mode.”
2.2.2.3 Testing Assurance Activities
Testing Assurance Activities: Key Establishment Schemes The evaluator shall verify the implementation of the key establishment schemes of the supported by the TOE using the applicable tests below. 1. SP800-56B Key Establishment Schemes The evaluator shall verify the correctness of the TSF’s implementation of RSAES-PKCS1-v1_5 by using a known good implementation for each protocol selected in FTP_TRP.1/Admin, FTP_TRP.1/Join, FTP_ITC.1 and FPT_ITT.1 that uses RSAES-PKCS1-v1_5.
2. Diffie-Hellman Group 14 The evaluator shall verify the correctness of the TSF’s implementation of Diffie-Hellman group 14 by using a known good implementation for each protocol selected in FTP_TRP.1/Admin, FTP_TRP.1/Join, FTP_ITC.1 and FPT_ITT.1 that uses Diffie-Hellman group 14.
Note: TD0402 (https://www.niap-ccevs.org/Documents_and_Guidance/view_td.cfm?td_id=412) was applied Testing Assurance Activities Details/Results:
1. The TSF’s implementation of RSAES-PKCS1-v1_5 was verified by the test activities for FTP_ITC.1. Evaluator checked the ST, and found that it lists the relevant SFRs: FTP_ITC.1 with TLS as the only selection. This selection corresponds to FCS_TLSC_EXT.2. To verify correctness of implementation of RSAES-PKCS1-v1_5, the evaluator used a known good implementation to confirm interoperability. In case of testing TLS client, a TLS connection to a CentOS 7 running syslog-ng v3.9.1 (that relies on OpenSSL v1.0.2k) server was established. The evaluator considers CentOS 7 (based on RHEL 7, a CC and FIPS certified) to be a known good implementations and considers a successful session establishment to be evidence of correct RSAES-PKCS1-v1_5 implementation.
2. The correctness of the TSF’s implementation of Diffie-Hellman group 14 was verified by the test activities for FTP_TRP.1/Admin. Evaluator checked the ST, and found that it is listing the relevant
28 of 91 Dell Networking Platforms Assurance Activity Report
SFRs: FTP_TRP.1/Admin with SSH as the only selection. This selection corresponds to FCS_SSHS_EXT.1. To verify correctness of the implementation of Diffie-Hellman group 14, the evaluator used known good implementation to confirm interoperability. Where the SSH service on the TOE is configured to only use Diffie-Hellman group 14, a CLI over SSH session from CentOS 7 running OpenSSH v7.4p1 was successfully established with the TOE. The evaluator considers CentOS 7 (based on RHEL 7, a CC and FIPS certified) to be a known good implementation and considers a successful session establishment to be evidence of correct TOE’s implementation of Diffie- Hellman group 14.
2.2.3 FCS_CKM.4 Cryptographic Key Destruction
2.2.3.1 TSS Assurance Activities
TSS Assurance Activities: (1) The evaluator examines the TSS to ensure it lists all relevant keys (describing the origin and storage location of each), all relevant key destruction situations (e.g. factory reset or device wipe function, disconnection of trusted channels, key change as part of a secure channel protocol), and the destruction method used in each case. For the purpose of this Evaluation Activity the relevant keys are those keys that are relied upon to support any of the SFRs in the Security Target. (2) The evaluator confirms that the description of keys and storage locations is consistent with the functions carried out by the TOE (e.g. that all keys for the TOE-specific secure channels and protocols, or that support FPT_APW.EXT.1 and FPT_SKP_EXT.1, are accounted for). In particular, if a TOE claims not to store plaintext keys in non-volatile memory then the evaluator checks that this is consistent with the operation of the TOE. (3) The evaluator shall check to ensure the TSS identifies how the TOE destroys keys stored as plaintext in non-volatile memory, and that the description includes identification and description of the interfaces that the TOE uses to destroy keys (e.g., file system APIs, key store APIs). Note that where selections involve ‘destruction of reference’ (for volatile memory) or ‘invocation of an interface’ (for non-volatile memory) then the relevant interface definition is examined by the evaluator to ensure that the interface supports the selection(s) and description in the TSS. In the case of non-volatile memory the evaluator includes in their examination the relevant interface description for each media type on which plaintext keys are stored. The presence of OS-level and storage device-level swap and cache files is not examined in the current version of the Evaluation Activity. (4) Where the TSS identifies keys that are stored in a non-plaintext form, the evaluator shall check that the TSS identifies the encryption method and the key-encrypting-key used, and that the key-encrypting-key is either itself stored in an encrypted form or that it is destroyed by a method included under FCS_CKM.4. (5) The evaluator shall check that the TSS identifies any configurations or circumstances that may not conform to the key destruction requirement (see further discussion in the Guidance Documentation section below). Note that reference may be made to the Guidance Documentation for description of the detail of such cases where destruction may be prevented or delayed. (6) Where the ST specifies the use of “a value that does not contain any CSP” to overwrite keys, the evaluator examines the TSS to ensure that it describes how that pattern is obtained and used, and that this justifies the claim that the pattern does not contain any CSPs. TSS Implementation Details/Results: (1) The ST, Section 7.2, Table 16 contains a list of all relevant keys, all relevant keys destruction situations and the destruction method used in each case. Below is Table 16. Table 2-1: Dell Networking Platforms CSPs Identifier Name Generation / Purpose Storage Zeroization Summary Algorithm Location CSP1 Private Key PKCS1v1_5 / RSA RSA private key NVRAM, RAM Single direct overwrite consisting of used for public-key (plain text) zeros followed by a read-verify action. based authentication
29 of 91 Dell Networking Platforms Assurance Activity Report
CSP2 Private Key PKCS1v1_5 / RSA X509 private key NVRAM, RAM Single direct overwrite consisting of used for certificate- (plain text) zeros followed by a read-verify action. based authentication CSP3 SSH Session Generated using SSH keys – server RAM (plain text) Single direct overwrite consisting of Keys SSH KDF to client, client to zeros followed by a read-verify action. server CSP4 Diffie-Hellman DH Key agreement for RAM (plain text) Cleared when device is powered down Key Pair SSH sessions or as part of session termination. Overwritten by new value or loss of capacitor charge in the memory cell. CSP5 TLS Pre-master RSA or DH, Key agreement for RAM (plain text) Cleared when device is powered down Secret generated using TLS or as part of session termination. DRBG Overwritten by new value or loss of capacitor charge in the memory cell. CSP6 TLS Session Generated using Symmetric keys for RAM (plain text) Cleared when device is powered down Keys TLS KDF TLS or as part of session termination. Overwritten by new value or loss of capacitor charge in the memory cell. CSP7 Administrative SHA256 Credentials used to FLASH (cipher Hashed passwords exist locally in a Passwords authenticate the text) startup configuration file and replaced administrator login. when that file is edited and saved. The passwords are stored in the hashed form only. Overwritten with new data. RAM (cipher Passwords in RAM are zeroized when and plain text) creating / resetting the password. Both clear text and encrypted forms are stored in RAM. Overwritten by new value or loss of capacitor charge in the memory cell. CSP8 PRNG Seed key /dev/random Seed key for PRNG RAM (plain text) Cleared when device is powered down or during reboot by the new seed. Overwritten by new value or loss of capacitor charge in the memory cell.
(2) Reading the ST section 7.2, table 16, the evaluator confirms that the description of keys and storage locations is consistent with the functions carried out by the TOE. (3) The evaluator confirmed that table 16 in the TSS section identifies how the TOE destroys keys stored as plaintext in non-volatile memory. For each plaintext CSP, the conditions when it is cleared are clearly explained. (4) The ST, section 7.2, does not identify keys that are stored in a non-plaintext form. The ST, table 16 mentions that all the keys are stored in plain-text state in the NVRAM and/or the RAM devices. (5) The evaluator checked the TSS section in the ST and did not identify any configurations or circumstances that may not conform to the key destruction requirement. (6) The evaluator confirmed that the selection “a value that does not contain any CSP” is not made within the FCS_CKM.4 SFR in the ST. The evaluator consider this assurance activity satisfied and no additional examination of the TSS section is needed.
30 of 91 Dell Networking Platforms Assurance Activity Report
2.2.3.2 Guidance Assurance Activities
Guidance Assurance Activities: A TOE may be subject to situations that could prevent or delay key destruction in some cases. The evaluator shall check that the guidance documentation identifies configurations or circumstances that may not strictly conform to the key destruction requirement, and that this description is consistent with the relevant parts of the TSS (and any other supporting information used). The evaluator shall check that the guidance documentation provides guidance on situations where key destruction may be delayed at the physical layer.
For example, when the TOE does not have full access to the physical memory, it is possible that the storage may be implementing wear-levelling and garbage collection. This may result in additional copies of the key that are logically inaccessible but persist physically. Where available, the TOE might then describe use of the TRIM command and garbage collection to destroy these persistent copies upon their deletion (this would be explained in TSS and Operational Guidance). Guidance Assurance Activities Details/Results: The CC guide, Section 3 Getting Started, Factory-Default Configuration, page 17 describes that restoring the device to factory defaults does not remove files from the filesystem that may have been downloaded, nor does it remove any certificates installed in the trust store. However, the section details how the TOE’s administrator can permanently delete these remaining certificates files from the TOE and any undesired files from the filesystem.
2.2.3.3 Testing Assurance Activities
Testing Assurance Activities: None Testing Assurance Activities Details/Results: N/A
2.2.4 FCS_COP.1/DataEncryption Cryptographic Operation (AES Data Encryption/Decryption)
2.2.4.1 TSS Assurance Activities
TSS Assurance Activities: None TSS Implementation Details/Results: N/A
2.2.4.2 Guidance Assurance Activities
Guidance Assurance Activities: None Guidance Assurance Activities Details/Results: N/A
2.2.4.3 Testing Assurance Activities
Testing Assurance Activities: Specific algorithm tests are detailed in the Supporting Document Section 2.2.4.1 Testing Assurance Activities Details/Results: The evaluator verified that the TOE’s encryption/decryption implementation as validated by CAVP AES certificates: #C213 using the exact version of the cryptographic module following appropriate installation and usage guidance. This validates AES as specified in ISO 18033-3, CBC as specified in ISO 10116.
31 of 91 Dell Networking Platforms Assurance Activity Report
2.2.5 FCS_COP.1/SigGen Cryptographic Operation (Signature Generation and Verification
2.2.5.1 TSS Assurance Activities
TSS Assurance Activities: None TSS Implementation Details/Results: N/A
2.2.5.2 Guidance Assurance Activities
Guidance Assurance Activities: None Guidance Assurance Activities Details/Results: N/A
2.2.5.3 Testing Assurance Activities
Testing Assurance Activities: Specific algorithm tests are detailed in the Supporting Document Section 2.2.5.1 Testing Assurance Activities Details/Results: The evaluation team verified that the TOE’s signature generation and verification implementation as validated by CAVP RSA certificates: #C213 conform to FIPS PUB 186-4 using the exact version of the cryptographic module following appropriate installation and usage guidance. This validates the TOE’s conformance claim for signature generation and verification.
2.2.6 FCS_COP.1/Hash Cryptographic Operation (Hash Algorithm)
2.2.6.1 TSS Assurance Activities
TSS Assurance Activities: The evaluator shall check that the association of the hash function with other TSF cryptographic functions (for example, the digital signature verification function) is documented in the TSS. TSS Implementation Details/Results: The ST identifies hashing functionality used by other cryptographic functionality, specifically:
The ST, Section 7.2 Table 15 entry for FCS_SSHS_EXT.1 lists SSH values for HMACs and Diffie- Hellman key exchange The ST, Section 7.2 Table 15 entry for FCS_TLSC_EXT.2 lists SHA1 and SHA-256 for the four TLS ciphersuites supported by the TOE The ST, Section 7.2 Table 15 entry for FCS_COP.1/SigGen details signature functionality using SHA-1, SHA-256, and SHA512. The ST, Section 7.2 Table 15 entry for FCS_COP.1/Hash details hashing functionality using SHA- 1, SHA-256, and SHA512. The ST, Section 7.2 Table 15 entry for FCS_COP.1/KeyedHash lists keyed hash algorithm parameters that utilize SHA-1, and SHA-256.
The evaluator examined these descriptions and concluded that they are consistent and match functionality claimed in SHS cert #C213 certificate.
32 of 91 Dell Networking Platforms Assurance Activity Report
2.2.6.2 Guidance Assurance Activities
Guidance Assurance Activities: The evaluator checks the AGD documents to determine that any configuration that is required to configure the required hash sizes is present. Guidance Assurance Activities Details/Results: This cryptographic functionality is not administrator-configurable. Instead, it is controlled via protocol settings.
2.2.6.3 Testing Assurance Activities
Testing Assurance Activities: Specific algorithm tests are detailed in the Supporting Document Section 2.2.6.3. Testing Assurance Activities Details/Results: The evaluation team verified that the TOE’s hashing implementation as validated by CAVP SHS certificates: #C213 using the exact version of the cryptographic module following appropriate installation and usage guidance. This validates the claims of conformance for the TOE’s hashing functionality to FIPS PUB 180-3 “Secure Hash Standard” within its operational environment.
2.2.7 FCS_COP.1/KeyedHash Cryptographic Operation (Keyed Hash Algorithm)
2.2.7.1 TSS Assurance Activities
TSS Assurance Activities: The evaluator shall examine the TSS to ensure that it specifies the following values used by the HMAC function: key length, hash function used, block size, and output MAC length used. TSS Implementation Details/Results: The evaluator examined the ST Section 7.2 and noted that it references CAVP #C213 that specifies the supported cryptographic key sizes: 160, 256 bits and message digest sizes: 160, 256, 512 bits and the hash functions used; ST table 15 matches what is in the CAVP #C213.
2.2.7.2 Guidance Assurance Activities
Guidance Assurance Activities: None Guidance Assurance Activities Details/Results: N/A
2.2.7.3 Testing Assurance Activities
Testing Assurance Activities: Specific algorithm tests are detailed in the Supporting Document Section 2.2.7.2. Testing Assurance Activities Details/Results: The evaluation team verified that the TOE’s keyed hashing implementation as validated by CAVP HMAC certificate #C213 using the exact version of the cryptographic module following appropriate installation and usage guidance. This validates the claim of conformance for the TOE’s keyed hashing functionality to FIPS PUB 198-1.
33 of 91 Dell Networking Platforms Assurance Activity Report
2.2.8 FCS_RBG_EXT.1 Extended: Cryptographic Operation (Random Bit Generation)
2.2.8.1 TSS Assurance Activities
TSS Assurance Activities: The evaluator shall examine the TSS to determine that it specifies the DRBG type, identifies the entropy source(s) seeding the DRBG, and state the assumed or calculated min-entropy supplied either separately by each source or the min-entropy contained in the combined seed value. TSS Implementation Details/Results: The evaluator examined the ST Section 7.2 and noted that it references CAVP #C213 that specifies the DRBG type, seeded with full entropy sourced from the Linux Kernel Random Number Generator (LKRNG) operating in blocking mode (/dev/random) with a minimum of 256-bits of entropy. All entropy is extracted, processed, and accumulated by the LKRNG from multiple software-based noise sources. The following noise sources are used: timing of inter-process communications events and CPU jitter. Accumulated entropy is not preserved across system reboots.
2.2.8.2 Guidance Assurance Activities
Guidance Assurance Activities: The evaluator shall confirm that the guidance documentation contains appropriate instructions for configuring the RNG functionality. Guidance Assurance Activities Details/Results: This cryptographic functionality is not administrator-configurable. Instead, it is global configuration for a cryptographic module.
2.2.8.3 Testing Assurance Activities
Testing Assurance Activities: Specific algorithm tests are detailed in the Supporting Document Section 2.2.8.3 Testing Assurance Activities Details/Results: The evaluator verified that the TOE uses a software based entropy source to seed a CTR_DRBG (AES- 256) random bit generator as validated by the CAVP DRBG certificate #C213 that meets NIST SP 800-90 “Recommendation for Random Number Generation Using Deterministic Random Bit Generators”.
34 of 91 Dell Networking Platforms Assurance Activity Report
2.3 FCS_SSHS_EXT.1 SSH Server
2.3.1 FCS_SSHS_EXT.1.2
2.3.1.1 TSS Assurance Activities
TSS Assurance Activities: The evaluator shall check to ensure that the TSS contains a description of the public key algorithms that are acceptable for use for authentication, that this list conforms to FCS_SSHS_EXT.1.5, and ensure that if password-based authentication methods have been selected in the ST then these are also described. TSS Implementation Details/Results: The ST, Section 7.2, Table 15 states that SSH_RSA is used as the public key algorithm.
This list conforms to FCS_SSHS_EXT.1.5, and it was verified in the ST, Section 7.2 Table 15.
Password-based authentication methods used with SSH are described in ST Table 15.
2.3.1.2 Guidance Assurance Activities
Guidance Assurance Activities: None Guidance Assurance Activities Details/Results: N/A
2.3.1.3 Testing Assurance Activities
Testing Assurance Activities: Test 1: If password-based authentication methods have been selected in the ST then using the guidance documentation, the evaluator shall configure the TOE to accept password-based authentication, and demonstrate that user authentication succeeds when the correct password is provided by the user. Test 2: If password-based authentication methods have been selected in the ST then the evaluator shall use an SSH client, enter an incorrect password to attempt to authenticate to the TOE, and demonstrate that the authentication fails. Note: Public key authentication is tested as part of testing for FCS_SSHS_EXT.1.5. Testing Assurance Activities Details/Results: Test 1: The evaluator followed the CC Guide Section 5 Setting Up the Common Criteria Configuration, Configuring Security, page 27 to configure the TOE to accept password-based authentication, and demonstrated that a user can be successfully authenticated to the TOE over SSH using a password as an authenticator. See test case PP-14B for more details. Test 2: The evaluator configure the TOE to accept password-based authentication and demonstrated that entering invalid password do not result in successful authentication. See test case PP-14B for more details.
2.3.2 FCS_SSHS_EXT.1.3
2.3.2.1 TSS Assurance Activities
TSS Assurance Activities: The evaluator shall check that the TSS describes how “large packets” in terms of RFC 4253 are detected and handled.
35 of 91 Dell Networking Platforms Assurance Activity Report
TSS Implementation Details/Results: The ST, Section 7.2 describes how large packets are detected and handled. Packets that exceed 256k bytes are dropped.
The maximum packet size is defined as 256k bytes in FCS_SSHS_EXT.1.3.
2.3.2.2 Guidance Assurance Activities
Guidance Assurance Activities: None Guidance Assurance Activities Details/Results: N/A
2.3.2.3 Testing Assurance Activities
Testing Assurance Activities: The evaluator shall demonstrate that if the TOE receives a packet larger than that specified in this component, that packet is dropped. Testing Assurance Activities Details/Results: The evaluator used a custom tool to send a non-fragmented handshake packet larger than the specified size. The modified packet, client key exchange init, included a valid list of ciphers padded with a repeated ‘the-quick-brow’ garbage string until the packet was of the desired length. Using packet capture, an application layer rejection was observed. See PP-14C test case for details.
2.3.3 FCS_SSHS_EXT.1.4
2.3.3.1 TSS Assurance Activities
TSS Assurance Activities: (1) The evaluator shall check the description of the implementation of this protocol in the TSS to ensure that optional characteristics are specified, and the encryption algorithms supported are specified as well. (2) The evaluator shall check the TSS to ensure that the encryption algorithms specified are identical to those listed for this component. TSS Implementation Details/Results: (1) The ST, Section 7.2 describes that the TOE implements the SSHv2 protocol and supports the following encryption algorithms: aes128-cbc and aes256-cbc. The evaluator checked the description of the SSH protocol in the TSS section and found that no optional SSH characteristics are supported by the TOE. (2) The ST, Section 7.2 was reviewed to ensure that the encryption algorithms specified are identical to those listed for this SFR in Section 6.1.2.9.
2.3.3.2 Guidance Assurance Activities
Guidance Assurance Activities: The evaluator shall also check the guidance documentation to ensure that it contains instructions on configuring the TOE so that SSH conforms to the description in the TSS (for instance, the set of algorithms advertised by the TOE may have to be restricted to meet the requirements). Guidance Assurance Activities Details/Results: The CC Guide, Section 5, Setting Up the Common Criteria Configuration, Configuring Encryption Algorithms for SSH Server, page 29 contains instructions on configuring the TOE so that SSH conforms to the description in the TSS.
36 of 91 Dell Networking Platforms Assurance Activity Report
2.3.3.3 Testing Assurance Activities
Testing Assurance Activities: (1) The evaluator must ensure that only claimed ciphers and cryptographic primitives are used to establish a SSH connection. To verify this, the evaluator shall start session establishment for a SSH connection from a remote client (referred to as ‘remote endpoint’ below). The evaluator shall capture the traffic exchanged between the TOE and the remote endpoint during protocol negotiation (e.g. using a packet capture tool or information provided by the endpoint, respectively). The evaluator shall verify from the captured traffic that the TOE offers all the ciphers defined in the TSS for the TOE for SSH sessions, but no additional ones compared to the definition in the TSS. (2) The evaluator shall perform one successful negotiation of an SSH session to verify that the TOE behaves as expected. It is sufficient to observe the successful negotiation of the session to satisfy the intent of the test. If the evaluator detects that not all ciphers defined in the TSS for SSH are supported by the TOE and/or the TOE supports one or more additional ciphers not defined in the TSS for SSH, the test shall be regarded as failed. Testing Assurance Activities Details/Results: (1) The evaluator used the test case PP-14D to verify this activity. In test case PP-14D, the evaluator configured the SSH Client to use only the ciphersuites that are supported by the TOE: The aes256-cbc and aes-128-cbc as encryption algorithms The Diffie-hellman-group14-sha1, Diffie-hellman-group14-sha256 as the exchange key algorithms The hmac-sha1, and hmac-sha2-256, as the hash algorithms The [email protected] , zlib, and none, as the ssh compression algorithms The rsa-sha2-256 as the host key algorithm. The evaluator used Bitvise client to establish a SSH session between the TOE and the client. During the session establishment, Wireshark was used to capture the traffic between the TOE and the client to verify the protocol negotiation. The evaluator verified in the Wireshark traffic capture that the TOE only offered the following ciphersuites algorithms as configured in the TOE: The aes256-cbc and aes-128-cbc as encryption algorithms The Diffie-hellman-group14-sha1, as the exchange key algorithms The hmac-sha1, hmac-sha1-96 and hmac-sha2-256, as the hash algorithms No ssh compression algorithms. The ssh-rsa, rsa-sha2-256 and rsa-sha2-512 as the host key algorithm. The evaluator concluded from the captured traffic that the TOE offered all the ciphers defined in the TSS for the TOE for SSH sessions, but no additional ones compared to the definition in the TSS.
(2) In test case PP-14D, the evaluator confirmed that that TOE successfully negotiated an SSH session with the client and behaved as intended. The evaluator found that the TOE does not support any ciphers undefined in the TSS nor deny support of any ciphers defined in the TSS for SSH.
2.3.4 FCS_SSHS_EXT.1.5
2.3.4.1 TSS Assurance Activities
TSS Assurance Activities: (1) The evaluator shall check the description of the implementation of this protocol in the TSS to ensure that optional characteristics are specified, and the public key algorithms supported are specified as well.
37 of 91 Dell Networking Platforms Assurance Activity Report
(2) The evaluator shall check the TSS to ensure that the public key algorithms specified are identical to those listed for this component. TSS Implementation Details/Results: The ST, Section 7.2 describes that the TOE implements SSH-RSA, RSA-SHA2-256, and RSA-SHA2-512 for public key authentication and there are no optional characteristics specified.
The evaluator verified the TSS to ensure that the public key specified is identical to that listed for this SFR in Section 6.1.2.9 of the ST.
2.3.4.2 Guidance Assurance Activities
Guidance Assurance Activities: The evaluator shall also check the guidance documentation to ensure that it contains instructions on configuring the TOE so that SSH conforms to the description in the TSS (for instance, the set of algorithms advertised by the TOE may have to be restricted to meet the requirements). Guidance Assurance Activities Details/Results: The CC Guide, Section 5, “Setting Up the Common Criteria Configuration”, “Configuring Encryption Algorithms and HMAC Algorithms”, page 29 contains instructions on how to configure the TOE so that its SSH Server conforms to the description in the TSS. The CC Guide, Section 5, “Enabling RSA authentication” in Page 31, states “The user's public key used for RSA authentication may use different RSA algorithms: ssh-rsa, rsa-sha2-256, or rsa-sah2-512.”
2.3.4.3 Testing Assurance Activities
Testing Assurance Activities: Test 1: The evaluator shall establish a SSH connection using each of the public key algorithms specified by the requirement to authenticate the TOE to an SSH client. It is sufficient to observe (on the wire) the successful negotiation of the algorithm to satisfy the intent of the test. Test 2: The evaluator shall choose one public key algorithm supported by the TOE. The evaluator shall generate a new key pair for that algorithm without configuring the TOE to recognize the public key for authentication. The evaluator shall use an SSH client to attempt to connect to the TOE with the new key pair and demonstrate that authentication fails. Test objective: The purpose of this negative test is to verify that the server rejects authentication attempts of clients that present a public key that does not match public key(s) associated by the TOE with the identity of the client (i.e. the public keys are unknown to the server). To demonstrate correct functionality it is sufficient to determine that an SSH connection was not established after using a valid username and an unknown key of supported type. Note: TD0412 https://www.niap-ccevs.org/Documents_and_Guidance/view_td.cfm?td_id=412 was applied. Test 3: The evaluator shall configure an SSH client to only allow a public key algorithm that is not included in the ST selection. The evaluator shall attempt to establish an SSH connection from the SSH client to the TOE and observe that the connection is rejected. Testing Assurance Activities Details/Results: Test 1: The TOE in the evaluated configuration supports an ssh-rsa, rsa-sha2-256 and rsa-sha2-512 public keys as part of SSH transport algorithm. In test case PP-14E, the evaluator observed a successful SSHv2 handshake using these host key algorithms.
Test 2: in test case PP-14A, the evaluator configured the TOE to use public-key-based authentication, then generated a new client RSA key pair without associating that key with a TOE administrator account. The evaluator used a standard SSH client to attempt to connect to the TOE with the new
38 of 91 Dell Networking Platforms Assurance Activity Report
key pair and observed that the SSH connection failed to establish between the TOE and the remote SSH client.
Test 3: In test case PP-14E, the evaluator configured the standard SSH client to only negotiate the ssh-dss algorithm. The evaluator then attempted to establish a SSH connection and observed that the SSH connection failed to establish between the TOE and the remote SSH client.
2.3.5 FCS_SSHS_EXT.1.6
2.3.5.1 TSS Assurance Activities
TSS Assurance Activities: The evaluator shall check the TSS to ensure that it lists the supported data integrity algorithms, and that that list corresponds to the list in this component. TSS Implementation Details/Results: The ST, Section 7.2 describes that the TOE implements SSHv2 protocol and supports the following data integrity algorithms: hmac-sha1, hmac-sha1-96, and hmac-sha2-256.
The list of supported data integrity algorithms corresponds to the list in this component in Section 6.1.2.9.
2.3.5.2 Guidance Assurance Activities
Guidance Assurance Activities: The evaluator shall also check the guidance documentation to ensure that it contains instructions to the administrator on how to ensure that only the allowed data integrity algorithms are used in SSH connections with the TOE (specifically, that the “none” MAC algorithm is not allowed). Guidance Assurance Activities Details/Results: The CC Guide, Section 5, Setting Up the Common Criteria Configuration, Configuring HMAC Algorithms for SSH Server, page 30 contains instructions on how to ensure that the following data integrity algorithms: hmac-sha1, hmac-sha1-96, hmac-sha2-256 for use in SSH connections with the TOE.
2.3.5.3 Testing Assurance Activities
Testing Assurance Activities: Test 1: (conditional, if an HMAC or AEAD_AES_*_GCM algorithm is selected in the ST) The evaluator shall establish an SSH connection using each of the algorithms, except “implicit”, specified by the requirement. It is sufficient to observe (on the wire) the successful negotiation of the algorithm to satisfy the intent of the test. Note: To ensure the observed algorithm is used, the evaluator shall ensure a non-aes*- [email protected] encryption algorithm is negotiated while performing this test. Test 2: (conditional, if an HMAC or AEAD_AES_*_GCM algorithm is selected in the ST) The evaluator shall configure an SSH client to only allow a MAC algorithm that is not included in the ST selection. The evaluator shall attempt to connect from the SSH client to the TOE and observe that the attempt fails. Note: To ensure the proposed MAC algorithm is used, the evaluator shall ensure a non-aes*- [email protected] encryption algorithm is negotiated while performing this test. Testing Assurance Activities Details/Results: Test 1: The TOE, in the evaluated configuration, supports the hmac-sha1, hmac-sha1-96, and hmac-sha2- 256 algorithms as part of the SSH transport layer protocol. In test case PP-14F, the evaluator
39 of 91 Dell Networking Platforms Assurance Activity Report
observed a successful SSHv2 handshake using each of these claimed integrity algorithms. Packet capture was used to confirm the HMAC selection, and observation of the subsequent CLI prompt confirmed a successful connection. Test 2: The evaluator configured a standard SSH client to negotiate only the hmac-md5-96 HMAC algorithm. The HMAC-MD5-96 algorithm is not supported by the TOE. The evaluator attempted to connect to the TOE and observed that the attempt failed with the following reported reason: “no mutually supported inbound MAC algorithm”. Packet capture analysis confirmed that the attempted HMAC algorithm was offered by the SSH client but not accepted by the TOE.
2.3.6 FCS_SSHS_EXT.1.7
2.3.6.1 TSS Assurance Activities
TSS Assurance Activities: The evaluator shall check the TSS to ensure that it lists the supported key exchange algorithms, and that that list corresponds to the list in this component. TSS Implementation Details/Results: The ST, Section 7.2 explains that the TOE supports Diffie-Hellman-group14-sha1 as its key exchange algorithm. This list corresponds to the list in this component in Section 6.1.2.9.
2.3.6.2 Guidance Assurance Activities
Guidance Assurance Activities: The evaluator shall also check the guidance documentation to ensure that it contains instructions to the administrator on how to ensure that only the allowed key exchange algorithms are used in SSH connections with the TOE. Guidance Assurance Activities Details/Results: The CC Guide, Section 5, Setting Up the Common Criteria Configuration Verifying the SSHv2 Server Configuration, page 30 contains instructions on running the command “show ip ssh”, which displays the entry for the “SSH Server Kex algorithms”. Reviewing that entry, as per the instructions, will show that diffie-hellman-group14-sha1 is used in SSH connections to the TOE.
2.3.6.3 Testing Assurance Activities
Testing Assurance Activities: Test 1: The evaluator shall configure an SSH client to only allow the diffie-hellman-group1-sha1 key exchange. The evaluator shall attempt to connect from the SSH client to the TOE and observe that the attempt fails. Test 2: For each allowed key exchange method, the evaluator shall configure an SSH client to only allow that method for key exchange, attempt to connect from the client to the TOE, and observe that the attempt succeeds. Testing Assurance Activities Details/Results: Test 1: In test case PP-14G, the evaluator configured the SSH client to only allow the diffie-hellman- group1-sha1 key exchange, then attempted to connect from the SSH client to the TOE. This resulted in a failed connection as expected. Test 2: The TOE in the evaluated configuration supports only diffie-hellman-group14-sha1 key exchange method as part of SSH transport layer protocol. In test case PP-14G test case, the evaluator observed successful SSHv2 handshake using this key exchange method. Packet capture was used to observe the successful negotiation.
40 of 91 Dell Networking Platforms Assurance Activity Report
2.3.7 FCS_SSHS_EXT.1.8
2.3.7.1 TSS Assurance Activities
TSS Assurance Activities: The evaluator shall check that the TSS specifies the following: a) Both thresholds are checked by the TOE. b) Rekeying is performed upon reaching the threshold that is hit first. TSS Implementation Details/Results: The ST, Section 7.2, details that SSH connection is automatically rekeyed by default after 60 minutes or 1 GB of data, both of these thresholds are administrator-configurable.
2.3.7.2 Guidance Assurance Activities
Guidance Assurance Activities: If one or more thresholds that are checked by the TOE to fulfil the SFR are configurable, then the evaluator shall check that the guidance documentation describes how to configure those thresholds. Either the allowed values are specified in the guidance documentation and must not exceed the limits specified in the SFR (one hour of session time, one gigabyte of transmitted traffic) or the TOE must not accept values beyond the limits specified in the SFR. The evaluator shall check that the guidance documentation describes that the TOE reacts to the first threshold reached. Guidance Assurance Activities Details/Results: The CC Guide, Section 5, Setting Up the Common Criteria Configuration, configuring SSH threshold Values, Page 30 states that to configure SSH threshold values, use the SSH ip ssh rekey configuration command. For example, to set the time to 60 minutes and the traffic volume to 1024, use the following command: ip ssh rekey time 60 volume 1024
2.3.7.3 Testing Assurance Activities
Testing Assurance Activities: The evaluator needs to perform testing that rekeying is performed according to the description in the TSS. The evaluator shall test both, the time-based threshold and the traffic-based threshold. For testing of the time-based threshold the evaluator shall use an SSH client to connect to the TOE and keep the session open until the threshold is reached. The evaluator shall verify that the SSH session has been active longer than the threshold value and shall verify that the TOE initiated a rekey (the method of verification shall be reported by the evaluator). Testing does not necessarily have to be performed with the threshold configured at the maximum allowed value of one hour of session time but the value used for testing shall not exceed one hour. The evaluator needs to ensure that the rekeying has been initiated by the TOE and not by the SSH client that is connected to the TOE. For testing of the traffic-based threshold the evaluator shall use an SSH client to connect to the TOE, and shall transmit data from and to the TOE within the active SSH session until the threshold for transmitted traffic is reached. The transmitted traffic is the total traffic comprising incoming and outgoing traffic. The evaluator shall verify that more data has been transmitted within the SSH session than the threshold allows and shall verify that the TOE initiated a rekey (the method of verification shall be reported by the evaluator). Testing does not necessarily have to be performed with the threshold configured at the maximum allowed value of one gigabyte of transferred traffic but the value used for testing shall not exceed one gigabyte. The
41 of 91 Dell Networking Platforms Assurance Activity Report evaluator needs to ensure that the rekeying has been initiated by the TOE and not by the SSH client that is connected to the TOE. If one or more thresholds that are checked by the TOE to fulfil the SFR are configurable, the evaluator needs to verify that the threshold(s) can be configured as described in the guidance documentation and the evaluator needs to test that modification of the thresholds is restricted to Security Administrators (as required by FMT_MOF.1/Functions). In cases where data transfer threshold could not be reached due to hardware limitations it is acceptable to omit testing of this (SSH rekeying based on data transfer threshold) threshold if both the following conditions are met: c) An argument is present in the TSS section describing this hardware-based limitation and d) All hardware components that are the basis of such argument are definitively identified in the ST. For example, if specific Ethernet Controller or WiFi radio chip is the root cause of such limitation, these chips must be identified. Testing Assurance Activities Details/Results: The TOE implements administrator-configurable SSH rekey based on time-base or traffic-based thresholds and this event is audited. In test case PP-14H, the evaluator configured the threshold to 10 minutes and 1MB of data. For the time-based threshold, the evaluator prevented the session from timing out while waiting for the rekey to happen. For traffic-based threshold, the evaluator repeatedly used the #show tech-support command. This CLI command displays a collection of data from other show commands and was used to exceed traffic-based threshold.
42 of 91 Dell Networking Platforms Assurance Activity Report
2.4 FCS_TLSC_EXT.2 Extended: TLS Client Protocol with authentication
2.4.1 FCS_TLSC_EXT.2.1
2.4.1.1 TSS Assurance Activities
TSS Assurance Activities: The evaluator shall check the description of the implementation of this protocol in the TSS to ensure that the ciphersuites supported are specified. The evaluator shall check the TSS to ensure that the ciphersuites specified are identical to those listed for this component. TSS Implementation Details/Results: The ST, Section 7.2 describes the implementation of the TLS and lists the following ciphersuites:
TLS_RSA_WITH_AES_128_CBC_SHA TLS_RSA_WITH_AES_256_CBC_SHA TLS_DHE_RSA_WITH_AES_256_CBC_SHA TLS_DHE_RSA_WITH_AES_128_CBC_SHA TLS_RSA_WITH_AES_128_CBC_SHA256 TLS_RSA_WITH_AES_256_CBC_ SHA256 TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
As the supported ciphersuites. The evaluator verified that the ciphersuites specified match those listed for this component in Section 6.1.2.10.
2.4.1.2 Guidance Assurance Activities
Guidance Assurance Activities: The evaluator shall also check the guidance documentation to ensure that it contains instructions on configuring the TOE so that TLS conforms to the description in the TSS. Guidance Assurance Activities Details/Results: The CC Guide, Appendix B - X.509v3, Transport layer Security (TLS), Page 68 contains instructions on configuring the TOE so that TLS conforms to the description in the TSS.
2.4.1.3 Testing Assurance Activities
Testing Assurance Activities: Test 1: The evaluator shall establish a TLS connection using each of the ciphersuites specified by the requirement. This connection may be established as part of the establishment of a higher-level protocol, e.g., as part of an HTTPS session. It is sufficient to observe the successful negotiation of a ciphersuite to satisfy the intent of the test; it is not necessary to examine the characteristics of the encrypted traffic to discern the ciphersuite being used (for example, that the cryptographic algorithm is 128-bit AES and not 256-bit AES). Test 2: The evaluator shall attempt to establish the connection using a server with a server certificate that contains the Server Authentication purpose in the extendedKeyUsage extension and verify that a connection is established. The evaluator shall repeat this test using a different, but otherwise valid and trusted, certificate that lacks the Server Authentication purpose in the extendedKeyUsage extension and ensure that a connection is not established. Ideally, the two certificates should be similar in structure, the types of identifiers used, and the chain of trust.
43 of 91 Dell Networking Platforms Assurance Activity Report
Note: TD0396 (https://www.niap-ccevs.org/Documents_and_Guidance/view_td.cfm?td_id=406) was applied Test 3: The evaluator shall send a server certificate in the TLS connection that does not match the server- selected ciphersuite (for example, send an ECDSA certificate while using the TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite.) The evaluator shall verify that the TOE disconnects after receiving the server’s Certificate handshake message. Test 4: The evaluator shall configure the server to select the TLS_NULL_WITH_NULL_NULL ciphersuite and verify that the client denies the connection. Test 5: The evaluator perform the following modifications to the traffic: a) Change the TLS version selected by the server in the Server Hello to a non-supported TLS version (for example 1.5 represented by the two bytes 03 06) and verify that the client rejects the connection. b) Modify at least one byte in the server’s nonce in the Server Hello handshake message, and verify that the client rejects the Server Key Exchange handshake message (if using a DHE or ECDHE ciphersuite) or that the server denies the client’s Finished handshake message. c) Modify the server’s selected ciphersuite in the Server Hello handshake message to be a ciphersuite not presented in the Client Hello handshake message. The evaluator shall verify that the client rejects the connection after receiving the Server Hello. d) If using DHE or ECDH, modify the signature block in the Server’s Key Exchange handshake message, and verify that the client rejects the connection after receiving the Server Key Exchange message. This test does not apply to cipher suites using RSA key exchange. If a TOE only supports RSA key exchange in conjunction with TLS then this test shall be omitted. e) Modify a byte in the Server Finished handshake message, and verify that the client sends an Encrypted Message followed by a FIN and ACK message. This is sufficient to deduce that the TOE responded with a Fatal Alert and no further data would be sent. f) Send a garbled message from the Server after the Server has issued the ChangeCipherSpec message and verify that the client denies the connection. Testing Assurance Activities Details/Results: Test 1: The TOE implements trusted channel with an audit server using TLS v1.2. In this configuration, the TOE acts as a client. The following TLS ciphers are supported in the evaluated configuration: TLS_RSA_WITH_AES_128_CBC_SHA TLS_RSA_WITH_AES_128_CBC_SHA256 TLS_RSA_WITH_AES_256_CBC_SHA TLS_RSA_WITH_AES_256_CBC_SHA256 TLS_DHE_RSA_WITH_AES_256_CBC_SHA TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 TLS_DHE_RSA_WITH_AES_128_CBC_SHA TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 In test case PP-17A, the evaluator established a TLS connection using each of the ciphersuites specified by the requirement. A combination of syslog-ng and a custom test tool was used to force negotiation of each supported ciphersuite. Packet capture was used to observe the handshake and to confirm that the selected ciphersuite was successfully negotiated. Test 2: In test case PP-17B, the TLS tool was configured to authenticate with an otherwise valid X509 certificate that was configured with extendedKeyUsage=clientAuth. The evaluator observed that a connection was not established. When another certificate that contained extendedKeyUsage=serverAuth was used, a connection was successfully established. In
44 of 91 Dell Networking Platforms Assurance Activity Report
both cases, sha256WithRSAEncryption certificates were issued by the same trusted CA with an otherwise-identical set of extensions. Test 3: In test case PP-17C, the evaluator configured the test tool (acting as a TLS server) to send an ECDSA certificate to the TOE instead of sending an RSA certificate. The evaluator observed that a connection was not established. Test 4: In test case PP-17D, the evaluator configured the test tool (acting as a TLS server) to specify cipher_suite= ‘TLS_NULL_WITH_NULL_NULL’ in the Server Hello message during the TLS handshake. The evaluator verified that the TOE denied the connection. Test 5: The evaluator used a custom test tool to send modified traffic as specified in the assurance activities. For the following tests, the test tool is acting as a TLS server and the TOE is acting as a client. a) In test case PP-17E, the evaluator sent the Server Hello message containing combinations of client_version_major and client_version_minor corresponding to SSL 3.0 and TLS 1.0 and TLS v1.1 and observed that the TOE rejected the connection. b) In test case PP-17F, the evaluator sent the Server Hello message with one byte in the server’s nonce in the Server Hello handshake message. Since the TOE supports both DHE and RSA based ciphers, one of each type was used and in both cases the handshake did not complete and appropriate rejections were observed. c) In test case PP-17G, the evaluator sent the Server Hello handshake message that contained cipher_suite = 'TLS_DHE_RSA_WITH_DES_CBC_SHA'. The evaluator observed that the TOE rejected the connection after receiving the Server Hello with ‘TLS connection failed – unable to establish connection: wrong cipher returned ‘ message displayed on the console. d) In test case PP-17H, the evaluator sent the Server’s Key Exchange handshake message with modified signature block and observed that the TOE rejected the connection after receiving the Server Key Exchange message by sending Fatal Alert: Decrypt Error message. e) In test case PP-17I, the evaluator sent the modified Server Finished handshake message and observed that the TOE responded with TLS Encrypted Alert message followed by TCP FIN ACK. The evaluator concluded that this behavior is consistent with a fatal alert and that closing the TCP socket ensured that no further application data could be sent. f) In test case PP-17J, the evaluator sent a garbled message after the Server had issued the ChangeCipherSpec message and observed that the TOE responded by sending the TLS Encrypted Alert message followed by TCP FIN ACK.
45 of 91 Dell Networking Platforms Assurance Activity Report
2.4.2 FCS_TLSC_EXT.2.2
2.4.2.1 TSS Assurance Activities
TSS Assurance Activities: (1) The evaluator shall ensure that the TSS describes the client’s method of establishing all reference identifiers from the administrator/application configured reference identifier, including which types of reference identifiers are supported (e.g. application-specific Subject Alternative Names) and whether IP addresses and wildcards are supported. (2) The evaluator shall ensure that this description identifies if certificate pinning is supported or used by the TOE and how it is implemented. (3) If IP addresses are supported in the CN as reference identifiers, the evaluator shall ensure that the TSS describes the TOE’s conversion of the text representation of the IP address in the CN to a binary representation of the IP address in network byte order. The evaluator shall also ensure that the TSS describes whether canonical format (RFC5952 for IPv6, RFC 3986 for IPv4) is enforced.
Note: TD0452 https://www.niap-ccevs.org/Documents_and_Guidance/view_td.cfm?TD=0452 was applied.
TSS Implementation Details/Results: (1) The ST, Section 7.2 describes the client’s method of establishing all reference identifiers. This section states that the DNS Name and the IP address are supported as reference identifiers, and that the TOE will verify that peer certificate Subject Alternative Name (SAN) or Common Name (CN) contains expected identifier. The same ST, section 7.2, states that the CN only supports domain names and not IP addresses. CN is checked only if SAN is absent. The TOE is also capable of parsing identifiers that include wildcards, but their use is discouraged (2) The evaluator noted from the ST Section 7.2 that certificate pinning is not supported by the TOE. (3) The TOE does IP addresses in the CN as reference identifiers.
2.4.2.2 Guidance Assurance Activities
Guidance Assurance Activities: The evaluator shall ensure that the operational guidance describes all supported identifiers, explicitly states whether the TOE supports the SAN extension or not, and includes detailed instructions on how to configure the reference identifier(s) used to check the identity of peer(s). If the identifier scheme implemented by the TOE includes support for IP addresses, the evaluator shall ensure that the operational guidance provides a set of warnings and/or CA policy recommendations that would result in secure TOE use.
Note: TD0452 https://www.niap-ccevs.org/Documents_and_Guidance/view_td.cfm?TD=0452 was applied. Guidance Assurance Activities Details/Results: The CC Guide, Appendix B - X.509v3, Verifying Server certificates, page 70 includes the following note: “Note: As part of the certificate verification, the hostname or IP address of the server is verified against the hostname or IP address specified in the application. For example, when using SYSLOG over TLS, the hostname or IP address specified in the ‘logging syslog-server secure port port-number’ command is compared against the SubjectAltName or Common Name field in the server certificate.”
The evaluator concluded that “the hostname or IP address of the server” is the reference identifier, and that it is configured as part of the ‘logging’ CLI command.
2.4.2.3 Testing Assurance Activities
Testing Assurance Activities:
46 of 91 Dell Networking Platforms Assurance Activity Report
The evaluator shall configure the reference identifier according to the AGD guidance and perform the following tests during a TLS connection: Test 1: The evaluator shall present a server certificate that contains a CN that does not match the reference identifier and does not contain the SAN extension. The evaluator shall verify that the connection fails. The evaluator shall repeat this test for each identifier type (e.g. IPv4, IPv6, FQDN) supported in the CN. When testing IPv4 or IPv6 addresses, the evaluator shall modify a single decimal or hexadecimal digit in the CN. Remark: Some systems might require the presence of the SAN extension. In this case the connection would still fail but for the reason of the missing SAN extension instead of the mismatch of CN and reference identifier. Both reasons are acceptable to pass Test 1. Test 2: The evaluator shall present a server certificate that contains a CN that matches the reference identifier, contains the SAN extension, but does not contain an identifier in the SAN that matches the reference identifier. The evaluator shall verify that the connection fails. The evaluator shall repeat this test for each supported SAN type (e.g. IPv4, IPv6, FQDN, URI). When testing IPv4 or IPv6 addresses, the evaluator shall modify a single decimal or hexadecimal digit in the SAN. Test 3: [conditional] If the TOE does not mandate the presence of the SAN extension, the evaluator shall present a server certificate that contains a CN that matches the reference identifier and does not contain the SAN extension. The evaluator shall verify that the connection succeeds. The evaluator shall repeat this test for each identifier type (e.g. IPv4, IPv6, FQDN) supported in the CN. If the TOE does mandate the presence of the SAN extension, this Test shall be omitted. Test 4: The evaluator shall present a server certificate that contains a CN that does not match the reference identifier but does contain an identifier in the SAN that matches. The evaluator shall verify that the connection succeeds. The evaluator shall repeat this test for each supported SAN type (e.g. IPv4, IPv6, FQDN, SRV). Test 5: The evaluator shall perform the following wildcard tests with each supported type of reference identifier: 1) The evaluator shall present a server certificate containing a wildcard that is not in the left-most label of the presented identifier (e.g. foo.*.example.com) and verify that the connection fails. 2) The evaluator shall present a server certificate containing a wildcard in the left-most label (e.g. *.example.com). The evaluator shall configure the reference identifier with a single left-most label (e.g. foo.example.com) and verify that the connection succeeds if wildcards are supported or fails if wildcards are not supported. The evaluator shall configure the reference identifier without a left- most label as in the certificate (e.g. example.com) and verify that the connection fails. The evaluator shall configure the reference identifier with two left-most labels (e.g. bar.foo.example.com) and verify that the connection fails. (Remark: Support for wildcards was always intended to be optional. It is sufficient to state that the TOE does not support wildcards and observe rejected connection attempts to satisfy corresponding assurance activities.) Test 6: [conditional] If URI or Service name reference identifiers are supported, the evaluator shall configure the DNS name and the service identifier. The evaluator shall present a server certificate containing the correct DNS name and service identifier in the URIName or SRVName fields of the SAN and verify that the connection succeeds. The evaluator shall repeat this test with the wrong service identifier (but correct DNS name) and verify that the connection fails. Test 7: [conditional] If pinned certificates are supported, the evaluator shall present a certificate that does not match the pinned certificate and verify that the connection fails. Test 8: [conditional] If IP addresses are supported, the evaluator shall present a server certificate that contains a CN that matches the reference identifier, except one of the groups has been replaced with an asterisk (*) (e.g. CN=192.168.1.* when connecting to 192.168.1.20, CN=2001:0DB8:0000:0000:0008:0800:200C:* when connecting to 2001:0DB8:0000:0000:0008:0800:200C:417A). The certificate shall not contain the SAN extension. The evaluator shall verify that the connection fails. The evaluator shall repeat this test
47 of 91 Dell Networking Platforms Assurance Activity Report
for each supported IP address version (e.g. IPv4, IPv6). Remark: Some systems might require the presence of the SAN extension. In this case the connection would still fail but for the reason of the missing SAN extension instead of the mismatch of CN and reference identifier. Both reasons are acceptable to pass Test 8. Note: TD0452 (https://www.niap-ccevs.org/Documents_and_Guidance/view_td.cfm?td_id=0452 ) was applied. Testing Assurance Activities Details/Results: The evaluator configured the reference identifier according to the user guidance and performed the following tests during a TLS connection:
Test 1: In test case PP-17K, the evaluator configured syslog to present an otherwise valid 2048-bit RSA X509v3 certificate that did not contain an identifier in either the X509v3 Subject Alternative Name (SAN) or Common Name (CN) that matched the reference identifier. The evaluator verified that the connection failed and observed “TLS connection failed – unable to verify server: Peer’s Subject Alt Name does not match connection” error.
Test 2: In test case PP-17L, the evaluator configured syslog to present an otherwise valid 2048-bit RSA X509v3 certificate that contained a CN (commonName = tlstool.lab.local) that matched the reference identifier but had multiple SAN entries that did not match the reference identifier. The evaluator observed that the connection failed and observed “TLS connection failed – unable to verify server: Peer’s Subject Alt Name does not match connection” error. The evaluator repeated this test for DNS name and IP address reference identifiers.
Test 3: In test case PP-17M, the evaluator configured syslog to present a valid 2048-bit RSA X509v3 certificate that contained a valid CN (commonName = tlstool.lab.local) that matched the reference identifier but did not contain the SAN extension. The evaluator observed that the connection succeeded.
Test 4: In test case PP-17N, the evaluator configured syslog to present a valid 2048-bit RSA X509v3 server certificate that contained a CN that did not match the reference identifier (commonName = tlstol.lab.local) but did contain an identifier in the SAN (syslog IP address) that matched. The evaluator observed that the connection succeeded.
Test 5: The evaluator performed the following wildcard tests with each supported type of reference identifier:
1) In test case PP-17O, the evaluator presented a server certificate containing a wildcard that was not in the left-most label of the presented identifier (e.g. foo.*.example.com) and observed that the connection fails.
2) In test case PP-17O, the evaluator configured syslog to present presented a valid 2048-bit RSA X509v3 certificate that contained *.lab.local wildcard. The evaluator configured the reference identifier to tlstool.lab.local and observed that the connection succeeded. The evaluator configured the reference identifier without a left-most label in the certificate (e.g. example.com) and observed that the connection failed. The evaluator configured the reference identifier with two left- most labels to syslog.test.lab.local and observed that the connection failed.
Test 6: [conditional] URI or Service name reference identifiers are not supported.
48 of 91 Dell Networking Platforms Assurance Activity Report
Test 7: [conditional] Pinned certificates are not supported. Test 8: [conditional] TOE does not support IP addresses in the CN field.
2.4.3 FCS_TLSC_EXT.2.3
2.4.3.1 TSS Assurance Activities
TSS Assurance Activities: None TSS Implementation Details/Results: N/A
2.4.3.2 Guidance Assurance Activities
Guidance Assurance Activities: None Guidance Assurance Activities Details/Results: N/A
2.4.3.3 Testing Assurance Activities
Testing Assurance Activities: The evaluator shall demonstrate that using an invalid certificate results in the function failing as follows: Test 1: Using the administrative guidance, the evaluator shall load a CA certificate or certificates needed to validate the presented certificate used to authenticate an external entity and demonstrate that the function succeeds and a trusted channel can be established. Test 2: The evaluator shall then change the presented certificate(s) so that validation fails and show that the certificate is not automatically accepted. The evaluator shall repeat this test to cover the selected types of failure defined in the SFR (i.e. the selected ones from failed matching of the reference identifier, failed validation of the certificate path, failed validation of the expiration date, failed determination of the revocation status). The evaluator performs the action indicated in the SFR selection observing the TSF resulting in the expected state for the trusted channel (e.g. trusted channel was established) covering the types of failure for which an override mechanism is defined. Test 3: [conditional] The purpose of this test to verify that only selected certificate validation failures could be administratively overridden. If any override mechanism is defined for failed certificate validation, the evaluator shall configure a new presented certificate that does not contain a valid entry in one of the mandatory fields or parameters (e.g. inappropriate value in extendedKeyUsage field) but is otherwise valid and signed by a trusted CA. The evaluator shall confirm that the certificate validation fails (i.e. certificate is rejected), and there is no administrative override available to accept such certificate. Testing Assurance Activities Details/Results: Test 1: in test case PP-10A, the syslog server was configured to use a leaf certificate signed by a rogue CA. Using the administrative guidance, the evaluator installed Rogue CA certificate into the TOE trust store, then configured the TOE to send audit logs to the syslog server. The evaluator observed the secure channel establishment and audit events appearing in the syslog audit repository. Test 2: in test case PP-11A, the evaluator shutdown the OCSP responder, configured the TOE to reject a certificate in case the OCSP responder is unavailable and then tried to send audit events to the syslog server, which failed as expected. In the second part of the test case the evaluator setup the TOE’s behavior to accept an endpoint’s certificate (syslog server in this case) upon failure to get a response from an OCSP responder, then the evaluator started a secure channel to the syslog server and observed a successful establishment of the communication channel.
49 of 91 Dell Networking Platforms Assurance Activity Report
Tes3: in test case PP-10B, the TOE’s behavior was set to reject endpoint certificate in the case it does not get an OCSP revocation status response. The evaluator loaded an expired certificate into the TLS Tool server, and then started a secure communication to the TLS Tool, which was acting as an audit server, and observed an expected failure of the secure communication.
2.4.4 FCS_TLSC_EXT.2.4
2.4.4.1 TSS Assurance Activities
TSS Assurance Activities: The evaluator shall verify that TSS describes the Supported Elliptic Curves Extension and whether the required behaviour is performed by default or may be configured. TSS Implementation Details/Results: The ST, Section 7.2 states that the TOE does not implement support for EC cryptography or Supported Curves Extension. Therefore, this activity is not applicable.
2.4.4.2 Guidance Assurance Activities
Guidance Assurance Activities: If the TSS indicates that the Supported Elliptic Curves Extension must be configured to meet the requirement, the evaluator shall verify that AGD guidance includes configuration of the Supported Elliptic Curves Extension. Guidance Assurance Activities Details/Results: The TOE does not claim or implement support for EC cryptography or the Supported Elliptic Curves Extension. Therefore, this activity is not applicable.
2.4.4.3 Testing Assurance Activities
Testing Assurance Activities: Test 1: If using DHE or ECDH, the evaluator shall configure the server to perform an ECDHE key exchange in the TLS connection using a non-supported curve (for example P-192) and shall verify that the TOE disconnects after receiving the server’s Key Exchange handshake message. Testing Assurance Activities Details/Results: Test 1: The TOE does not claim or implement support for EC cryptography. Therefore, this activity is not applicable.
2.4.5 FCS_TLSC_EXT.2.5
2.4.5.1 TSS Assurance Activities
TSS Assurance Activities: The evaluator shall ensure that the TSS description required per FIA_X509_EXT.2.1 includes the use of client-side certificates for TLS mutual authentication. TSS Implementation Details/Results: The ST, Section 7.3 contains the description required per FIA_X509_EXT.2.1 includes the use of client- side certificates for TLS mutual authentication. ST, Section 7.3 states that the TOE supports X509v3 certificates as defined by RFC 5280 to mutually authenticate TLS connections.
50 of 91 Dell Networking Platforms Assurance Activity Report
2.4.5.2 Guidance Assurance Activities
Guidance Assurance Activities: If the TSS indicates that mutual authentication using X.509v3 certificates is used, the evaluator shall verify that the AGD guidance includes instructions for configuring the client-side certificates for TLS mutual authentication. Guidance Assurance Activities Details/Results: The CC Guide, Appendix B – X.509v3, Information about Creating Certificate Signing Requests (CSR), page 65-68 includes instructions for configuring the client-side certificates for TLS mutual authentication.
2.4.5.3 Testing Assurance Activities
Testing Assurance Activities: The purpose of these tests is to confirm that the TOE appropriately handles connection to peer servers that support and do not support mutual authentication. Test 1: The evaluator shall establish a connection to a peer server that is not configured for mutual authentication (i.e. does not send Server’s Certificate Request (type 13) message). The evaluator observes negotiation of a TLS channel and confirms that the TOE did not send Client’s Certificate message (type 11) during handshake. Test 2: The evaluator shall establish a connection to a peer server with a shared trusted root that is configured for mutual authentication (i.e. it sends Server’s Certificate Request (type 13) message). The evaluator observes negotiation of a TLS channel and confirms that the TOE responds with a non-empty Client’s Certificate message (type 11) and Certificate Verify (type 15) messages. Testing Assurance Activities Details/Results: Test 1: In test case PP-17P, the evaluator configured a custom test tool to act as a TLS server configured for non-mutual authentication. The evaluator then captured TLS traffic between the TOE and the TLS Tool. After reviewing the traffic capture, the evaluator did not observe any TOE’s certificate message (type 11) during its TLS handshake with the TLS tool.
Test 2: In test case PP-17P, the evaluator configured a custom test tool to act as a TLS server and configured to require mutual authentication. The evaluator then captured TLS traffic between the TOE and the TLS Tool. After reviewing the traffic capture, the evaluator observed the TLS Tool’s Certificate Request (type 13) message sent to the TOE’s and confirmed that the TOE sent a certificate message (type 11) and Certificate verify (type 15) message during its TLS handshake with the TLS tool
2.5 FCS_NTP_EXT.1 NTP Protocol
2.5.1 FCS_NTP_EXT.1.1
2.5.1.1 TSS Assurance Activities
TSS Assurance Activities: The evaluator shall examine the TSS to ensure identifies the version of NTP supported, how it is implemented and what approach the TOE uses to ensure the timestamp it receives from an NTP timeserver (or NTP peer) is from an authenticated source and the integrity of the time has been maintained.
51 of 91 Dell Networking Platforms Assurance Activity Report
TSS Implementation Details/Results: The evaluator examined the corresponding TSS section and concluded that the TOE sends NTP version 4 packets, it implements the NTPD reference clock implementation and the TOE uses SHA1 hash algorithm to ensure the timestamp it receives from an NTP timeserver is from an authenticated source and the integrity of the time has been maintained.
2.5.1.2 Guidance Assurance Activities
Guidance Assurance Activities: The evaluator shall examine the guidance documentation to ensure it provides the administrator instructions as how to configure the version of NTP supported, how to configure multiple NTP servers for the TOE’s time source and how to configure the TOE to use the method(s) that are selected in the ST. Guidance Assurance Activities Details/Results: The Evaluator examined the CC Guide, Appendix F: NTP, page 90 and confirmed that the guide contains instructions on how to configure the NTP client on the TOE, with a specific NTP version 4 and sha1 hashing algorithm for every NTP server. The Appendix F states that the TOE supports the configuration of multiple timeserving hosts. The Appendix F mentions all the commands to configure the hashing keys
2.5.1.3 Testing Assurance Activities
Testing Assurance Activities: The version of NTP selected in element 1.1 and specified in the ST shall be verified by observing establishment of a connection to an external NTP server known to be using the specified version(s) of NTP. This may be combined with tests of other aspects of FCS_NTP_EXT.1 as described below.
Testing Assurance Activities Details/Results: As part of test case PP-18, the evaluator configured the TOE to use NTPv4 when communication with the NTP server, then observed a Wireshark traffic and confirmed consistency with how it is configured.
2.5.2 FCS_NTP_EXT.1.2
2.5.2.1 TSS Assurance Activities
TSS Assurance Activities: None
TSS Implementation Details/Results: N/A
2.5.2.2 Guidance Assurance Activities
Guidance Assurance Activities: For each of the secondary selections made in the ST, the evaluator shall examine the guidance document to ensure it instructs the administrator how to configure the TOE to use the algorithms that support the authenticity of the timestamp and/or how to configure the TOE to use the protocols that ensure the integrity of the timestamp. Guidance Assurance Activities Details/Results: The evaluator examined the CC guide and confirmed that Appendix F, Configuring an Authentication Key for NTP traffic, page 90 contains the required command to configure the SHA1 hashing algorithm that used to ensure the integrity and authenticity of the timestamped NTP packets.
52 of 91 Dell Networking Platforms Assurance Activity Report
2.5.2.3 Testing Assurance Activities
Testing Assurance Activities: The cryptographic algorithms selected in element 1.2 and specified in the ST will have been specified in an FCS_COP SFR and tested in the accompanying Evaluation Activity for that SFR. Likewise, the cryptographic protocol selected in in element 1.2 and specified in the ST will have been specified in an FCS SFR and tested in the accompanying Evaluation Activity for that SFR.
(1) [Conditional] If the message digest algorithm is claimed in element 1.2, the evaluator will change the message digest algorithm used by the NTP server in such a way that new value does not match the configuration on the TOE and confirms that the TOE does not synchronize to this time source. (2) The evaluator shall use a packet sniffer to capture the network traffic between the TOE and the NTP server. The evaluator uses the captured network traffic, to verify the NTP version, to observe time change of the TOE and uses the TOE’s audit log to determine that the TOE accepted the NTP server’s timestamp update.
(3) The captured traffic is also used to verify that the appropriate message digest algorithm was used to authenticate the time source and/or the appropriate protocol was used to ensure integrity of the timestamp that was transmitted in the NTP packets.
Testing Assurance Activities Details/Results: As part of the test case PP-18: (1) The evaluator configured the NTP server to use sha1 hash algorithm then configured the TOE to use the MD5 hashing algorithm with specific key when communicating with the NTP server. The evaluator observed that the TOE lost time synchronization and generated an error message.
(2) The evaluator configured the TOE to use the correct hash algorithm and the correct key to communicate with a specific NTP server and captured network traffic using the Wireshark tool.
(3) The evaluator examined traffic captured on both the positive and negative testing of NTP. Verified and confirmed that the TOE used the configured NTP version, the appropriate message digest algorithm sha1 and observed the TOE’s clock synchronized with the NTP server.
2.5.3 FCS_NTP_EXT.1.3
2.5.3.1 TSS Assurance Activities
TSS Assurance Activities: None
TSS Implementation Details/Results: N/A
2.5.3.2 Guidance Assurance Activities
Guidance Assurance Activities: The evaluator shall examine the guidance documentation to ensure it provides the administrator instructions as how to configure the TOE to not accept broadcast and multicast NTP packets that would result in the timestamp being updated. Guidance Assurance Activities Details/Results:
53 of 91 Dell Networking Platforms Assurance Activity Report
The CC guide, Appendix F, describes the default TOE behavior toward broadcast and multicast NTP packets sent by a NTP server and includes instructions on how to change it.
2.5.3.3 Testing Assurance Activities
Testing Assurance Activities: The evaluator shall configure NTP server(s) to support periodic time updates to broadcast and multicast addresses. The evaluator shall confirm the TOE is configured to not accept broadcast and multicast NTP packets that would result in the timestamp being updated. The evaluator shall check that the time stamp is not updated after receipt of the broadcast and multicast packets.
Testing Assurance Activities Details/Results: As part of the test case PP-18, the evaluator configured the NTP server to send periodic time updates to the local network broadcast address and to the multicast address 224.0.1.1, and then the evaluator confirmed that the TOE did not synchronize its clock with the NTP server clock. The evaluator confirmed the behavior of the TOE as mentioned in the CC guide, which states that, by default, the TOE does not accept NTP broadcast and multicast time stamps.
2.5.4 FCS_NTP_EXT.1.4
2.5.4.1 TSS Assurance Activities
TSS Assurance Activities: None TSS Implementation Details/Results: N/A
2.5.4.2 Guidance Assurance Activities
Guidance Assurance Activities: None Guidance Assurance Activities Details/Results: N/A
2.5.4.3 Testing Assurance Activities
Testing Assurance Activities: None Testing Assurance Activities Details/Results: N/A
2.6 Identification and Authentication (FIA)
2.6.1 FIA_AFL.1 Authentication Failure Management
2.6.1.1 TSS Assurance Activities
TSS Assurance Activities: (1) The evaluator shall examine the TSS to determine that it contains a description, for each supported method for remote administrative actions, of how successive unsuccessful authentication attempts are detected and tracked.
(2) The TSS shall also describe the method by which the remote administrator is prevented from successfully logging on to the TOE, and the actions necessary to restore this ability.
54 of 91 Dell Networking Platforms Assurance Activity Report
(3) The evaluator shall examine the TSS to confirm that the TOE ensures that authentication failures by remote administrators cannot lead to a situation where no administrator access is available, either permanently or temporarily (e.g. by providing local logon which is not subject to blocking). TSS Implementation Details/Results: (1) The ST, Section 7.3 states that for remote and local CLI the account will be locked out after a configurable unsuccessful authentication attempts within a range of 1 to 16 attempts. In both instances, once the user is locked out, the user would have to wait a configurable time period ranges from one to 1440 minutes before attempting to log back into the device.
(2) The ST, Section 7.3 states that once locked out of the account, the remote administrator would be required to wait for a configurable lockout time before attempting to log back into the device. Alternatively, an authorized administrator can manually unlock the user’s account.
(3) The evaluator confirmed from ST, Section 7.3 that the TOE ensures that authentication failures by remote administration cannot lead to a situation where no administrator access is available, by distinguishing between local and remote login attempts.
2.6.1.2 Guidance Assurance Activities
Guidance Assurance Activities: (1) The evaluator shall examine the guidance documentation to ensure that instructions for configuring the number of successive unsuccessful authentication attempts and time period (if implemented) are provided, and that the process of allowing the remote administrator to once again successfully log on is described for each “action” specified (if that option is chosen). If different actions or mechanisms are implemented depending on the secure protocol employed (e.g., TLS vs. SSH), all must be described.
(2) The evaluator shall examine the guidance documentation to confirm that it describes, and identifies the importance of, any actions that are required in order to ensure that administrator access will always be maintained, even if remote administration is made permanently or temporarily unavailable due to blocking of accounts as a result of FIA_AFL.1. Guidance Implementation Details/Results: (1) The CC Guide, Section 5, Setting Up The Common Criteria Configuration, Configuring the Login Lockout Period, page 33 provides guidance on configuring the lockout mechanism and time required to wait until the administrator can log back into the device.
(2) The CC Guide, Section 5, Setting Up the Common Criteria Configuration, Configuring Console and Terminal Lines, page 34, provides details on maintaining separate timeout period for the local CLI and remote SSH administration. Based on this description the evaluator concludes that even if remote administrators are locked out it would not affect local administration of the TOE and such design ensures that administrative access is always maintained.
55 of 91 Dell Networking Platforms Assurance Activity Report
2.6.1.3 Testing Assurance Activities
Testing Assurance Activities:
The evaluator shall perform the following tests for each method by which remote administrators access the TOE (e.g. any passwords entered as part of establishing the connection protocol or the remote administrator application):
Test 1: The evaluator shall use the operational guidance to configure the number of successive unsuccessful authentication attempts allowed by the TOE (and, if the time period selection in FIA_AFL.1.2 is included in the ST, then the evaluator shall also use the operational guidance to configure the time period after which access is re-enabled). The evaluator shall test that once the authentication attempts limit is reached, authentication attempts with valid credentials are no longer successful. Test 2: After reaching the limit for unsuccessful authentication attempts as in Test 1 above, the evaluator shall proceed as follows. If the administrator action selection in FIA_AFL.1.2 is included in the ST then the evaluator shall confirm by testing that following the operational guidance and performing each action specified in the ST to re-enable the remote administrator’s access results in successful access (when using valid credentials for that administrator).
If the time period selection in FIA_AFL.1.2 is included in the ST then the evaluator shall wait for just less than the time period configured in Test 1 and show that an authorisation attempt using valid credentials does not result in successful access. The evaluator shall then wait until just after the time period configured in Test 1 and show that an authorisation attempt using valid credentials results in successful access. Testing Implementation Details/Results: Test 1: In test case PP-15, the evaluator followed the CC Guide, Section 5, Setting Up The Common Criteria Configuration, Configuring the Login Lockout Period, page 33 to configure the local and remote CLI timeout to 3 unsuccessful attempts and the lockout time period to 2 minutes. The evaluator observed that after logging in with invalid passwords 4 times, the login attempt failed even with valid credentials.
Test 2: In test case PP-15, the administrator used another administrator account to unlock the locked account, then tried to login with the same account with a valid credential, the evaluator observed a successful access
In test case PP-15, the evaluator followed the same steps as in Test 1 to end up with a locked administrator account, and then waited for just less than the time period configured in Test 1 and observed that an authorization attempt using valid credentials does not result in successful access. The evaluator then waited again until just after the time-period configured in Test 1 and observed that an authorization attempt using valid credentials results in successful access.
2.6.2 FIA_PMG_EXT.1 Password Management
2.6.2.1 TSS Assurance Activities
TSS Assurance Activities: None TSS Implementation Details/Results: N/A
56 of 91 Dell Networking Platforms Assurance Activity Report
2.6.2.2 Guidance Assurance Activities
Guidance Assurance Activities: The evaluator shall examine the guidance documentation to determine that it: a) identifies the characters that may be used in passwords and provides guidance to security administrators on the composition of strong passwords, and b) provides instructions on setting the minimum password length and describes the valid minimum password lengths supported. Guidance Implementation Details/Results: The CC Guide, Section 5, Setting Up the Common Criteria Configuration, Configuring Password Attributes, page 32 provides guidance to security administrators on setting the password complexity.
The CC Guide, Section 5, Setting Up the Common Criteria Configuration, Create a Password Policy that Matches Your Organization, page 32, details how to set the minimum password length to 15 characters.
The CC Guide, Section 5, Setting Up the Common Criteria Configuration, Create a Password Policy that Matches Your Organization, page 32, details how to set the password composition rules.
The CC Guide, Section 5, Setting Up the Common Criteria Configuration, Create a Password Policy that Matches Your Organization, page 32, details the Password Complexity:
Require Uppercase: When enabled, requires at least one uppercase alphabet character in the administrator password. This is enabled by default.
Requires Numbers: When enabled, this requires at least one integer to be present in the administrator password. This is enabled by default.
Requires Special Characters: When enabled, this requires at least one special character to be present in the administrator. (i.e.:’ “!@#$%^&*()_+{}|:<>-=[]\;',./.)
2.6.2.3 Testing Assurance Activities
Testing Assurance Activities: The evaluator shall perform the following tests. Test 1: The evaluator shall compose passwords that either meet the requirements, or fail to meet the requirements, in some way. For each password, the evaluator shall verify that the TOE supports the password. While the evaluator is not required (nor is it feasible) to test all possible compositions of passwords, the evaluator shall ensure that all characters, and a minimum length listed in the requirement are supported, and justify the subset of those characters chosen for testing.
57 of 91 Dell Networking Platforms Assurance Activity Report
Testing Implementation Details/Results: Test 1: The TOE supports password-based authentication. As part of test case PP-3, the evaluator tested all of the password attributes required by the PP, including negative tests. The evaluator tested the following rules for password based authentication: Passwords composed from the following character sets: a-z, A-Z, integers: 0-9, and special characters: “!@#$%^&*()_+{}|:"<>-=[]\;',./` Minimum password length of 15 characters; Password composition rules specifying minimum number of lower, upper, numeric and special character The evaluator set the minimum password length to 15 characters and observed that the set value took effect. This was also tested out for password characters less than 15 characters, and it was noted that an error message stating that a minimum of 15 characters were required for passwords was produced. Password length greater than 15 characters and password length equal to 15 characters were also tested. Throughout testing, the evaluator also tested both unsupported and supported characters.
2.6.3 FIA_UIA_EXT.1 User Identification and Authentication
2.6.3.1 TSS Assurance Activities
TSS Assurance Activities: (1) The evaluator shall examine the TSS to determine that it describes the logon process for each logon method (local, remote (HTTPS, SSH, etc.)) supported for the product. This description shall contain information pertaining to the credentials allowed/used, any protocol transactions that take place, and what constitutes a “successful logon”.
(2) The evaluator shall examine the TSS to determine that it describes which actions are allowed before user identification and authentication. The description shall cover authentication and identification for local and remote TOE administration. TSS Implementation Details/Results: (1) The ST, Section 7.3, describes that the CLI is accessed over the serial console port for local logon. Local management supports password-based authentication. The ST, Section 7.3 describes that for remote administration, implemented as a CLI over SSH, the TOE can be configured to authenticate using public key mechanism (RSA), or password-based, or both. For local administration, only password-based authentication is supported. When RSA authentication is used, the TOE checks presented public key against authorized keys database and verifies possession of a private key by negotiating secure channel using this public key. When both password and certificate are presented, the TOE use public key during handshake negotiation followed by a password verification
(2) The ST, Section 7.3 details that a username and password are required to logon to the TOE, and once the username and password have been validated by the system then access is allowed. If an incorrect username and password are entered then access is denied. Logging into the TOE with the correct credentials constitutes a successful logon. For RSA authentication, the TOE validates the presented public key against authorized keys database and verifies possession of a private key by negotiating secure channel using this public key.
58 of 91 Dell Networking Platforms Assurance Activity Report
2.6.3.2 Guidance Assurance Activities
Guidance Assurance Activities: (1) The evaluator shall examine the guidance documentation to determine that any necessary preparatory steps (e.g., establishing credential material such as pre- shared keys, tunnels, certificates, etc.) to logging in are described. (2) For each supported the login method, the evaluator shall ensure the guidance documentation provides clear instructions for successfully logging on. (3) If configuration is necessary to ensure the services provided before login are limited, the evaluator shall determine that the guidance documentation provides sufficient instruction on limiting the allowed services. Guidance Implementation Details/Results: (1) The CC Guide, Section 2, Configuration Fundamentals, pagea 10-11 detail on how to access the CLI command line locally and remotely to enable password based authentication.
(2) The CC Guide, Section 5, Setting Up the Common Criteria Configuration, Configuring Security, Enabling RSA Authentication, and Enabling SSH and Disabling Telnet, Page 31, provides instructions on how to successfully login through SSH authentication. The section 5, Setting Up the Common Criteria Configuration, Configuring Logging, section audit Entries page 40, provides samples of audit logs of successful and unsuccessful logging through local console or remote CLI.
(3) The ST, Section 7.3 states that the TOE requires any user to be identified and authenticated before any management action, so no necessary configuration is needed to limit the allowed services.
2.6.3.3 Testing Assurance Activities
Testing Assurance Activities: The evaluator shall perform the following tests for each method by which administrators access the TOE (local and remote), as well as for each type of credential supported by the login method: Test 1: The evaluator shall use the guidance documentation to configure the appropriate credential supported for the login method. For that credential/login method, the evaluator shall show that providing correct I&A information results in the ability to access the system, while providing incorrect information results in denial of access. Test 2: The evaluator shall configure the services allowed (if any) according to the guidance documentation, and then determine the services available to an external remote entity. The evaluator shall determine that the list of services available is limited to those specified in the requirement. Test 3: For local access, the evaluator shall determine what services are available to a local administrator prior to logging in, and make sure this list is consistent with the requirement. Testing Implementation Details/Results: Test 1: The evaluator followed the user guidance and used a valid username and password to successfully login to the TOE. The evaluator used an invalid username and password and observed that access to the TOE was denied. This was carried out for both local (Console CLI) and remote access (CLI via SSH). See test case PP-4 for valid local access, test case PEN-3 for invalid local access, and test case PP-14B for valid and invalid remote access. Test 2: The evaluator observed that for both local (Console CLI) and remote access (CLI via SSH) there are no services available prior to logging in. Test 3: The evaluator observed that for local access, the login prompt is displayed after establishing a connection, with no other services permitted. Successful login was indicated by a command line prompt, while a failed login returned the operator to the user name login prompt. Thus there are no
59 of 91 Dell Networking Platforms Assurance Activity Report
actions permitted to the user without prior successful identification and authentication to the TOE. See test case PEN-3 for invalid local access.
2.6.4 FIA_UAU_EXT.2 Password-based Authentication Mechanism
Evaluation Activities for this requirement are covered under those for FIA_UIA_EXT.1. If other authentication mechanisms are specified, the evaluator shall include those methods in the activities for FIA_UIA_EXT.1.
2.6.5 FIA_UAU.7 Protected Authentication Feedback
2.6.5.1 TSS Assurance Activities
TSS Assurance Activities: None TSS Implementation Details/Results: N/A
2.6.5.2 Guidance Assurance Activities
Guidance Assurance Activities: None Guidance Implementation Details/Results: N/A
2.6.5.3 Testing Assurance Activities
Testing Assurance Activities: The evaluator shall perform the following test for each method of local login allowed: Test 1: The evaluator shall locally authenticate to the TOE. While making this attempt, the evaluator shall verify that at most obscured feedback is provided while entering the authentication information. Testing Implementation Details/Results: Test 1: As part of the PP-7 testing, the evaluator authenticated locally to the TOE and observed that the feedback was obscured when entering the authentication information.
2.6.6 FIA_X509_EXT.1/Rev X.509 Certificate Validation
2.6.6.1 TSS Assurance Activities
TSS Assurance Activities: (1) The evaluator shall ensure the TSS describes where the check of validity of the certificates takes place, and that the TSS identifies any of the rules for extendedKeyUsage fields (in FIA_X509_EXT.1.1) that are not supported by the TOE (i.e. where the ST is therefore claiming that they are trivially satisfied).
It is expected that revocation checking is performed when a certificate is used in an authentication step and when performing trusted updates (if selected). It is not necessary to verify the revocation status of X.509 certificates during power-up self-tests (if the option for using X.509 certificates for self-testing is selected).
(2) The TSS shall describe when revocation checking is performed and on what certificates. If the revocation checking during authentication is handled differently depending on whether a full
60 of 91 Dell Networking Platforms Assurance Activity Report
certificate chain or only a leaf certificate is being presented, any differences must be summarized in the TSS section and explained in the Guidance. It is expected that revocation checking is performed when a certificate is used in an authentication step. It is expected that revocation checking is performed on both leaf and intermediate CA certificates when a leaf certificate is presented to the TOE as part of the certificate chain during authentication. Revocation checking of any CA certificate designated a trust anchor is not required. It is not sufficient to perform a revocation check of a CA certificate only when it is loaded onto the device. TSS Implementation Details/Results: (1) The ST, Section 7.3 describes that the TOE supports the use of X.509v3 certificates as defined by RFC 5280 to authenticate connections with authorized IT entities. The TSS describes in general terms the process of certificate validation and extension checking, explicitly mentioning validating extendedKeyUsage field and checking BasicConstraints extension. This description also includes acceptable values for extendedKeyUsage: serverAuthentication for IT Servers, OCSPSigning for OCSP responder.
(2) The ST, Section 7.3, describes the supported certificate path validation algorithms as: OCSP. The TSS explains that revocation checking performed on identity certificates presented to the TOE and all CA certificates in the chain up to the Root CA. The TSS also mentions that when loading signed CSR the revocation checking is also performed. The ST, Section 7.3 mentions that the TOE constructs the trust chain based on CA certificates in its trust store and as a result performs complete revocation chain regardless whether full chain or just leaf certificate is presented.
2.6.6.2 Guidance Assurance Activities
Guidance Assurance Activities: None Guidance Implementation Details/Results: N/A
2.6.6.3 Testing Assurance Activities
Testing Assurance Activities: The evaluator shall demonstrate that checking the validity of a certificate is performed when a certificate is used in an authentication step or when performing trusted updates (if FPT_TUD_EXT.2 is selected). It is not sufficient to verify the status of a X.509 certificate only when it is loaded onto the TOE. It is not necessary to verify the revocation status of X.509 certificates during power-up self-tests (if the option for using X.509 certificates for self-testing is selected).
The evaluator shall perform the following tests for FIA_X509_EXT.1.1/Rev. These tests must be repeated for each distinct security function that utilizes X.509v3 certificates. For example, if the TOE implements certificate-based authentication with IPSEC and TLS, then it shall be tested with each of these protocols: Test 1a: The evaluator shall present the TOE with a valid chain of certificates (terminating in a trusted CA certificate) as needed to validate the leaf certificate to be used in the function, and shall use this chain to demonstrate that the function succeeds. Test 1a shall be designed in a way that the chain can be 'broken' in Test 1b by either being able to remove the trust anchor from the TOEs trust store, or by setting up the trust store in a way that at least one intermediate CA certificate needs to be provided, together with the leaf certificate from outside the TOE, to complete the chain (e.g. by storing only the root CA certificate in the trust store). Test 1b: The evaluator shall then 'break' the chain used in Test 1a by either removing the trust anchor in the TOE's trust store used to terminate the chain, or by removing one of the intermediate CA certificates (provided together with the leaf certificate in Test 1a) to complete the chain. The evaluator shall show that an attempt to validate this broken chain fails.
61 of 91 Dell Networking Platforms Assurance Activity Report
Test 2: The evaluator shall demonstrate that validating an expired certificate results in the function failing. Test 3: The evaluator shall test that the TOE can properly handle revoked certificates-–conditional on whether CRL or OCSP is selected; if both are selected, then a test shall be performed for each method. The evaluator shall test revocation of the peer certificate and revocation of the peer intermediate CA certificate i.e. the intermediate CA certificate should be revoked by the root CA. The evaluator shall ensure that a valid certificate is used, and that the validation function succeeds. The evaluator then attempts the test with a certificate that has been revoked (for each method chosen in the selection) to ensure when the certificate is no longer valid that the validation function fails. Revocation checking is only applied to certificates that are not designated as trust anchors. Therefore the revoked certificate(s) used for testing shall not be a trust anchor. Test 4: If OCSP is selected, the evaluator shall configure the OCSP server or use a man-in-the-middle tool to present a certificate that does not have the OCSP signing purpose and verify that validation of the OCSP response fails. If CRL is selected, the evaluator shall configure the CA to sign a CRL with a certificate that does not have the cRLsign key usage bit set, and verify that validation of the CRL fails. Test 5: The evaluator shall modify any byte in the first eight bytes of the certificate and demonstrate that the certificate fails to validate. (The certificate will fail to parse correctly.) Test 6: The evaluator shall modify any byte in the last byte of the certificate and demonstrate that the certificate fails to validate. (The signature on the certificate will not validate.) Test 7: The evaluator shall modify any byte in the public key of the certificate and demonstrate that the certificate fails to validate. (The hash of the certificate will not validate.)
The evaluator shall perform the following tests for FIA_X509_EXT.1.2/Rev. The tests described must be performed in conjunction with the other certificate services assurance activities, including the functions in FIA_X509_EXT.2.1/Rev. The tests for the extendedKeyUsage rules are performed in conjunction with the uses that require those rules. Where the TSS identifies any of the rules for extendedKeyUsage fields (in FIA_X509_EXT.1.1) that are not supported by the TOE (i.e. where the ST is therefore claiming that they are trivially satisfied) then the associated extendedKeyUsage rule testing may be omitted.
The goal of the following tests is to verify that the TOE accepts a certificate as a CA certificate only if it has been marked as a CA certificate by using basicConstraints with the CA flag set to True (and implicitly tests that the TOE correctly parses the basicConstraints extension as part of X509v3 certificate chain validation).
For each of the following tests the evaluator shall create a chain of at least three certificates: a self-signed root CA certificate, an intermediate CA certificate and a leaf (node) certificate. The properties of the certificates in the chain are adjusted as described in each individual test below (and this modification shall be the only invalid aspect of the relevant certificate chain). Test 1: The evaluator shall ensure that at least one of the CAs in the chain does not contain the basicConstraints extension. The evaluator confirms that the TOE rejects such a certificate at one (or both) of the following points: (i) as part of the validation of the leaf certificate belonging to this chain; (ii) when attempting to add a CA certificate without the basicConstraints extension to the TOE’s trust store (i.e. when attempting to install the CA certificate as one which will be retrieved from the TOE itself when validating future certificate chains). Test 2: The evaluator shall ensure that at least one of the CA certificates in the chain has a basicConstraints extension in which the CA flag is set to FALSE. The evaluator confirms that the TOE rejects such a certificate at one (or both) of the following points: (i) as part of the validation of the leaf certificate belonging to this chain; (ii) when attempting to add a CA certificate with the CA flag set to FALSE to the TOE’s trust store (i.e. when attempting to install the CA certificate as one which will be retrieved from the TOE itself when validating future certificate chains).
62 of 91 Dell Networking Platforms Assurance Activity Report
Testing Implementation Details/Results: For the following test cases, two hierarchical CA structures were used: Root CA ->Intermediate CA1 --> end entity certificate for positive testing Rogue CA -> end entity certificate for negative testing The TOE supports only OCSP certificate revocation checking. Each CA had a corresponding OCSP responder to perform revocation checking. For positive testing 2 CA certificates (RootCA->intCA1) were added to the TOE’s trusted certificate store.
FIA_X509_EXT.1.1/Rev: Test 1a: In test case PP-10A, the evaluator confirmed that the RootCA->intCA1 certificate chain was loaded into the TOE’s certificate store. The evaluator successfully installed the TOE’s certificate. Test 1b: The evaluator then removed the intCA1 from the TOE’s trust store, tried to install the TOE’s leaf certificate and observed that the validation of the TOE certificate once again failed due to the absence of the intermediate CA certificate. Test 2: In test case PP-10B, the evaluator used TLS handshake to present a valid but expired 2048-bit RSA X509v3 leaf certificate signed by intCA1. The evaluator then attempted to re-establish connection, which resulted in the TLS handshake failing and the TOE producing “TLS connection failed – unable to establish connection: certificate verify failed” message. Test 3: The TOE implements OCSP protocol to perform revocation checking. As part of test case PP-10C, the evaluator used TLS handshake to present a structurally valid 2048-bit RSA X509v3 leaf certificate signed by intCA1 that was revoked and observed that the handshake failed. The evaluator repeated this test by revoking intCA1 and observer that the handshake failed. Test 4: The TOE implements OCSP protocol to perform revocation checking. As part of test case PP-10D, the evaluator configured the OCSP responder associated with intCA1 with a valid RSA X509v3certificate that did not have appropriate X509v3 Extended Key Usage entry (OCSP Signing) and verified that the revocation check failed. Test 5: In test case PP-10E, the evaluator configured the test tool to present an otherwise valid RSA X509v3 certificate that contained a modified byte in the first eight bytes of the certificate. The evaluator observed TLS handshake and confirmed that the certificate validation failed and the TOE produced :”TLS connection failed – unable to establish connection: wrong tag”. Test 6: In test case PP-10F, the evaluator configured the test tool to present an otherwise valid RSA X509v3 certificate that contained a modified byte in the last eight bytes of the certificate and observed that the certificate validation failed. The evaluator observed TLS handshake and the TOE produced :”TLS connection failed – unable to establish connection: block type is not 01. Test 7: In test case PP-10G, the evaluator configured test tool to present an otherwise valid RSA X509v3 certificate that contained a modified byte in the public key of the certificate. The evaluator observed TLS handshake and confirmed that the certificate validation failed and the TOE produced :”TLS connection failed – unable to establish connection: bad signature”. FIA_X509_EXT.1.2/Rev: Test 1: In test case PP-10H, the evaluator attempted to install an intermediate CA certificate that was missing the basicConstraints extension. The evaluator observed that this certificate failed the format check by the TOE and an error was generated. Test 2: In test case PP-10I, the evaluator attempted to install an intermediate CA certificate that had the CA flag in the basicConstraints extension set to FALSE. The evaluator observed that this certificate failed the format check by the TOE and an error was generated.
63 of 91 Dell Networking Platforms Assurance Activity Report
2.6.7 FIA_X509_EXT.2 X.509 Certificate Authentication
2.6.7.1 TSS Assurance Activities
TSS Assurance Activities: (1) The evaluator shall check the TSS to ensure that it describes how the TOE chooses which certificates to use, and any necessary instructions in the administrative guidance for configuring the operating environment so that the TOE can use the certificates. (2) The evaluator shall examine the TSS to confirm that it describes the behaviour of the TOE when a connection cannot be established during the validity check of a certificate used in establishing a trusted channel. The evaluator shall verify that any distinctions between trusted channels are described. If the requirement that the administrator is able to specify the default action, then the evaluator shall ensure that the guidance documentation contains instructions on how this configuration action is performed. TSS Implementation Details/Results: (1) The ST, Section 7.3 details that the TOE uses X.509 v3 certificates as defined by RFC 5280 to mutually authenticate TLS connections. The TOE is configured with only one client certificate for the mutual authentication at any given time.
(2) The ST, Section 7.3 details that when X509 certificate are presented during TLS handshake, the TOE validates presented certificate and the entire trust chain by performing revocation checks. The revocation check is performed by sending an OCSP request to a trusted OCSP responder and verifying signed response. If connection to OCSP server cannot be established, the administrator can configure default behavior and determine whether to accept the certificate in such cases. The list of OCSP responders may be manually configured or specified in a CA certificate in the authorityInfoAccess extension.
2.6.7.2 Guidance Assurance Activities
Guidance Assurance Activities: If the requirement that the administrator is able to specify the default action [when a connection cannot be established during the validity check of a certificate], then the evaluator shall ensure that the guidance documentation contains instructions on how this configuration action is performed. Guidance Implementation Details/Results: The CC Guide, Appendix B X.509v3, section “Online Certificate Status Protocol (OCSP)” states, “In a scenario where all OCSP responders are unreachable, the switch accepts the certificate. This action is the default behavior. You can also configure an alternate system behavior when all OCSP responders are unreachable.”
The CC Guide, Appendix B X.509v3, section “Configuring Revocation Behavior”, contains instructions on how this configuration action is performed.
64 of 91 Dell Networking Platforms Assurance Activity Report
2.6.7.3 Testing Assurance Activities
Testing Assurance Activities: The evaluator shall perform the following test for each trusted channel: (1) The evaluator shall demonstrate that using a valid certificate that requires certificate validation checking to be performed in at least some part by communicating with a non-TOE IT entity. (2) The evaluator shall then manipulate the environment so that the TOE is unable to verify the validity of the certificate, and observe that the action selected in FIA_X509_EXT.2.2 is performed. If the selected action is administrator-configurable, then the evaluator shall follow the guidance documentation to determine that all supported administrator-configurable options behave in their documented manner. Testing Implementation Details/Results: In order to verify a certificate, the TOE first performs a validity check on the format of the certificate, then checks trust against its internal certificate store, then performs revocation checking on all of the certificates in the chain using OCSP. For the following test cases, the hierarchical CA structure Root CA - >Intermediate CA1 -> end entity certificate was used. (1) In test case PP-11A, the evaluator configured mutually authenticated trusted channel with the syslog server and observer syslog authenticating with X.509v3 certificate and the TOE performing revocation checking. Throughout test cases, PP-10A to PP-10H and PP-11B the evaluator manipulated the environment so the TOE was unable to verify validity, trust, or revocation status of the certificate and observed that appropriate responses.
(2) The TOE supports two administrator-configurable behaviors in case OCSP responder is unavailable – accept and reject. In test case PP-11B, the evaluator disabled the OCSP responder associated with Intermediate CA1 and attempted to establish a connection with the external syslog server. When the TOE was configured to reject, connection was denied. When the TOE was configured to accept, connection succeeded. This CC Guide was closely followed during OCSP testing and was found to be an accurate and useful source of information about TOE.
2.6.8 FIA_X509_EXT.3 Extended: X509 Certificate Requests
2.6.8.1 TSS Assurance Activities
TSS Assurance Activities: If the ST author selects "device-specific information", the evaluator shall verify that the TSS contains a description of the device-specific fields used in certificate requests. TSS Implementation Details/Results: The ST author has not selected “device-specific information”; therefore, this activity is not applicable.
2.6.8.2 Guidance Assurance Activities
Guidance Assurance Activities: The evaluator shall check to ensure that the guidance documentation contains instructions on requesting certificates from a CA, including generation of a Certificate Request Message. If the ST author selects "Common Name", "Organization", "Organizational Unit", or "Country", the evaluator shall ensure that this guidance includes instructions for establishing these fields before creating the Certification Request. Guidance Implementation Details/Results: The CC Guide, Setting Up the Common Criteria Configuration, Configuring X.509v3, page 48-51 contains instructions on requesting certificates from a CA, including generation of a Certificate Request Message.
65 of 91 Dell Networking Platforms Assurance Activity Report
The CC Guide, Section 5 Setting Up the Common Criteria Configuration, Information about Creating Certificate Signing Requests (CSR), page 48-51 contains instructions for establishing
2.6.8.3 Testing Assurance Activities
Testing Assurance Activities: The evaluator shall perform the following tests: Test 1: The evaluator shall use the guidance documentation to cause the TOE to generate a certificate request. The evaluator shall capture the generated message and ensure that it conforms to the format specified. The evaluator shall confirm that the certificate request provides the public key and other required information, including any necessary user-input information. Test 2: The evaluator shall demonstrate that validating a response message to a certificate Request without a valid certification path results in the function failing. The evaluator shall then load a certificate or certificates as trusted CAs needed to validate the certificate response message, and demonstrate that the function succeeds. Testing Implementation Details/Results: The TOE supports mutual X.509v3 RSA-based certificate authentication. To generate a valid X509 certificate the TOE first generates RSA key pair, then uses the public key to produce a Certificate Signing Request (CSR). Once the CSR is signed by the CA (intermediate CA1 in all test cases), the resulting certificate is imported back into the TOE and used as the TOE’s X.509v3 certificate. Test 1: As part of test case PP-12, the evaluator followed guidance to generate a CSR. The CSR was analyzed to ensure that it conformed to the RFC 2986 and included the TOE’s public key and other relevant information. Test 2: As part of test case PP-10A, the evaluator created a test scenario where the TOE attempted to validate a signed certificate without a valid certification path (i.e. intCA1 was missing from the TOE), which resulted in a failure. The evaluator then loaded intCA1’s certificate containing the verification public key that signed the certificate being questioned, and observed that the certificate validation then succeeded. The evaluator then deleted the TOE’s certificate followed by intCA1’s certificate, attempted to install the TOE’s certificate (requiring a validation) and observed that the function failed.
66 of 91 Dell Networking Platforms Assurance Activity Report
2.7 Security Management (FMT)
2.7.1 FMT_MOF.1/ManualUpdate
2.7.1.1 TSS Assurance Activities
TSS Assurance Activities: There are no specific requirements for non-distributed TOEs. TSS Implementation Details/Results: N/A
2.7.1.2 Guidance Assurance Activities
Guidance Assurance Activities: (1) The evaluator shall examine the guidance documentation to determine that any necessary steps to perform manual update are described. (2) The guidance documentation shall also provide warnings regarding functions that may cease to operate during the update (if applicable). Guidance Implementation Details/Results: (1) CC Guide, Section 4, Upgrade and downgrade the software, page 22, describes all the necessary steps to perform manual upgrade of the TOE, starting from where to get the new or specific TOE firmware image, how to transfer the new image file, verifying the published SHA256 checksum on the TOE and how to install it. (2) The CC guide, Section 4, Upgrade and downgrade the software, page 23, states that to take advantage of the new installed software; you need to reboot the TOE, which means that the new image is not executed until the next reboot. The evaluator conclude that this activity is considered not applicable so not need to have a warning added to the CC guide.
2.7.1.3 Testing Assurance Activities
Testing Assurance Activities: (1) The evaluator shall try to perform the update using a legitimate update image without prior authentication as security administrator (either by authentication as a user with no administrator privileges or without user authentication at all – depending on the configuration of the TOE). The attempt to update the TOE shall fail. (2) The evaluator shall try to perform the update with prior authentication as security administrator using a legitimate update image. This test should pass. This test case should be covered by the tests for FPT_TUD_EXT.1 already. Testing Implementation Details/Results: (1) In test case PP-1B, the evaluator attempted to perform an update using a legitimate update image by authenticating as a user with no administrator privileges. The update was not successful, as the TOE does not allow a user without administrator privileges to perform image updates to the TOE. (2) In test case PP-1B, the evaluator performed the update, with prior authentication as security administrator, using a legitimate update image. The TOE was updated successfully and the update process generated appropriate audit record(s).
67 of 91 Dell Networking Platforms Assurance Activity Report
2.7.2 FMT_MTD.1/CoreData Management of TSF Data
2.7.2.1 TSS Assurance Activities
TSS Assurance Activities: (1) The evaluator shall examine the TSS to determine that, for each administrative function identified in the guidance documentation; those that are accessible through an interface prior to administrator log-in are identified. (2) For each of these functions, the evaluator shall also confirm that the TSS details how the ability to manipulate the TSF data through these interfaces is disallowed for non-administrative users. (3) If the TOE supports handling of X.509v3 certificates and implements a trust store, the evaluator shall examine the TSS to determine that it contains sufficient information to describe how the ability to manage the TOE’s trust store is restricted. TSS Implementation Details/Results: (1) The ST, Section 7.4, details that the TOE requires all users to be successfully be identified and authenticated before permitting any TSF-mediated actions.
(2) The ST v2.9 Section 7.4, details that local or remote user is not allowed to perform the TSF management functions without successful authentication and authorization.
(3) The ST v2.9 Section 7.4, details that only authenticated and authorized users (local or remote) can import CA certificates to the TOE’s trust store.
2.7.2.2 Guidance Assurance Activities
Guidance Assurance Activities: 1. The evaluator shall review the guidance documentation to determine that each of the TSF-data- manipulating functions implemented in response to the requirements of the cPP is identified, and that configuration information is provided to ensure that only administrators have access to the functions. 2. If the TOE supports handling of X.509v3 certificates and provides a trust store, the evaluator shall review the guidance documentation to determine that it provides sufficient information for the administrator to configure and maintain the trust store in a secure way. If the TOE supports loading of CA certificates, the evaluator shall review the guidance documentation to determine that it provides sufficient information for the administrator to securely load CA certificates into the trust store. The evaluator shall also review the guidance documentation to determine that it explains how to designate a CA certificate a trust anchor.
68 of 91 Dell Networking Platforms Assurance Activity Report
Guidance Implementation Details/Results: 1. The TOE supports role-based authentication. Each role has defined set of permissions and based on these permissions the user can manipulate the TSF data. The CC Guide, Section 5, Setting Up the Common Criteria Configuration, Configuring Role-Based Access Control and AAA, Create UserIDs on TOE, Page 36 states that sysadmin user role has full control over the system. The CC Guide, Section Appendix A Role-Based Access Control, System-Defined RBAC User Roles, page 53 details the user roles and the privileges allocated to each of the roles.
Function User Guidance Reference Creating users CC Guide p36 Upgrade / downgrade the TOE software CC Guide p22 Configuring cryptography CC Guide p27 Enabling SSH and Disabling Telnet CC Guide p31 Configuring Password Attributes CC Guide p32 Configuring the Login Lockout Period CC Guide p33 Obscuring Passwords and Keys CC Guide p33 Configuring Console and Terminal Lines CC Guide p33 Configuring Role-Based Access Control and AAA CC Guide p35 Configuring the Hostname CC Guide p37 Configure the Management Port IP Address CC Guide p38 Configuring a Management Route CC Guide p38 Configuring Syslog CC Guide p42 Configuring the System Date and Time CC Guide p43 Configuring the Banner CC Guide p34 Configuring X.509v3 CC Guide p62 Self-Test Failures CC Guide Page 86
2. The evaluator examined the CC Guide, appendix B, Section “X.509 support in Dell Networking OS”, Page 63 and confirmed that the section contains instructions for the administrator to configure and maintain the trust store in a secure way. As the TOE supports loading of CA certificates, the evaluator reviewed Appendix B, Section “Information about installing CA certificates”, and confirmed that it provides sufficient information for the administrator to securely load CA certificate into the trust store.
2.7.2.3 Testing Assurance Activities
Testing Assurance Activities: None Testing Implementation Details/Results: N/A
2.7.3 FMT_MTD.1/CryptoKeys Management of TSF Data
2.7.3.1 TSS Assurance Activities
TSS Assurance Activities: For distributed TOEs see chapter 2.4.1.1. There are no specific requirements TSS Implementation Details/Results: N/A
69 of 91 Dell Networking Platforms Assurance Activity Report
2.7.3.2 Guidance Assurance Activities
Guidance Assurance Activities: None Guidance Assurance Activities: N/A
2.7.3.3 Testing Assurance Activities
Testing Assurance Activities: (1) The evaluator shall try to perform at least one of the related actions (modify, delete, generate/import) without prior authentication as security administrator (either by authentication as a non-administrative user, if supported, or without authentication at all). Attempts to perform related actions without prior authentication should fail. According to the implementation no other users than the Security Administrator might be defined and without any user authentication the user might not be able to get to the point where the attempt to manage cryptographic keys can be executed. In that case it shall be demonstrated that access control mechanisms prevent execution up to the step that can be reached without authentication as Security Administrator.
(2) The evaluator shall try to perform at least one of the related actions with prior authentication as security administrator. This attempt should be successful. Testing Implementation Details/Results: (1) ) The evaluator logging into the TOE using a non-privileged user account (ccoperator1) and confirmed that the non-admin user was not able to successfully execute the management commands like deleting the SSH RSA Key, generating a new key, deleting TOE certificate or generating a new certificate signing request (CSR). Please refer to the test case PP-13 for detailed instructions that were executed to test the requirement. (2) (2) As part of the test case PP-13, the evaluator used a privileged user account (admin account), and was able to successfully delete and generate a new SSH RSA Key. The test case PP-13 satisfies this assurance activities.
2.7.4 FMT_SMF.1 Specification of Management Functions
2.7.4.1 TSS Assurance Activities
TSS Assurance Activities: The evaluator shall examine the TSS and Guidance Documentation to verify they both describe the local administrative interface… Note: TD0408 https://www.niap-ccevs.org/Documents_and_Guidance/view_td.cfm?td_id=418 was applied. TSS Implementation Details/Results: The ST, Section 7.4, describes the local administrative interface as being a directly connected RJ-45 console port.
2.7.4.2 Guidance Assurance Activities
Guidance Assurance Activities: The evaluator shall examine the TSS and Guidance Documentation to verify they both describe the local administrative interface. The evaluator shall ensure the Guidance Documentation includes appropriate warnings for the administrator to ensure the interface is local. Note: TD0408 https://www.niap-ccevs.org/Documents_and_Guidance/view_td.cfm?td_id=418 was applied. Guidance Implementation Details/Results:
70 of 91 Dell Networking Platforms Assurance Activity Report
The CC Guide, Section 2, Configuration Fundamentals, Connecting to the Serial Console Port, page 10, describe the local administrative interface.
2.7.4.3 Testing Assurance Activities
Testing Assurance Activities: The evaluator tests management functions as part of testing the SFRs identified in section 2.4.4. No separate testing for FMT_SMF.1 is required unless one of the management functions in FMT_SMF.1.1 has not already been exercised under any other SFR. Testing Implementation Details/Results: Please refer to the corresponding AA sections according to the list above.
2.7.5 FMT_SMR.2 Restrictions on security roles
2.7.5.1 TSS Assurance Activities
TSS Assurance Activities: None TSS Implementation Details/Results: N/A
2.7.5.2 Guidance Assurance Activities
Guidance Assurance Activities: The evaluator shall review the guidance documentation to ensure that it contains instructions for administering the TOE both locally and remotely, including any configuration that needs to be performed on the client for remote administration. Guidance Implementation Details/Results: The CC Guide, Section 2, Configuration Fundamentals, Accessing the Command Line, pages 10-11 contains instructions on how to administer the TOE locally. The CLI interface is the default initial interface. The CC Guide, Section 2, Configuration Fundamentals, Connecting to the Management Ethernet Port, page 10 details configuration tasks that need to be performed on the client for remote administration.
2.7.5.3 Testing Assurance Activities
Testing Assurance Activities: (1) In the course of performing the testing activities for the evaluation, the evaluator shall use all supported interfaces, although it is not necessary to repeat each test involving an administrative action with each interface. (2) The evaluator shall ensure, however, that each supported method of administering the TOE that conforms to the requirements of this cPP be tested; for instance, if the TOE can be administered through a local hardware interface; SSH; and TLS/HTTPS; then all three methods of administration must be exercised during the evaluation team’s test activities. Testing Implementation Details/Results: (1) The evaluator followed the user guidance to configure the CLI interface for local administration of the TOE. The TOE administered exclusively via CLI that implements both remote and local administration. There is no differences in how the CLI operates regardless of how it is accessed. (2) Throughout the testing, the evaluator followed the user guidance to configure the CLI over SSH for remote administration of the TOE and the CLI over crossover cable for local administration of the TOE.
71 of 91 Dell Networking Platforms Assurance Activity Report
2.8 Protection of the TSF (FPT)
2.8.1 FPT_SKP_EXT.1 Protection of TSF Data (for reading of all symmetric keys)
2.8.1.1 TSS Assurance Activities
TSS Assurance Activities: The evaluator shall examine the TSS to determine that it details how any preshared keys, symmetric keys, and private keys are stored and that they are unable to be viewed through an interface designed specifically for that purpose, as outlined in the application note. If these values are not stored in plaintext, the TSS shall describe how they are protected/obscured. TSS Implementation Details/Results: The ST, Section 7.2, Table 16 lists all of the TOE’s Critical Security Parameters (CSPs) and details how they are protected and stored.
2.8.1.2 Guidance Assurance Activities
Guidance Assurance Activities: None Guidance Implementation Details/Results: N/A
2.8.1.3 Testing Assurance Activities
Testing Assurance Activities: None Testing Implementation Details/Results: N/A
2.8.2 FPT_APW_EXT.1 Protection of Administrator Passwords
2.8.2.1 TSS Assurance Activities
TSS Assurance Activities: The evaluator shall examine the TSS to determine that it details all authentication data that are subject to this requirement, and the method used to obscure the plaintext password data when stored. The TSS shall also detail passwords are stored in such a way that they are unable to be viewed through an interface designed specifically for that purpose, as outlined in the application note. TSS Implementation Details/Results: The ST, Section 7.2, table 16 describes how credentials are stored and protected. Based on this section of the ST, it is clear that raw password authentication data are not stored in non-volatile memory in the clear.
2.8.2.2 Guidance Assurance Activities
Guidance Assurance Activities: None Guidance Implementation Details/Results: N/A
2.8.2.3 Testing Assurance Activities
Testing Assurance Activities: None Testing Implementation Details/Results: N/A
72 of 91 Dell Networking Platforms Assurance Activity Report
2.8.3 FPT_TST_EXT.1 TSF Testing
2.8.3.1 TSS Assurance Activities
TSS Assurance Activities: (1) The evaluator shall examine the TSS to ensure that it details the self-tests that are run by the TSF; this description should include an outline of what the tests are actually doing (e.g., rather than saying "memory is tested", a description similar to "memory is tested by writing a value to each memory location and reading it back to ensure it is identical to what was written" shall be used). (2) The evaluator shall ensure that the TSS makes an argument that the tests are sufficient to demonstrate that the TSF is operating correctly. TSS Implementation Details/Results: (1) The ST, Section 7.5, details that the TSF performs known-answer algorithm testing, integrity testing, and conditional self-testing.
(2) The ST, Section 7.5 details that Self-tests comply with the FIPS 140-2 requirements for self-testing. For all start-up tests, successful completion is indicated by reaching operational status. The diagnostic self-tests monitor the TOE against a set of anticipated faults, therefore outside of failure mode induced by failing self-tests, the TSF is assumed to operate correctly.
2.8.3.2 Guidance Assurance Activities
Guidance Assurance Activities: The evaluator shall also ensure that the guidance documentation describes the possible errors that may result from such tests, and actions the administrator should take in response; these possible errors shall correspond to those described in the TSS. Guidance Implementation Details/Results: The CC Guide, Appendix E - Auditable Events, FIPS Self-tests, page 88 details that if any of the self-test fail, the TOE will enter into an error state, raising an alarm and all data transmission is halted. The administrator must reboot the device in order to clear the error. Audit log error messages are generated as a result of the failure of one or more self-tests. The following is a sample error message when a self-test fail:
Sample Error Message 00:00:11: %STKUNIT0-M:CP %CRYPTO-5-FIPS_SELF_TEST_FAILED: [sysd] FIPS crypto module self-test failed
2.8.3.3 Testing Assurance Activities
Testing Assurance Activities: It is expected that at least the following tests are performed: a) Verification of the integrity of the firmware and executable software of the TOE. b) Verification of the correct operation of the cryptographic functions necessary to fulfill any of the SFRs. Although formal compliance is not mandated, the self-tests performed should aim for a level of confidence comparable to: a) [FIPS 140-2], chap. 4.9.1, Software/firmware integrity test for the verification of the integrity of the firmware and executable software. Note that the testing is not restricted to the cryptographic functions of the TOE.
73 of 91 Dell Networking Platforms Assurance Activity Report
b) [FIPS 140-2], chap. 4.9.1, Cryptographic algorithm test for the verification of the correct operation of cryptographic functions. Alternatively, national requirements of any CCRA member state for the security evaluation of cryptographic functions should be considered as appropriate. The evaluator shall either verify that the self-tests described above are carried out during initial start-up or that the developer has justified any deviation from this. Testing Implementation Details/Results: a) The TOE must be configured to be in FIPS mode of operation as part of the evaluated configuration. In test case PP-1C, the evaluator observed visually, via output to the console, that the integrity tests are executed on the startup of the TOE.
b) In test case PP-1C, the evaluator observed the self-tests being executed during formal testing. When the device starts up, the self –tests are executed as expected.
2.8.4 FPT_TUD_EXT.1 Trusted Update
2.8.4.1 TSS Assurance Activities
TSS Assurance Activities: (1) The evaluator shall verify that the TSS describe how to query the currently active version. If a trusted update can be installed on the TOE with a delayed activation, the TSS needs to describe how and when the inactive version becomes active. The evaluator shall verify this description. (2) The evaluator shall verify that the TSS describes all TSF software update mechanisms for updating the system firmware and software (for simplicity the term 'software' will be used in the following although the requirements apply to firmware and software). (3) The evaluator shall verify that the description includes a digital signature verification of the software before installation and that installation fails if the verification fails. Alternatively an approach using a published hash can be used. In this case the TSS shall detail this mechanism instead of the digital signature verification mechanism. The evaluator shall verify that the TSS describes the method by which the digital signature or published hash is verified to include how the candidate updates are obtained, the processing associated with verifying the digital signature or published hash of the update, and the actions that take place for both successful and unsuccessful signature verification or published hash verification. (4) If the options ‘support automatic checking for updates’ or ‘support automatic updates’ are chosen from the selection in FPT_TUD_EXT.1.2, the evaluator shall verify that the TSS explains what actions are involved in automatic checking or automatic updating by the TOE, respectively. (5) If the ST author indicates that a certificate-based mechanism is used for software update digital signature verification, the evaluator shall verify that the TSS contains a description of how the certificates are contained on the device. The evaluator also ensures that the TSS (or guidance documentation) describes how the certificates are installed/updated/selected, if necessary. (6) If a published hash is used to protect the trusted update mechanism, then the evaluator shall verify that the trusted update mechanism does involve an active authorization step of the Security Administrator, and that download of the published hash value, hash comparison and update is not a fully automated process involving no active authorization by the Security Administrator. In particular, authentication as Security Administration according to FMT_MOF.1/ManualUpdate needs to be part of the update process when using published hashes. TSS Implementation Details/Results: (1) The ST, Section 7.5, discusses all TSF software updates. When software updates are available, an administrator may obtain and apply the updates.
74 of 91 Dell Networking Platforms Assurance Activity Report
(2) The ST, Section 7.5, details that the TOE uses a published SHA-256 hash value. Once the image file has been downloaded to the device, executing the “verify” CLI command will produce a SHA-256 hash value. The administrator must then visually compare the generated result to the published hash value on the Dell website. If this visual verification fails then the installation of that image cannot proceed and the administrator must contact Dell Support.
(3) The ST, Section 7.5, states that the published hash mechanism is the method used to details how the candidate updates are obtained, the processing associated with verifying the digital signature or published hash of the update, and the actions that take place for both successful and unsuccessful signature verification or published hash verification.
(4) In the ST, Section 6.1.5.4, the SFR FPT_TUD_EXT.1.3 does not include the support of automatic checking of updates
(5) In the ST, Section 6.1.5.4, the SFR FPT_TUD_EXT.1.3 does not mention the support for certificate- based checking of updates.
(6) The ST, Section 7.5, details that the TOE uses a published SHA-256 hash value. Once the image file has been downloaded to the device, executing the “verify” CLI command will produce a SHA-256 hash value. The administrator must then visually compare the generated result to the published hash value on the Dell website. If this visual verification fails then the installation of that image cannot proceed and the administrator must contact Dell Support.
2.8.4.2 Guidance Assurance Activities
Guidance Assurance Activities: (1) The evaluator shall verify that the guidance documentation describes how to query the currently active version. If a trusted update can be installed on the TOE with a delayed activation, the guidance documentation needs to describe how to query the loaded but inactive version. (2) The evaluator shall verify that the guidance documentation describes how the verification of the authenticity of the update is performed (digital signature verification or verification of published hash). The description shall include the procedures for successful and unsuccessful verification. The description shall correspond to the description in the TSS. (3) If a published hash is used to protect the trusted update mechanism, the evaluator shall verify that the guidance documentation describes how the Security Administrator can obtain authentic published hash values for the updates. (4) If this was information was not provided in the TSS: If the ST author indicates that a certificate-based mechanism is used for software update digital signature verification, the evaluator shall verify that the Guidance Documentation contains a description of how the certificates are contained on the device. The evaluator also ensures that the Guidance Documentation describes how the certificates are installed/updated/selected, if necessary. Guidance Implementation Details/Results: (1) The CC Guide, Section 4, Upgrading and Downgrading the Software, Page 22, describes how to query the currently active version installed in the TOE. The TOE has two partitions, each partition can carry different software version. The page 23 of the CC Guide, describes how to query the loaded but inactive version of the installed software in one of the TOE's partitions.
(2) The CC Guide, Section 4, Upgrading and Downgrading the Software, Page 23, discusses that the TOE uses the published hash to verify the generated hash of the image. Upon successful verification, the TOE will load the new update upon reboot. The update will be rejected if the verification fails. This description corresponds to the description in the TSS.
75 of 91 Dell Networking Platforms Assurance Activity Report
(3) The CC Guide, Section 4, Upgrading and Downgrading the Software, Page 23, states that before starting the upgrade of image on the TOE, a user needs to obtain a user ID and password to access the Dell Networking release notes, software, and published hash on at https://www.dell.com/support/. Use the published hash to validate the software. The published hash and release notes are with the software.
(4) The ST author, in section 6.1.5.4, indicates that published hash verification is used and nothing else. This part of the assurance activity is therefore satisfied.
2.8.4.3 Testing Assurance Activities
Testing Assurance Activities: The evaluator shall perform the following tests: a) Test 1: The evaluator performs the version verification activity to determine the current version of the product. If a trusted update can be installed on the TOE with a delayed activation, the evaluator shall also query the most recently installed version (for this test the TOE shall be in a state where these two versions match). The evaluator obtains a legitimate update using procedures described in the guidance documentation and verifies that it is successfully installed on the TOE. For some TOEs loading the update onto the TOE and activation of the update are separate steps (‘activation’ could be performed e.g. by a distinct activation step or by rebooting the device). In that case the evaluator verifies after loading the update onto the TOE but before activation of the update that the current version of the product did not change but the most recently installed version has changed to the new product version. After the update, the evaluator performs the version verification activity again to verify the version correctly corresponds to that of the update and that current version of the product and most recently installed version match again. b) Test 2 (if digital signatures are used): The evaluator first confirms that no updates are pending and then performs the version verification activity to determine the current version of the product, verifying that it is different from the version claimed in the update(s) to be used in this test. The evaluator obtains or produces illegitimate updates as defined below, and attempts to install them on the TOE. The evaluator verifies that the TOE rejects all of the illegitimate updates. The evaluator performs this test using all of the following forms of illegitimate updates: 1) A modified version (e.g. using a hex editor) of a legitimately signed update 2) An image that has not been signed 3) An image signed with an invalid signature (e.g. by using a different key as expected for creating the signature or by manual modification of a legitimate signature) 4) If the TOE allows a delayed activation of updates the TOE must be able to display both the currently executing version and most recently installed version. The handling of version information of the most recently installed version might differ between different TOEs depending on the point in time when an attempted update is rejected. The evaluator shall verify that the TOE handles the most recently installed version information for that case as described in the guidance documentation. After the TOE has rejected the update the evaluator shall verify, that both, current version and most recently installed version, reflect the same version information as prior to the update attempt c) Test 3 (if published hash is verified on the TOE): If the published hash is provided to the TOE by the Security Administrator and the verification of the hash value over the update file(s) against the published hash is performed by the TOE, then the evaluator shall perform the following tests. The evaluator first confirms that no update is pending and then performs the version verification activity to determine the current version of the product, verifying that it is different from the version claimed in the update(s) to be used in this test. 1) The evaluator obtains or produces an illegitimate update such that the hash of the update does not match the published hash. The evaluator provides the published hash value to the TOE and
76 of 91 Dell Networking Platforms Assurance Activity Report
calculates the hash of the update either on the TOE itself (if that functionality is provided by the TOE), or else outside the TOE. The evaluator confirms that the hash values are different, and attempts to install the update on the TOE, verifying that this fails because of the difference in hash values (and that the failure is logged). Depending on the implementation of the TOE, the TOE might not allow the user to even attempt updating the TOE after the verification of the hash value fails. In that case the verification that the hash comparison fails is regarded as sufficient verification of the correct behaviour of the TOE. 2) The evaluator uses a legitimate update and tries to perform verification of the hash value without storing the published hash value on the TOE. The evaluator confirms that this attempt fails. Depending on the implementation of the TOE it might not be possible to attempt the verification of the hash value without providing a hash value to the TOE, e.g. if the hash value needs to be handed over to the TOE as a parameter in a command line message and the syntax check of the command prevents the execution of the command without providing a hash value. In that case the mechanism that prevents the execution of this check shall be tested accordingly, e.g. that the syntax check rejects the command without providing a hash value, and the rejection of the attempt is regarded as sufficient verification of the correct behaviour of the TOE in failing to verify the hash. The evaluator then attempts to install the update on the TOE (in spite of the unsuccessful hash verification) and confirms that this fails. Depending on the implementation of the TOE, the TOE might not allow to even attempt updating the TOE after the verification of the hash value fails. In that case the verification that the hash comparison fails is regarded as sufficient verification of the correct behaviour of the TOE. 3) If the TOE allows delayed activation of updates, the TOE must be able to display both the currently executing version and most recently installed version. The handling of version information of the most recently installed version might differ between different TOEs. Depending on the point in time when the attempted update is rejected, the most recently installed version might or might not be updated. The evaluator shall verify that the TOE handles the most recently installed version information for that case as described in the guidance documentation. After the TOE has rejected the update the evaluator shall verify, that both, current version and most recently installed version, reflect the same version information as prior to the update attempt. If the verification of the hash value over the update file(s) against the published hash is not performed by the TOE, Test 3 shall be skipped. The evaluator shall perform Test 1, Test 2 and Test 3 (if applicable) for all methods supported (manual updates, automatic checking for updates, automatic updates). Testing Implementation Details/Results: a) Test 1: The evaluator displayed the version of the product, then installed an update. The published hash value was verified visually against the generated hash, and the update was loaded successfully after verification. After the update, the evaluator performed the version verification activity again to verify the version correctly corresponds to that of the update and that current version of the product and most recently installed version match again.
b) Test 2: Not applicable, as the vendor does not digitally sign the TOE’s firmware.
c) Test 3: The evaluator modified an update using a binary editor and then attempted to install it. The hash verification failed and the update was not installed.
2.8.5 FPT_STM_EXT.1 Reliable Time Stamps
2.8.5.1 TSS Assurance Activities
TSS Assurance Activities:
77 of 91 Dell Networking Platforms Assurance Activity Report
The evaluator shall examine the TSS to ensure that it lists each security function that makes use of time, and that it provides a description of how the time is maintained and considered reliable in the context of each of the time related functions. TSS Implementation Details/Results: The ST, Section 7.5 states that the TOE is a hardware appliance that implements hardware-based real- time clock managed by embedded OS, which also controls the exposure of administrative functions.
The ST, Section 7.5 lists the following security functions that makes use of time:
audit trail generation synchronization with the operational environment Session inactivity timer checks Certificate expiration validation
The ST, Section 7.5, states “The TOE is a hardware appliance that implements hardware-based real-time clock managed by embedded OS, which also controls the exposure of administrative functions. This clock is used to produce reliable timestamps that are available for audit trail generation, synchronization with the operational environment, session inactivity checks, and certificate expiration validation.”
2.8.5.2 Guidance Assurance Activities
Guidance Assurance Activities: (1) The evaluator examines the guidance documentation to ensure it instructs the administrator how to set the time. (2) If the TOE supports the use of an NTP server, the guidance documentation instructs how a communication path is established between the TOE and the NTP server, and any configuration of the NTP client on the TOE to support this communication. Guidance Implementation Details/Results: (1) The CC Guide, Section 5, Setting Up the Common Criteria Configuration, Configuring the System Date and Time, Pages 43 - 44 details how to set the time and time zone on the TOE.
(2) The CC Guide, Appendix F, details how to configure the TOE to use the message digest SHA1 to protect its communication with the NTP server, and how to configure the trusted keys to be used with the NTP servers.
2.8.5.3 Testing Assurance Activities
Testing Assurance Activities: The evaluator shall perform the following tests: Test 1: If the TOE supports direct setting of the time by the Security Administrator then the evaluator uses the guidance documentation to set the time. The evaluator shall then use an available interface to observe that the time was set correctly. Test 2: If the TOE supports the use of an NTP server; the evaluator shall use the guidance documentation to configure the NTP client on the TOE, and set up a communication path with the NTP server. The evaluator will observe that the NTP server has set the time to what is expected. If the TOE supports multiple protocols for establishing a connection with the NTP server, the evaluator shall perform this test using each supported protocol claimed in the guidance documentation. If the audit component of the TOE consists of several parts with independent time information, then the evaluator shall verify that the time information between the different parts are either synchronized or that it
78 of 91 Dell Networking Platforms Assurance Activity Report
is possible for all audit information to relate the time information of the different part to one base information unambiguously. Testing Implementation Details/Results: Test 1: In test case PP-2, the evaluator followed the guidance documentation to set the time and time zone. During the same activity, using the console interface, the evaluator confirmed the correct display of the time and time zone on the TOE. Test 2: As part of the test cases PP-2 and PP-18, the evaluator used the guidance documentation to configure the TOE’s NTP client, and set up the trusted key and the message digest algorithm to be used with a specific NTP server and then the evaluator observed the TOE’s clock synchronized with the configured NTP serve’s clock. As mentioned in the ST, the TOE only supported the message digest sha1 algorithm to protect the integrity and the authenticity of the NTP packets.
2.9 TOE Access (FTA)
2.9.1 FTA_SSL_EXT.1 TSF-initiated Session Locking
2.9.1.1 TSS Assurance Activities
TSS Assurance Activities: None TSS Implementation Details/Results: N/A
2.9.1.2 Guidance Assurance Activities
Guidance Assurance Activities: The evaluator shall confirm that the guidance documentation states whether local administrative session locking or termination is supported and instructions for configuring the inactivity time period. Guidance Assurance Activities Details/Results: The CC Guide, Section 5, Configuring the Console Time-out, page 34 contains instructions for configuring local administrative session lockout. It also states that the default setting is 10 minutes.
2.9.1.3 Testing Assurance Activities
Testing Assurance Activities: The evaluator shall perform the following test [for local administrative session]: Test 1: The evaluator follows the guidance documentation to configure several different values for the inactivity time period referenced in the component. For each period configured, the evaluator establishes a local interactive session with the TOE. The evaluator then observes that the session is either locked or terminated after the configured time period. If locking was selected from the component, the evaluator then ensures that re-authentication is needed when trying to unlock the session. Testing Assurance Activities Details/Results: Test 1: In test case PP-4, the evaluator followed the user guidance and configured the following values for the console session inactivity timeout period: 1, 5, and 15 minutes. For each configured value, the evaluator established a local console session with the TOE and left it idle. The evaluator then observed that the console session was terminated after the configured time elapsed.
79 of 91 Dell Networking Platforms Assurance Activity Report
2.9.2 FTA_SSL.3 TSF-initiated Termination
2.9.2.1 TSS Assurance Activities
TSS Assurance Activities: None. TSS Implementation Details/Results: N/A
2.9.2.2 Guidance Assurance Activities
Guidance Assurance Activities: The evaluator shall confirm that the guidance documentation includes instructions for configuring the inactivity time period for remote administrative session termination. Note: TD0425 https://www.niap-ccevs.org/Documents_and_Guidance/view_td.cfm?td=0425 was applied. The CC Guide, Section 5, Subsection “Configuring Remote Access Time-out”, page 34 under “Configuring Console and Terminal Lines” section, contains instructions for configuring remote administrative session lockout. It also states that the default setting is 30 minutes.
2.9.2.3 Testing Assurance Activities
Testing Assurance Activities: For each method of remote administration, the evaluator shall perform the following test:
Test 1: The evaluator follows the guidance documentation to configure several different values for the inactivity time period referenced in the component. For each period configured, the evaluator establishes a remote interactive session with the TOE. The evaluator then observes that the session is terminated after the configured time period. Testing Assurance Activities Details/Results: Test 1: In test case PP-4, the evaluator followed the user guidance and configured the following values: 60 seconds, and 5, 15 minutes for the inactivity time period for the SSH sessions. For each period configured, the evaluator established a remote SSH session with the TOE. The evaluator then observes that the SSH session was terminated after each configured time period.
2.9.3 FTA_SSL.4 User-initiated Termination
2.9.3.1 TSS Assurance Activities
TSS Assurance Activities: None TSS Implementation Details/Results: N/A
2.9.3.2 Guidance Assurance Activities
Guidance Assurance Activities: The evaluator shall confirm that the guidance documentation states how to terminate a local or remote interactive session. Guidance Assurance Activities Details/Results: The CC Guide, Appendix C Navigating CLI modes, page 71 contains instruction on how to terminate a local and remote interactive session.
80 of 91 Dell Networking Platforms Assurance Activity Report
2.9.3.3 Testing Assurance Activities
Testing Assurance Activities: For each method of remote administration, the evaluator shall perform the following tests: Test 1: The evaluator initiates an interactive local session with the TOE. The evaluator then follows the guidance documentation to exit or log off the session and observes that the session has been terminated. Test 2: The evaluator initiates an interactive remote session with the TOE. The evaluator then follows the guidance documentation to exit or log off the session and observes that the session has been terminated. Testing Assurance Activities Details/Results: Test 1: In test case PP-4, the evaluator established an interactive local session with the TOE. The evaluator used the “exit” command to log off from the session and observed that the session was terminated. Test 2: In test case PP-4, the evaluator established an interactive remote session with the TOE. The evaluator used the “exit” command to log off from the SSH session and observed that the session was terminated.
2.9.4 FTA_TAB.1 Default TOE Access Banners
2.9.4.1 TSS Assurance Activities
TSS Assurance Activities: (1) The evaluator shall check the TSS to ensure that it details each administrative method of access (local and remote) available to the Security Administrator (e.g., serial port, SSH, HTTPS).
(2) The evaluator shall check the TSS to ensure that all administrative methods of access available to the Security Administrator are listed and that the TSS states that the TOE is displaying an advisory notice and a consent warning message for each administrative method of access. The advisory notice and the consent warning message might be different for different administrative methods of access, and might be configured during initial configuration (e.g. via configuration file). TSS Implementation Details/Results: (1) The evaluator examined the ST Section 7.6 and confirmed that it contains details about each administrative method of access (local and remote) available to the Security Administrator. Local administrator access the TOE using the local serial port, while remote administrators access the TOE via SSH. (2) The ST Section 7.6 explains that the TOE displays a Security Administrator-specified advisory notice and consent warning message (banner) when a Security Administrator initiates an interactive session either locally or remotely. The advisory notice and the consent warning message for all the different administrative methods of access can be configured during the initial configuration
2.9.4.2 Guidance Assurance Activities
Guidance Assurance Activities: The evaluator shall check the guidance documentation to ensure that it describes how to configure the banner message. Guidance Assurance Activities Details/Results:
81 of 91 Dell Networking Platforms Assurance Activity Report
The CC Guide, Section 5, Configuring the Banner page 34 contains instructions how to configure the banner message.
2.9.4.3 Testing Assurance Activities
Testing Assurance Activities: The evaluator shall also perform the following test: Test 1: The evaluator follows the guidance documentation to configure a notice and consent warning message. The evaluator shall then, for each method of access specified in the TSS, establish a session with the TOE. The evaluator shall verify that the notice and consent warning message is displayed in each instance.
Test 1: In test case PP-5, the evaluator followed the guidance to configure a notice and consent warning message, then established a local and remote session with the TOE and observed that the TOE displayed the notice and consent warning message. When carrying the above testing activity, the evaluator observed that the TOE displayed the notice and consent warning message for both local and remote methods of access.
82 of 91 Dell Networking Platforms Assurance Activity Report
2.10 Trusted Path/channels (FTP)
2.10.1 FTP_ITC.1 Inter-TSF Trusted Channel
2.10.1.1 TSS Assurance Activities
TSS Assurance Activities: (1) The evaluator shall examine the TSS to determine that, for all communications with authorized IT entities identified in the requirement, each secure communication mechanism is identified in terms of the allowed protocols for that IT entity, whether the TOE acts as a server or a client, and the method of assured identification of the non-TSF endpoint.
(2) The evaluator shall also confirm that all secure communication mechanisms are described in sufficient detail to allow the evaluator to match them to the cryptographic protocol Security Functional Requirements listed in the ST.
TSS Implementation Details/Results: (1) The ST, Section 7.7, states that the TLS v1.2 protocol with certificate-base authentication is used for secure communication with the external audit server.
(2) The evaluator confirmed that all protocols listed in the TSS are specified and included in the requirements of the ST.
2.10.1.2 Guidance Assurance Activities
Guidance Assurance Activities: The evaluator shall confirm that the guidance documentation contains instructions for establishing the allowed protocols with each authorized IT entity, and that it contains recovery instructions should a connection be unintentionally broken. Guidance Implementation Details/Results: The CC Guide, Section 5, Setting Up the Common Criteria Configuration, Configuring SYSLOG Servers, pages 42-43, contains instructions for establishing the TLS protocol with the external audit server. The CC Guide, Section 5, Setting Up the Common Criteria Configuration, Configuring SYSLOG Servers, pages 42- 43, contains recovery instructions should a connection to the audit server be unintentionally broken. There is no synchronization of audit records between the TOE and the remote SYSLOG server if communication is lost and then re-established at a later time.
2.10.1.3 Testing Assurance Activities
Testing Assurance Activities: The vendor shall provide to the evaluator application layer configuration settings for all secure communication mechanisms specified by the FTP_ITC.1 requirement. This information should be sufficiently detailed to allow the evaluator to determine the application layer timeout settings for each cryptographic protocol. There is no expectation that this information must be recorded in any public-facing document or report. The evaluator shall perform the following tests: Test 1: The evaluators shall ensure that communications using each protocol with each authorized IT entity is tested during the course of the evaluation, setting up the connections as described in the guidance documentation and ensuring that communication is successful.
83 of 91 Dell Networking Platforms Assurance Activity Report
Test 2: For each protocol that the TOE can initiate as defined in the requirement, the evaluator shall follow the guidance documentation to ensure that in fact the communication channel can be initiated from the TOE. Test 3: The evaluator shall ensure, for each communication channel with an authorized IT entity, the channel data is not sent in plaintext. Test 4: Objective: The objective of this test is to ensure that the TOE reacts appropriately to any connection outage or interruption of the route to the external IT entities. The evaluator shall, for each instance where the TOE acts as a client utilizing a secure communication mechanism with a distinct IT entity, physically interrupt the connection of that IT entity for the following durations: i) a duration that exceeds the TOE’s application layer timeout setting, ii) a duration shorter than the application layer timeout but of sufficient length to interrupt the MAC layer. The evaluator shall ensure that, when the physical connectivity is restored, communications are appropriately protected and no TSF data is sent in plaintext. In the case where the TOE is able to detect when the cable is removed from the device, another physical network device (e.g. a core switch) shall be used to interrupt the connection between the TOE and the distinct IT entity. The interruption shall not be performed at the virtual node (e.g. virtual switch) and must be physical in nature. Testing Implementation Details/Results: Test 1: The evaluator followed the user guidance documentation and set up communication using the TLS protocol with the syslog server. Test 2: The evaluator verified that once the TLS session was established the communication channel was initiated from the TOE. Test 3: For communication channel with the syslog server, it was observed that data was not sent in plaintext. Wireshark packet capture was used to verify the data was not in plain text. Test 4: The evaluator physically interrupted the connection to the audit server using TLS, and observed that once the connectivity was restored, communications were appropriately protected.
2.10.2 SFR: FTP_TRP.1/Admin Trusted Path
2.10.2.1 TSS Assurance Activities
TSS Assurance Activities: (1) The evaluator shall examine the TSS to determine that the methods of remote TOE administration are indicated, along with how those communications are protected.
(2) The evaluator shall also confirm that all protocols listed in the TSS in support of TOE administration are consistent with those specified in the requirement, and are included in the requirements in the ST. TSS Implementation Details/Results: (1) The ST, Section 7.7 states that the SSH v2 protocol is used for remote TOE administration.
(2) The evaluator confirmed that all protocols listed in the TSS in support of TOE administration are consistent with those specified in the NDcPP requirement, and are included in the relevant SFRs in the ST.
84 of 91 Dell Networking Platforms Assurance Activity Report
2.10.2.2 Guidance Assurance Activities
Guidance Assurance Activities: The evaluator shall confirm that the guidance documentation contains instructions for establishing the remote administrative sessions for each supported method. Guidance Assurance Activities Details/Results: The CC Guide, Section 2, Configuration Fundamentals, Accessing the Command Line, Connecting to the Management Ethernet Port, page 10, contains instructions for establishing SSH v2 for remote administration of the TOE.
2.10.2.3 Testing Assurance Activities
Testing Assurance Activities: The evaluator shall perform the following tests: Test 1: The evaluators shall ensure that communications using each specified (in the guidance documentation) remote administration method is tested during the course of the evaluation, setting up the connections as described in the guidance documentation and ensuring that communication is successful. Test 2: The evaluator shall ensure, for each communication channel, the channel data is not sent in plaintext. Testing Assurance Activities Details/Results: Test 1: during the testing activity, the evaluator ensured that the remote administration method using the SSHv2 protocol was tested and evaluated. The evaluator followed the CC guide instructions to set up the communication between the TOE and an SSH client running on a management machine and noticed a successful implementation of the communication Test 2: The evaluator verified that once the SSH session was established, the communication channel was initiated from the TOE and the data was not sent in clear-text.
85 of 91 Dell Networking Platforms Assurance Activity Report
3 Security Assurance Requirements
The sections below specify Evaluation Activities for the Security Assurance Requirements included in the related cPPs. The Evaluation Activities are an interpretation of the more general CEM assurance requirements as they apply to the specific technology area of the TOE.
3.1 ASE: Security Target Evaluation
3.1.1 General ASE
Evaluation Activities: (1) When evaluating a Security Target, the evaluator performs the work units as presented in the CEM. In addition, the evaluator ensures the content of the TSS in the ST satisfies the EAs specified in Section 2 (Evaluation Activities for SFRs).
Evaluation Activities Details/Results: (1) The evaluator performed the work units as presented in the CEM. The evaluator ensured the content of the TSS in the ST satisfied the EAs specified in Section 2. The evaluator reported all the ASE activity results in the ETR.
3.2 ADV: Development
3.2.1 ADV_FSP.1 Basic Functional Specification
Evaluation Activities: (1) The evaluator shall check the interface documentation to ensure it describes the purpose and method of use for each TSFI that is identified as being security relevant. In this context, TSFI are deemed security relevant if they are used by the administrator to configure the TOE, or to perform other administrative functions (e.g. audit review or performing updates). Additionally, those interfaces that are identified in the ST, or guidance documentation, as adhering to the security policies (as presented in the SFRs), are also considered security relevant. The intent is that these interfaces will be adequately tested, and having an understanding of how these interfaces are used in the TOE is necessary to ensure proper test coverage is applied. The set of TSFI that are provided as evaluation evidence are contained in the Administrative Guidance and User Guidance.
(2) The evaluator shall check the interface documentation to ensure it identifies and describes the parameters for each TSFI that is identified as being security relevant.
(3) The evaluator shall examine the interface documentation to develop a mapping of the interfaces to SFRs. The evaluator uses the provided documentation and first identifies, and then examines a representative set of interfaces to perform the EAs presented in Section 2, including the EAs associated with testing of the interfaces. It should be noted that there may be some SFRs that do not have an interface that is explicitly “mapped” to invoke the desired functionality. For example, generating a random bit string, destroying a
86 of 91 Dell Networking Platforms Assurance Activity Report
cryptographic key that is no longer needed, or the TSF failing to a secure state, are capabilities that may be specified in SFRs, but are not invoked by an interface. However, if the evaluator is unable to perform some other required EA because there is insufficient design and interface information, then the evaluator is entitled to conclude that an adequate functional specification has not been provided, and hence that the verdict for the ADV_FSP.1 assurance component is a ‘fail’. Evaluation Activities Details/Results: (1) The Evaluator examined the DellOS9.14_FSP document, and found it describing the purpose and method of use for every TSFI.
(2) The evaluator check the CC guide, and confirmed that: The CC Guide, Section 5 Setting Up the common Criteria Configuration, configuring Security, pages 27 to 31 identifies and describes the parameters for the SSH command Line interface. The CC Guide, Section 2, Configuration Fundamentals, accessing the command line, page 10 to 11, Setting Up the common Criteria Configuration, configuring Security, page 27, identifies and describes the parameters for the console command Line interface The CC Guide, Section 5, Setting Up the common Criteria Configuration, configuring syslog servers, pages 42 to 43, identifies and describes the parameters for the syslog interface. The CC Guide, Section 5, Setting Up the common Criteria Configuration, configuring x.509v3, pages 48 to 51, identifies and describes the parameters for the OCSP interface. The CC Guide, Appendix F, NTP, pages 89 to 90, identifies and describes the parameters for the NTP interface.
(3) The Dell OS9.14_FSP document was reviewed by the evaluator and provided to the scheme as part of the checkout package. This document outlines TOE TSFIs and states their purpose, method of use, and identifies parameters by referencing applicable RFC standard.
3.3 AGD: Guidance Documents
3.3.1 AGD_OPE.1 Operational User Guidance
Evaluation Activities: (1) The evaluator shall ensure the Operational guidance documentation is distributed to administrators and users (as appropriate) as part of the TOE, so that there is a reasonable guarantee that administrators and users are aware of the existence and role of the documentation in establishing and maintaining the evaluated configuration.
(2) The evaluator shall ensure that the Operational guidance is provided for every Operational Environment that the product supports as claimed in the Security Target and shall adequately address all platforms claimed for the TOE in the Security Target.
(3) The evaluator shall ensure that the Operational guidance contains instructions for configuring any cryptographic engine associated with the evaluated configuration of the TOE. It shall provide a warning to the administrator that use of other cryptographic engines was not evaluated nor tested during the CC evaluation of the TOE.
87 of 91 Dell Networking Platforms Assurance Activity Report
(4) The evaluator shall ensure the Operational guidance makes it clear to an administrator which security functionality and interfaces have been assessed and tested by the EAs.
(5) In addition the evaluator shall ensure that the following requirements are also met. a) The guidance documentation shall contain instructions for configuring any cryptographic engine associated with the evaluated configuration of the TOE. It shall provide a warning to the administrator that use of other cryptographic engines was not evaluated nor tested during the CC evaluation of the TOE. b) The documentation must describe the process for verifying updates to the TOE by verifying a digital signature. The evaluator shall verify that this process includes the following steps: 1) Instructions for obtaining the update itself. This should include instructions for making the update accessible to the TOE (e.g., placement in a specific directory). 2) Instructions for initiating the update process, as well as discerning whether the process was successful or unsuccessful. This includes instructions that describe at least one method of validating the hash/digital signature. c) The TOE will likely contain security functionality that does not fall in the scope of evaluation under this cPP. The guidance documentation shall make it clear to an administrator which security functionality is covered by the Evaluation Activities. Evaluation Activities Details/Results: (1) The Common Criteria Guide [ADMIN], submitted by the vendor to the Lab for evaluation, will be published along with the ST and CC certificate on www.niap-ccevs.org, so that there is a reasonable guarantee that administrators who need to set up the TOE in the evaluated configuration will be able to do so. The CC Guide, Section 1, Related Documents, page 8 states, “For more information about the Dell Networking certified switches see the following documents, release 9.14.1.0. Go to www.dell.com/manuals to access all Dell Networking documentation”.
(2) The evaluator examined the CC Guide and found it addresses every Operational Environment that the product supports as claimed in the ST. The evaluator found that the CC guide, adequately address all platforms claimed for the TOE in the ST.
(3) The CC Guide, Section 5, Setting Up the Common Criteria Configuration, Configuring Security, provides instructions for configuring the SSH cryptographic engine. The CC Guide, Appendix B- X.509v3, page 62 provides instructions how to install the trusted certificate anchor for x.509 certificates. The CC Guide, Section 5, Setting Up the Common Criteria Configuration, Enable FIPS mode, page 28 contains warning states that the use of other cryptographic engines was not evaluated nor tested during the CC evaluation of the TOE. You cannot install any other cryptographic engine as the Dell switches are not general-purpose machines.
(4) The evaluator examined the CC Guide, and found it only describes security functionality and interfaces that have been assessed and tested by the EAs. The evaluator found many statements on the CC guide that they emphasize on the CC supported configuration settings, and that the administrators must follow the CC Guide to configure the TOE in an evaluator configuration. Listing the above, the evaluator think that this assurance activity is satisfied.
(5) The evaluator ensured that the below additional requirements are also met:
a) The CC Guide, Section 5, Setting Up the Common Criteria Configuration, Enabling FIPS Mode, page 28 detail how to configure the cryptographic engine. It provides a warning to the administrators that use of other engines were not evaluated nor tested during the CC evaluation.
b) The CC Document, Section 4, Upgrading and downgrading the Software, page 22 details how to;
88 of 91 Dell Networking Platforms Assurance Activity Report
1) Obtain and apply updates to the system and determining if an upgrade was successful/unsuccessful.
2) The product presents a hash to be manually compared by the administrator to a published hash before loading the update as stated in the ST and found during testing. All devices are pre-installed with the digital signature verification key.
c) The evaluator examined the CC Guide, and found it only describes security functionality and interfaces that have been assessed and tested by the EAs. The evaluator that the CC Guide made it clear as to the scope of what that particular guidance addresses, i.e. the evaluated functionality of the TOE.
3.3.2 AGD_PRE.1 Preparative Procedures
Evaluation Activities: (1) The evaluator shall examine the Preparative procedures to ensure they include a description of how the administrator verifies that the operational environment can fulfil its role to support the security functionality (including the requirements of the Security Objectives for the Operational Environment specified in the Security Target).
(2) The evaluator shall examine the Preparative procedures to ensure they are provided for every Operational Environment that the product supports as claimed in the Security Target and shall adequately address all platforms claimed for the TOE in the Security Target.
(3) The evaluator shall examine the preparative procedures to ensure they include instructions to successfully install the TSF in each Operational Environment.
(4) The evaluator shall examine the preparative procedures to ensure they include instructions to manage the security of the TSF as a product and as a component of the larger operational environment.
(5) In addition the evaluator shall ensure that the following requirements are also met.
The preparative procedures must a) include instructions to provide a protected administrative capability; and b) identify TOE passwords that have default values associated with them and instructions shall be provided for how these can be changed.
Evaluation Activities Details/Results: (1) The evaluator examined the CC and the ADMIN1 guides and found that they include description of how the administrator can verify that the supporting servers (e.g. syslog server, NTP server and SSH client) in the TOE’s operational environment can support the TOE to fulfil its security objectives.
(2) The [ST] does not claim any additional Operational Environments outside of the [PP] defined network device Operational Environment. To this end, there is only one Operational Environment defined in the [ST]. (3) Evaluator examined the CC and ADMIN1 guides and he found that they include steps and instructions to successfully the TOE in each operational environment. (4) Evaluator examined the CC and ADMIN1 guides and he concluded that they include instructions to manage the security of the TSF as a product and as a component of the larger operational environment. (5) In addition, the evaluator ensured that the following requirements are also met: a) CC guide, Section 5, Setting Up the Common Criteria Configuration, includes instructions to for configuring administrative security functionality which includes
89 of 91 Dell Networking Platforms Assurance Activity Report
the following: o Warning and consent banner for both the local and remote console sessions o Administrative user credentials for local and remote consoles o Interactive session timeouts for local and remote sessions
b) The CC guide, section “Setting Up the Common Criteria Configuration, bullet “before you begin”, identify TOE passwords that have default values associated. The CC guide, section “Configuring a Username and Password” instructs how to change passwords for any user of the TOE.
3.4 ALC: Life-cycle Support
3.4.1 ALC_CMC.1 Labelling of the TOE
Evaluation Activities: When evaluating that the TOE has been provided and is labelled with a unique reference, the evaluator performs the work units as presented in the CEM. Evaluation Activities Details/Results: The evaluator performed the CEM work units as reported in the ETR.
3.4.2 ALC_CMS.1 TOE CM coverage
Evaluation Activities: When evaluating the developer’s coverage of the TOE in their CM system, the evaluator performs the work units as presented in the CEM. Evaluation Activities Details/Results: The evaluator performed the CEM work units as reported in the ETR.
3.5 ATE: Tests
3.5.1 ATE_IND.1 Independent Testing - Conformance
Evaluation Activities: The focus of the testing is to confirm that the requirements specified in the SFRs are being met. Additionally, testing is performed to confirm the functionality described in the TSS, as well as the dependencies on the Operational guidance documentation is accurate. The evaluator performs the CEM work units associated with the ATE_IND.1 SAR. Specific testing requirements and EAs are captured for each SFR in Sections 2, 3 and 4. The evaluator should consult Appendix B when determining the appropriate strategy for testing multiple variations or models of the TOE that may be under evaluation. Evaluation Activities Details/Results: Please refer to the NDcPP DELL Test Report v0.6 for all details. The evaluator translated Testing Assurance Activities into a Test Plan containing 56 manual test cases. The testing was carried out at 1000 Innovation Drive, Ottawa, ON, lab on an isolated test setup. All tests have passed and the result were noted in the TEST document.
90 of 91 Dell Networking Platforms Assurance Activity Report
3.6 AVA: Vulnerability Assessment
3.6.1 AVA_VAN.1 Vulnerability Survey
Evaluation Activities: (1) The evaluator shall examine the documentation outlined below provided by the developer to confirm that it contains all required information. This documentation is in addition to the documentation already required to be supplied in response to the EAs listed previously. The developer shall provide documentation identifying the list of software and hardware components that compose the TOE. Hardware components should identify at a minimum the processors used by the TOE. Software components include applications, the operating system and other major components that are independently identifiable and reusable (outside the TOE) such as a web server and protocol or cryptographic libraries. This additional documentation is merely a list of the name and version number of the components, and will be used by the evaluators in formulating hypotheses during their analysis.
(2) The evaluator formulates hypotheses in accordance with process defined in Appendix A. The evaluator documents the flaw hypotheses generated for the TOE in the report in accordance with the guidelines in Appendix A.3. The evaluator shall perform vulnerability analysis in accordance with Appendix A.2. The results of the analysis shall be documented in the report according to Appendix A.3.
Evaluation Activities Details/Results: The evaluator requested that the vendor provide a comprehensive list of third-party components used by the TOE. Using this list, the evaluator identified 3 components.
The evaluator then performed searches on public information from the following sources: National Vulnerability Database (https://nvd.nist.gov) CVE details (https://www.cvedetails.com) Open Sourced Vulnerability Database (vulners.com) Security Focus (securityfocus.com)
Using search terms that included “Dell”, “OpenSSL 1.0.2”, “OpenSSH 8.0.p1”.
These searches produced a combined list of 327 potential vulnerabilities.
The evaluator then reviewed this list based on criteria including: applicability to each component (version affected), whether or not the vulnerable functionality might be utilized by the TOE, etc. A much shorter list of potential vulnerabilities was forwarded to the vendor, who performed a thorough granular search on whether or not the TOE used specific functionality (i.e. a function call), and either upgraded the component in question or provided a rationale back to the evaluator that either required further clarification or was determined to be appropriate as to why the vulnerability did not apply.
Please refer to the [ETR] as it contains the results of the vulnerability assessment of the TOE. The evaluator performed searches on public information to determine vulnerabilities as well as devised test cases to test out vulnerabilities. Vulnerabilities detected were patched in the evaluated version of the product.
91 of 91