## H3C WX5800 Series, WX2800 Series, WSG1800 Series, WA6500 Series, WA7200 Series, WA7300 Series, WA7500 Series, WA7600 Series, CPE Series and WX3800 Series Wireless Controllers and Access Points ## Security Target Lite Version: 4.4 Date: 2025-10-22 H3C ### Document Introduction Prepared by: New H3C Technologies Co., Ltd. This document provides the basis for the security evaluation of the specific Target of Evaluation (TOE) - H3C Wireless Controller (AC) and Access Point (AP). This Security Target (ST) defines the environmental assumptions, the list of threats the product must address, the set of security objectives, the set of security requirements, and the IT security functions provided by the object to meet these requirements. #### Document history | Version | Date | Comment | Author | |-----------|------------|---------------------------------------------------------------|----------| | 0.1 | 2024-12-11 | Initial version | H3C | | 0.2 | 2025-01-23 | Updated conformance claims | H3C | | 1.0 | 2025-03-23 | Updated RBG etc. | H3C | | 2.0 | 2025-04-03 | Updated after initial comments | H3C | | 3.1 | 2025-04-22 | Updated TSS and, added FCS_CKM.3 | H3C | | 3.2 | 2025-05-07 | Updated FCS_CKM.3 | H3C | | 3.3 | 2025-05-09 | Updated according to review comments | H3C | | 3.4 | 2025-05-09 | Updated FIA_X509_EXT.1.1/ITT | H3C | | 3.5 | 2025-06-12 | Modified according to review | H3C | | 3.6 | 2025-06-23 | Modified DTLS and TLS | H3C | | 3.7 | 2025-07-07 | Based on internal review revisions | H3C | | 3.8 | 2025-07-15 | Changed text format | H3C | | 3.9 | 2025-08-7 | Updated according to review comments | H3C | | 4.0 | 2025-08-12 | Updated according to review comments | H3C | | 4.1 | 2025-08-22 | Updated TSS | H3C | | 4.2 | 2025-09-08 | Updated TSS | H3C | | 4.3 | 2025-10-18 | Modified section 1 ， Updated section 8.2 FCS_CKM.2 | H3C | | 4.4 | 2025-10-22 | Delete revision history and notes ， Modified section 1.4&1.5 | H3C | #### Contents | Document Introduction Prepared by: New H3C Technologies Co., Ltd. ................................................. 2 | Document Introduction Prepared by: New H3C Technologies Co., Ltd. ................................................. 2 | |-------------------------------------------------------------------------------------------------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | 1 | Security Target lite Introduction .......................................................................................... 9 | | 1.1 | Security Target Lite and TOE Reference ..................................................................................... 9 | | 1.2 | TOE Overview ............................................................................................................................. 9 | | 1.3 | TOE Type 10 | | 1.4 | ................................................................................................................................... TOE Evaluated Configuration ................................................................................................... 10 | | 1.5 | Required non-TOE Hardware/Software/Firmware .................................................................. 12 | | 1.6 | TOE Description ........................................................................................................................ 12 | | 1.7 | Physical Scope .......................................................................................................................... 13 | | 1.8 | Logical Scope ............................................................................................................................ 19 | | 1.8.1 | Security audit ............................................................................................................................ 19 | | 1.8.2 | Communication ........................................................................................................................ 19 | | 1.8.3 | Cryptographic support.............................................................................................................. 19 | | 1.8.4 | Identification and authentication ............................................................................................. 19 | | 1.8.5 | Security management .............................................................................................................. 19 | | 1.8.6 | Protection of the TSF ................................................................................................................ 19 | | 1.8.7 | TOE access ................................................................................................................................ 20 | | 1.8.8 | Trusted path/channels. ............................................................................................................ 20 | | 1.9 | Excluded Functionality ............................................................................................................. 20 | | 2 | Conformance claims ........................................................................................................... 21 | | 2.1 | CC Conformance Claim ............................................................................................................. 21 | | 2.2 | PP Conformance ....................................................................................................................... 21 | | 2.3 | Package Conformance .............................................................................................................. 21 | | 2.4 | Conformance Rationale ............................................................................................................ 21 | | 3 | Security Problem Definition ................................................................................................ 22 | | 3.1 | Threats ...................................................................................................................................... 22 | | 3.1.1 | T.UNAUTHORIZED_ADMINSTRATOR_ACCESS .......................................................................... 22 | | 3.1.2 | T.WEAK_CRYPTOGRAPHY ......................................................................................................... 22 | | 3.1.3 | T.UNTRUSTED_COMMUNICATION_CHANNELS ....................................................................... 22 | | 3.1.4 | T.WEAK_AUTHENTICATION_ENDPOINTS ................................................................................. 22 | | 3.1.5 | T.UPDATE_COMPROMISE......................................................................................................... 22 | | 3.1.6 | T.UNDETECTED_ACTIVITY ......................................................................................................... 22 | | 3.1.7 | T.SECURITY_FUNCTIONALITY_COMPROMISE .......................................................................... 23 | | 3.1.8 | T.SECURITY_FUNCTIONALITY_FAILURE .................................................................................... 23 | | 3.1.9 | T.NETWORK_DISCLOSURE ........................................................................................................ 23 | | 3.1.10 | T.NETWORK_ACCESS ................................................................................................................ 23 | | 3.1.11 | T.TSF_FAILURE .......................................................................................................................... 23 | | 3.1.12 | T.DATA_INTEGRITY ................................................................................................................... 23 | | 3.1.13 | T.REPLAY_ATTACK .................................................................................................................... 23 | | 3.2 | Assumptions | | | ............................................................................................................................. 24 | | 3.2.1 3.2.2 | A.PHYSICAL_PROTECTION ........................................................................................................ 24 A.LIMITED_FUNCTIONALITY ..................................................................................................... 24 | | 3.2.3 | A.NO_THRU_TRAFFIC_PROTECTION ........................................................................................ | 24 | |---------|------------------------------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------------------------------------------| | 3.2.4 | A.TRUSTED_ADMINISTRATOR .................................................................................................. | 24 | | 3.2.5 | A.REGULAR_UPDATES .............................................................................................................. | 24 | | 3.2.6 | A.ADMIN_CREDENTIALS_SECURE ............................................................................................ | 24 | | 3.2.7 | A.COMPONENTS_RUNNING (applies to distributed TOEs only) ............................................... | 24 | | 3.2.8 | A.RESIDUAL_INFORMATION ..................................................................................................... | 25 | | 3.2.9 | A.CONNECTIONS ....................................................................................................................... | 25 | | 3.3 | Organizational Security Policy .................................................................................................. | 25 | | 3.3.1 | P.ACCESS_BANNER ................................................................................................................... | 25 | | 4 | Security Objectives | ............................................................................................................. 26 | | 4.1 | Security Objectives for the TOE ................................................................................................ | 26 | | 4.1.1 | O.ADMIN_AUTH ....................................................................................................................... | 26 | | 4.1.2 | O.STRONG_CRYPTO .................................................................................................................. | 26 | | 4.1.3 | O.TRUSTED_COMM .................................................................................................................. | 26 | | 4.1.4 | O.STRONG_AUTHENTICATION_ENDPOINT .............................................................................. | 26 | | 4.1.5 | O.SECURE_UPDATES ................................................................................................................. | 26 | | 4.1.6 | O.ACTIVITY_AUDIT | ................................................................................................................... 26 | | 4.1.7 | O.PASSWORD_PROTECTION .................................................................................................... | 26 | | 4.1.8 | O.SELF_TEST ............................................................................................................................. | 26 | | 4.1.9 | O.BANNER ................................................................................................................................ | 27 | | 4.1.10 | O.CRYPTOGRAPHIC_FUNCTIONS .............................................................................................. | 27 | | 4.1.11 | O.AUTHENTICATION | ................................................................................................................. 27 | | 4.1.12 | O.FAIL_SECURE ......................................................................................................................... | 27 | | 4.1.13 | O.SYSTEM_MONITORING ......................................................................................................... | 27 | | 4.1.14 | O.TOE_ADMINISTRATION ......................................................................................................... | 27 | | 4.2 | Security Objectives for the Operational Environment | ............................................................. 27 | | 4.2.1 | OE.PHYSICAL ............................................................................................................................. | 27 | | 4.2.2 | OE.NO_GENERAL_PURPOSE ..................................................................................................... | 27 | | 4.2.3 | OE.NO_THRU_TRAFFIC_PROTECTION ...................................................................................... | 27 | | 4.2.4 | OE.TRUSTED_ADMIN ................................................................................................................ | 27 | | 4.2.5 | OE.UPDATES | ............................................................................................................................. 28 | | 4.2.6 | OE.ADMIN_CREDENTIALS_SECURE .......................................................................................... | 28 | | 4.2.7 | OE.COMPONENTS_RUNNING (applies to distributed TOEs only) ............................................ | 28 | | 4.2.8 | OE.RESIDUAL_INFORMATION .................................................................................................. | 28 | | 4.2.9 | OE.CONNECTIONS .................................................................................................................... | 28 | | 4.3 | Tracing SPDs to Security Objectives | ......................................................................................... 28 | | 4.4 | Security Objectives Rationale ................................................................................................... | 29 | | 4.4.1 | Threats ...................................................................................................................................... | 29 | | 4.4.1.1 | T.UNAUTHORIZED_ADMINISTRATOR_ACCESS ......................................................................... | 29 | | 4.4.1.2 | T.WEAK_CRYPTOGRAPHY | ......................................................................................................... 29 | | 4.4.1.3 | T.UNTRUSTED_COMMUNICATION_CHANNELS ....................................................................... | 29 | | 4.4.1.4 | T.WEAK_AUTHENTICATION_ENDPOINTS | ................................................................................. 29 | | 4.4.1.5 | T.UPDATE_COMPROMISE......................................................................................................... | 29 | | 4.4.1.6 | T.UNDETECTED_ACTIVITY ......................................................................................................... | 30 | | 4.4.1.7 | T.SECURITY_FUNCTIONALITY_COMPROMISE | .......................................................................... 30 | 4.4.1.8 T.SECURITY_FUNCTIONALITY_FAILURE .................................................................................... 30 | 4.4.1.9 | T.NETWORK_DISCLOSURE ........................................................................................................ | 30 | |---------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-------| | 4.4.1.10 | T.NETWORK_ACCESS ................................................................................................................ | 30 | | 4.4.1.11 | T.TSF_FAILURE .......................................................................................................................... | 30 | | 4.4.1.12 | T.DATA_INTEGRITY ................................................................................................................... | 30 | | 4.4.1.13 | T.REPLAY_ATTACK .................................................................................................................... | 30 | | 4.4.2 | OSP ........................................................................................................................................... | 31 | | 4.4.2.1 | P.ACCESS_BANNER ................................................................................................................... | 31 | | 4.4.3 | Assumptions ............................................................................................................................. | 31 | | 4.4.3.1 | A.PHYSICAL_PROTECTION ........................................................................................................ | 31 | | 4.4.3.2 | A.LIMITED_FUNCTIONALITY ..................................................................................................... | 31 | | 4.4.3.3 | A.NO_THRU_TRAFFIC_PROTECTION ........................................................................................ | 31 | | 4.4.3.4 | A.TRUSTED_ADMINISTRATOR .................................................................................................. | 31 | | 4.4.3.5 | A.REGULAR_UPDATES .............................................................................................................. | 31 | | 4.4.3.6 | A.ADMIN_CREDENTIALS_SECURE ............................................................................................ | 31 | | 4.4.3.7 | A.RESIDUAL_INFORMATION ..................................................................................................... | 31 | | 4.4.3.8 | A.CONNECTIONS ....................................................................................................................... | 31 | | 5 | Extended Component Definition ........................................................................................ | 32 | | 6 6.1 | Security Functional Requirements ...................................................................................... Security Audit (FAU) ................................................................................................................. | 33 33 | | 6.1.1 | Security Audit Data generation (FAU_GEN) ............................................................................. | 33 | | 6.1.1.1 | FAU_GEN.1 Audit Data Generation .......................................................................................... | 33 | | 6.1.1.2 | FAU_GEN.2 User identity association....................................................................................... | 36 | | 6.1.2 | Security audit event storage (FAU_STG) .................................................................................. | 37 | | 6.1.2.1 | FAU_STG.2 Protected audit data storage ................................................................................. | 37 | | 6.1.2.2 | FAU_STG_EXT.1 Protected Audit Event Storage ...................................................................... | 37 | | 6.2 | Cryptographic Support (FCS) .................................................................................................... | 37 | | 6.2.1 | Cryptographic Key Management (FCS_CKM) ........................................................................... | 37 | | 6.2.1.1 | FCS_CKM.1 Cryptographic Key Generation (Refinement) ........................................................ | 37 | | 6.2.1.2 | FCS_CKM.2 Cryptographic Key Establishment (Refinement) ................................................... | 38 | | 6.2.1.3 | FCS_CKM.3 Cryptographic key access ...................................................................................... | 38 | | 6.2.1.4 | FCS_CKM.6 Timing and event of cryptographic key destruction ............................................. | 38 | | 6.2.2 | Cryptographic Operation (FCS_COP.1) ..................................................................................... | 38 | | 6.2.2.1 | FCS_COP.1/SigGen Cryptographic Operation (Signature Generation and Verification) .......... | 38 | | 6.2.2.2 | FCS_COP.1/Hash Cryptographic Operation (Hash Algorithm).................................................. | 39 | | 6.2.2.3 | FCS_COP.1/KeyedHash Cryptographic Operation (Keyed Hash Algorithm) ............................. | 39 | | 6.2.3 | Random Bit Generation (FCS_RBG) .......................................................................................... | 39 | | 6.2.3.1 | FCS_RBG.1 Random Bit Generation ......................................................................................... | 39 | | 6.2.3.2 | FCS_RBG.3 Random bit generation (internal seeding - single source) .................................... | 40 | | 6.3 | Identification and Authentication (FIA) .................................................................................... | 40 | | 6.3.1 | Authentication Failure Management (FIA_AFL) ....................................................................... | 40 | | 6.3.1.1 | FIA_AFL.1 Authentication Failure Management (Refinement) ................................................ | 40 | | 6.3.2 | Password Management (Extended - FIA_PMG_EXT)............................................................... | 40 | | 6.3.2.1 6.3.3 | FIA_PMG_EXT.1 Password Management ................................................................................. User Identification and Authentication (Extended - FIA_UIA_EXT) ......................................... | 40 41 | | 6.3.3.1 | ........................................................... | | | | FIA_UIA_EXT.1 User Identification and Authentication | 41 | | 6.3.4 | User authentication (FIA_UAU) (Extended - FIA_UAU_EX ...................................................... | 41 | |---------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|------------------| | 6.3.4.1 | FIA_UAU.7 Protected Authentication Feedback ...................................................................... | 41 | | 6.4 | Security Management (FMT) .................................................................................................... | 41 | | 6.4.1 | Specification of Management Functions (FMT_SMF) .............................................................. | 41 | | 6.4.1.1 | FMT_SMF.1 Specification of Management Functions .............................................................. | 41 | | 6.4.2 | Security management roles (FMT_SMR) .................................................................................. | 42 | | 6.4.2.1 | FMT_SMR.2 Restrictions on security roles ............................................................................... | 42 | | 6.5 | Protection of the TSF (FPT) ....................................................................................................... | 43 | | 6.5.1 | Protection of TSF Data (Extended - FPT_SKP_EXT) .................................................................. | 43 | | 6.5.1.1 | FPT_SKP_EXT.1 Protection of TSF Data (for reading of all pre-shared, symmetric and .................................................................................................................................................. | private keys) 43 | | 6.5.2 | Protection of Administrator Passwords (Extended - FPT_APW_EXT) ...................................... | 43 | | 6.5.2.1 | FPT_APW_EXT.1 Protection of Administrator Passwords ........................................................ | 43 | | 6.5.3 | Trusted Update (FPT_TUD_EXT) ............................................................................................... | 43 | | 6.5.3.1 | FPT_TUD_EXT.1 Trusted Update .............................................................................................. | 43 | | 6.5.4 | Time stamps (Extended - FPT_STM)) ....................................................................................... | 43 | | 6.5.4.1 | FPT_STM.1 Reliable Time Stamps ............................................................................................ | 43 | | 6.5.4.2 | FPT_STM.2 Time source ........................................................................................................... | 44 | | 6.6 | TOE Access (FTA) ...................................................................................................................... | 44 | | 6.6.1 | TSF-initiated Session Locking (Extended - FTA_SSL_EXT) ........................................................ | 44 | | 6.6.1.1 | FTA_SSL_EXT.1 TSF-initiated Session Locking .......................................................................... | 44 | | 6.6.2 | Session Locking and Termination (FTA_SSL) ............................................................................ | 44 | | 6.6.2.1 | FTA_SSL.3 TSF-initiated Termination (Refinement) ................................................................. | 44 | | 6.6.2.2 | FTA_SSL.4 User-initiated Termination (Refinement) ................................................................ | 44 | | 6.6.3 | TOE Access Banners (FTA_TAB) ................................................................................................ | 44 | | 6.6.3.1 | FTA_TAB.1 Default TOE Access Banners (Refinement) ............................................................ | 44 | | 6.7 | Trusted Path/Channels (FTP) .................................................................................................... | 44 | | 6.7.1 | Trusted Channel (FTP_ITC) ....................................................................................................... | 44 | | 6.7.1.1 | FTP_ITC.1 Inter-TSF Trusted Channel (Refinement) ................................................................. | 44 | | 6.7.2 | Trusted Path (FTP_TRP) ............................................................................................................ | 45 | | 6.7.2.1 | FTP_TRP.1/Admin Trusted Path (Refinement) ......................................................................... | 45 | | 6.8 | Selection-Based Requirements ................................................................................................ | 45 | | 6.8.1 | Cryptographic Support (FCS) .................................................................................................... | 45 | | 6.8.1.1 | FCS_IPSEC_EXT.1 IPsec Protocol .............................................................................................. | 45 | | 6.8.1.2 | FCS_NTP_EXT.1 NTP Protocol ................................................................................................... | 47 | | 6.8.1.3 | FCS_SSH_EXT.1 SSH Protocol ................................................................................................... | 47 | | 6.8.1.4 | FCS_SSHS_EXT.1 SSH Protocol - Server.................................................................................... | 48 | | 6.8.1.5 | FCS_DTLSC_EXT.1 DTLS Client Protocol Without Mutual Authentication ................................ | 49 | | 6.8.1.6 | FCS_DTLSS_EXT.1 DTLS Server Protocol Without Mutual Authentication ............................... | 50 | | 6.8.1.7 | FCS_TLSC_EXT.1 TLS Client Protocol Without Mutual Authentication ..................................... | 51 | | 6.8.1.8 | FCS_TLSS_EXT.1 TLS Server Protocol Without Mutual Authentication .................................... | 52 | | 6.8.2 | Identification and Authentication (FIA) .................................................................................... | 53 | | 6.8.2.1 | FIA_X509_EXT.1/Rev X.509 Certificate Validation ................................................................... | 53 | | 6.8.2.2 | FIA_X509_EXT.1/ITT X.509 Certificate Validation .................................................................... | 54 | | 6.8.2.3 | FIA_X509_EXT.2 X.509 Certificate Authentication ................................................................... | 55 | | 6.8.2.4 6.8.3 | FIA_X509_EXT.3 X.509 Certificate Requests ............................................................................ Communication (FCO) .............................................................................................................. | 55 55 | | 6.8.3.1 | FCO_CPC_EXT.1 Component Registration Channel Definition ................................................. | 55 | |-----------|---------------------------------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------------------------------------------------| | 6.8.4 | Security Management (FMT) .................................................................................................... | 56 | | 6.8.4.1 | FMT_MOF.1/Functions Management of Security Functions Behaviour .................................. | 56 | | 6.8.4.2 | FMT_MOF.1/ManualUpdate Management of Security Functions Behaviour .......................... | 56 | | 6.8.4.3 | FMT_MTD.1/CoreData Management of TSF Data | ................................................................... 56 | | 6.8.4.4 | FMT_MTD.1/CryptoKeys Management of TSF Data ................................................................ | 56 | | 6.8.5 | Protection of the TSF (FPT) | ....................................................................................................... 57 | | 6.8.5.1 | FPT_ITT.1 Basic internal TSF data transfer protection (Refinement) ....................................... | 57 | | 6.9 | Edited Requirements from PP Module ..................................................................................... | 57 | | 6.9.1 | Security Audit (FAU) | ................................................................................................................. 57 | | 6.9.1.1 | FAU_GEN_EXT.1 Security Audit Generation ............................................................................. | 57 | | 6.9.1.2 | FAU_STG_EXT.4 Protected Local Audit Event Storage for Distributed TOEs ............................ | 57 | | 6.9.1.3 | FAU_STG_EXT.5 Protected Remote Audit Event Storage for Distributed TOEs ....................... | 57 | | 6.9.2 | Cryptographic Support (FCS) .................................................................................................... | 57 | | 6.9.2.1 | FCS_COP.1/DataEncryption Cryptographic Operation (AES Data Encryption/Decryption) | ..... 57 | | 6.9.3 | Protection of the TSF (FPT) ....................................................................................................... | 58 | | 6.9.3.1 | FPT_TST_EXT.1 TSF Testing | ...................................................................................................... 58 | | 6.10 | New Requirements from PP Module ........................................................................................ | 58 | | 6.10.1 | Cryptographic Support (FCS) .................................................................................................... | 58 | | 6.10.1.1 | FCS_CKM.1/WPA Cryptographic Key Generation (Symmetric Keys for WPA2 Connections) | .. 58 | | 6.10.1.2 | FCS_CKM.2/GTK Cryptographic Key Distribution (GTK) ........................................................... | 58 | | 6.10.1.3 | FCS_CKM.2/PMK Cryptographic Key Distribution (PMK) ......................................................... | 58 | | 6.10.2 | Identification and Authentication (FIA) .................................................................................... | 59 | | 6.10.2.1 | FIA_8021X_EXT.1 802.1X Port Access Entity (Authenticator) Authentication ......................... | 59 | | 6.10.2.2 | FIA_UAU.6 Re-Authenticating .................................................................................................. | 59 | | 6.10.3 | Security Management (FMT) .................................................................................................... | 59 | | 6.10.3.1 | FMT_SMF.1/AccessSystem Specification of Management Functions (WLAN Access Systems)59 | | | 6.10.3.2 | FMT_SMR_EXT.1 No Administration from Client ..................................................................... | 59 | | 6.10.1 | Security Audit (FAU) ................................................................................................................. | 60 | | 6.10.1.1 | FAU_GEN.1/WLAN Audit Data Generation .............................................................................. | 60 | | 6.10.2 | Protection of the TSF (FPT) ....................................................................................................... | 61 | | 6.10.2.1 | FPT_FLS.1 Failure with Preservation of Secure State | ............................................................... 61 | | 6.10.3 | TOE Access (FTA) ...................................................................................................................... | 61 | | 6.10.3.1 | FTA_TSE.1 TOE Session Establishment ..................................................................................... | 61 | | 6.10.4 | Trusted Path/Channels (FTP) .................................................................................................... | 61 | | 6.10.4.1 | FTP_ITC.1/Client Inter-TSF Trusted Channel (WLAN Client Communications) ......................... | 61 | | 7 | Security Assurance Requirements ...................................................................................... | 62 | | 8 | TOE Summary Specification ................................................................................................ | 63 | | 8.1 | Security audit ............................................................................................................................ | 63 | | 8.2 | Cryptographic support.............................................................................................................. | 64 | | 8.3 | Identification and authentication ............................................................................................. | 74 | | 8.4 | Security management .............................................................................................................. | 79 | | 8.5 | Protection of the TSF ................................................................................................................ TOE access | 81 ................................................................................................................................ 83 | | 8.6 | path/channels. ............................................................................................................ | 83 | | 8.7 | Trusted | | 8.8 Communication ........................................................................................................................ 84 ##### 9 Rationales ........................................................................................................................... 86 9.1 Security Objectives Rationale ................................................................................................... 86 9.1.1 O.ADMIN_AUTH: ...................................................................................................................... 86 9.1.2 O.STRONG_CRYPTO .................................................................................................................. 87 9.1.3 O.TRUSTED_COMM .................................................................................................................. 87 9.1.4 O.STRONG_AUTHENTICATION_ENDPOINT .............................................................................. 87 9.1.5 O.SECURE_UPDATES ................................................................................................................. 87 9.1.6 O.ACTIVITY_AUDIT ................................................................................................................... 87 9.1.7 O.PASSWORD_PROTECTION .................................................................................................... 88 9.1.8 O.SELF_TEST ............................................................................................................................. 88 9.1.9 O.CRYPTOGRAPHIC_FUNCTIONS .............................................................................................. 88 9.1.10 O.AUTHENTICATION ................................................................................................................. 88 9.1.11 O.FAIL_ SECURE ........................................................................................................................ 88 9.1.12 O.SYSTEM_MONITORING ......................................................................................................... 88 9.1.13 O.TOE_ADMINISTRATION ......................................................................................................... 89 9.1.14 O.BANNER ................................................................................................................................ 89 9.2 SFRs to component of the TOE rationale ................................................................................. 89 9.3 Dependency Rationale ............................................................................................................. 91 10 Abbreviations and glossary ................................................................................................. 92 11 References .......................................................................................................................... 93 ### 1 Security Target lite Introduction The ST describes what is evaluated, including the exact security properties of the TOE in a manner that the potential consumer can rely on. ## 1.1 Security Target Lite and TOE Reference This section provides information needed to identify and control this ST and its TOE. Table 1 Security Target Lite reference | Title | H3C WX5800 Series, WX2800 Series, WSG1800 Series, WA6500 Series, WA7200 Series, WA7300 Series, WA7500 Series, WA7600 Series, CPE Series and WX3800 Series Wireless Controllers and Access Points Security Target Lite | |---------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | Version | See Document History | | Date | See Document History | | Author | New H3C Technologies Co., Ltd | | EAL | 2+ augmented with ALC_FLR.2 | ###### TOE Reference Table 2 TOE reference | TOE Developer | New H3C Technologies Co., Ltd | |-----------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | TOE Name | H3C Wireless Controllers and Access Points | | TOE Version | TOE hardware: H3C WX5800 Series, WX2800 Series, WSG1800 Series, WX3800 Series Wireless Controllers and WA6500 Series, WA7200 Series, WA7300 Series, WA7500 Series, WA7600 Series , CPE Series Access Points TOE firmware: H3C Comware Software, Version 7.1, H3C Comware Software, Version 9.1 | ## 1.2 TOE Overview The TOE combines Wireless Access Controllers and Access Points developed by H3C to create a Wireless LAN Access System TOE. The TOE provides secure wireless access to a wired and wireless network and will hereafter be referred to as the TOE throughout this document. A typical Wireless LAN access system is showed in figure 1: Figure 1 TOE usage scenario. The wireless Access Controllers (ACs) are wireless switch appliances that provide a wide range of security services and features including wireless network mobility, security, centralized management, auditing, authentication, and remote access. The access point (AP) appliances service wlan clients. ## 1.3 TOE Type The TOE is a distributed network device composed of one wireless Access Controller (AC) and at least one Access Point (AP) from Table 4, used to build WLAN access systems. The system ensures that wireless clients (STAs) complete authentication via a centralized authentication server, and provides an IEEE 802.11 - compliant encrypted link to prevent unauthorized disclosure or tampering of wireless communications. It also supports centralized management and operation of the organization ' s wireless infrastructure. ## 1.4 TOE Evaluated Configuration The H3C wireless controller and access point evaluation objects use a distributed deployment. The evaluation configuration requirements must include at least one wireless local area network (WLAN) controller and one access point (AP). The TOE supports Non-FIPS mode and FIPS mode. In FIPS mode, a TOE meets strict security requirements, uses only approved cryptography, and performs self-tests on cryptography modules to verify that the modules are operating correctly. A TOE in FIPS mode also meets the functionality requirements defined in Network Device Protection Profile (NDPP) of Common Criteria (CC). FIPS mode must be enabled in order for the TOE to be operating in its CC evaluated configuration. Each TOE appliance runs Comware software and offers wireless access of network traffic. The TOE appliance can also be the destination of network traffic, where it provides interfaces for its own management. The AP is connected to the AC via wired Ethernet Local Area Network (LAN) over an IP network or wired directly to the AC. The management and control tunnel between AP and AC is protected using DTLS and TLS. For DTLS/TLS security domain establishment (in the FIPS mode): - ⚫ Certificate-based authentication: The AP verifies the AC's certificate by checking the title of the certificate. Users can further configure AP to validate the certificate chain up to a pre-installed root CA, validate the certificate's expiration date and digital signature, and check the certificate revocation list (CRL). - ⚫ Prerequisites for AP-AC connection: The AC must pre-configure an AP template. The AP tunnel encryption must be enabled in the AP template. - ⚫ Key exchange: the TOE supports generating ephemeral ECDH keys for the TLS/DTLS. - ⚫ Cipher suite enforcement: Only ECDHE cipher suites (e.g., TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256) are allowed. - ⚫ when it goes online. When the AP connects to the AC, it automatically switches to FIPS mode. Running mode: AP will follow AC's mode configuration The TOE may be accessed and managed through a PC or terminal in the environment which can be remote from or directly connected to the TOE. The TOE can be configured to forward its audit records to an external audit server in the network environment, and this audit server is connected to the TOE through an IPsec tunnel. The TOE can also be configured to work with a Network Time Server (NTP Server). TOE supports authentication server connection through IPsec tunnel. SSH clients on PCs can also connect to TOE through encrypted channels. Figure 1 and Figure 2 shows the TOE depicted in its intended environment. Figure 2 TOE usage scenario. The hardware of the TOE is composed of one Access Controller, a physical network device that supports modules that serve to offer a wide range of network ports varying in number, form factor (copper or fiber), and performance; and at least one Access Point, a physical network device which provides the connection point between wlan client hosts and the wired network. The software of the TOE executes entirely within the TOE hardware. ## 1.5 Required non-TOE Hardware/Software/Firmware The blue area in Figure 2 is the evaluate scope, while the grey area is for test assistance and is outside the evaluate scope. The TOE may require the following hardware, software, and firmware in the IT environment when it is configured depending on the Security Administrator's option. Table 3 Components of the environment | Component | Required | Scope | Description | |-----------------------|------------|---------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | Audit Server | Optional | No | Used to receive audit records, including any audit server to which the TOE will transmit audit record messages. The device will generate audit log records locally, and when the TOE is configured to send audit records to an external server, it will also send these logs to that server. | | SSH Client | Optional | No | The SSH remote connection can access the TOE, which includes any device with an SSH client installed and used to establish a protected channel with the TOE. | | Local console | Mandatory | No | TOE supports CLI access, and the administrator needs to use a terminal emulation program to operate the management interface. This includes connecting directly to the TOE via the serial console port, with the TOE administrator executing TOE management tasks on the console. | | Authentication Server | Optional | No | AAA (Authentication Authorization Accounting), implemented in accordance with related RFC, provides authentication, authorization and accounting functionalities. The TOE can be configured to utilize external authentication servers. Required when using external AAA services per RFC standards 。 | | NTP Server | Optional | No | Network Time Protocol (NTP) is an application layer protocol in the TCP/IP protocol suite. Time synchronization between the NTP server and NTP client is used to keep the TOE ' s real-time clock in sync with other network devices. | | WLAN Client | Optional | No | WLAN clients are wireless terminal equipment, such as smartphones, that can access the Internet via the TOE and are essential for implementing the wireless access function. The WLAN client establishes an encrypted IEEE 802.11 connection with the TOE to protect data in wireless transmission from leakage and tampering. | ## 1.6 TOE Description The H3C Wireless controller and access point (TOE) provide wireless clients with the capability to access organizational network resources. The TOE consists of two independent component devices: - ⚫ The wireless access point (AP) uses the IEEE 802.11 standard to implement data communications with wireless clients. Its functions include broadcasting presence signals (beacons), responding to wireless network probe requests, executing 802.11 station authentication and association, encryption/decryption, and session management. - ⚫ The wireless local area network (WLAN) controller ensures that wireless client ' s complete authentication and generates cryptographic keys in accordance with the IEEE 802.11 standard. The TOE uses IEEE 802.1X, PSK, and other protocols to ensure that only after the requester passes authentication is wireless client traffic allowed into the organization ' s wired network. The wireless controller centrally manages all access points. After an AP register with the AC device, both sides use DTLS and TLS protocols to establish an encrypted tunnel for centralized management and configuration. AP does not provide local management functions except for temporarily importing certificates before connecting to AC. This internal channel also ensures the security of IEEE key distribution between the AC and AP. Secure remote management of the wireless controller is implemented through SSH, with an authentication failure handling mechanism in place. The TOE logs can be sent in real time to the log server. The TOE can obtain time using an NTP server, and it interacts with the authentication server via the RADIUS protocol. All of these can be protected via the IPsec protocol. ## 1.7 Physical Scope The TOE includes a total of 4 different AC series and 6 AP series: Table 4 TOE models in scope | Family | Type | Product Series | Models | Firmware | |------------|-------------------|------------------|------------------------------------------------------------------------------------------------|--------------------------------------------------------| | Comware V7 | Access Controller | WX5800 Series | WX5860X | H3C Comware Software, Version 7.1.064, Release 5484P50 | | Comware V7 | Access Controller | WX2800 Series | WX2880X, WX2860X, WX2812X-PWR | H3C Comware Software, Version 7.1.064, Release 5817P50 | | Comware V7 | Access Controller | WSG1800 Series | WSG1840X, WSG1812X-PWR, WSG1808X-PWR | H3C Comware Software, Version 7.1.064, Release 5817P50 | | Comware V7 | Access Point | WA6500 Series | WA6520, WA6526, WA6526E, WA6520H, WA6120, WA6120H, WA6120X, WA6126, WA6020, WA6022H, WA6520-SI | H3C Comware Software, Version 7.1.064, Release 2617P50 | | Comware V7 | Access Point | WA7200 Series | WA7220-HI, WA7130, WA7120, WA7120X, WA7220X, WA7220CE, WA7232, WA7226E, WA7226 | H3C Comware Software, Version 7.1.064, Release 2617P50 | | Comware V7 | Access Point | WA7300 Series | WA7320i, WA7338-HI, WA7330X, WA7330i, WA7320XE, WA7322H-HI, WA7320, WA7320H-HI, WA7120H | H3C Comware Software, Version 7.1.064, Release 2617P50 | | Comware V7 | Access Point | WA7500 Series | WA7539 | H3C Comware Software, Version 7.1.064, Release 2617P50 | | Comware V7 | Access Point | WA7600 Series | WA7638, WA7620CE, WA7630X, WA7610E-T, WA7628XE | H3C Comware Software, Version 7.1.064, Release 2617P50 | | Comware V7 | Access Point | CPE Series | CPE5100X | H3C Comware Software, Version 7.1.064, Release 2617P50 | | Comware V9 | Access Controller | WX3800 Series | WX3840X, WX3820X | H3C Comware Software, Version 9.1.061, ESS 1404P50 | All V7 Wireless Controllers (WX5860X, WX2880X, WX2860X, WX2812X-PWR, WSG1840X, WSG1812X-PWR, WSG1808X-PWR) run the same Comware Version 7.1 software. The difference between Wireless Controllers under the same software version is the physical port type, number of the physical ports, manageable number of APs, manageable number of wireless users. All V9 Wireless Controllers (WX3840X, WX3820X) run the same Comware Version 9.1 software. The difference between controllers under Version 7.1 and Version 9.1 is that, Version 9.1 has been adjusted and optimized in its internal architecture, and its features are based on modular fine-grained. Compared with Version 7.1, it supports more forms, such as containerized forms. In terms of security functions, Version 9.1 fully inherits the functional specifications of Version 7.1, so the security functions of Version 9.1 and Version 7.1 are consistent. The APs of TOE include three types: Indoor AP (ceilings and are not physical reachable), Outdoor AP (hanging high and are not physical reachable), wall plate AP (wall mounted and physical reachable, but do not have user management interface). The AP provides the connection point between wlan client hosts and the wired network. The APs also communicate directly with the wireless controller for management purposes. The management traffic between H3C AP and H3C Wireless Access Controller is encrypted using DTLS and TLS. All H3C APs run the same Comware Version 7.1 software. The difference between AP models under the same software version is the radio properties, MIMO properties, the physical port type, number of physical ports. H3C AP do not have user interface used for administration or configuration of the AP component. All administration and configuration of the H3C AP component occurs through the H3C Access Controller component. TOE Delivery The delivery of the TOE to the customer is performed by an authorized courier service. TOE firmware can be obtained from the H3C official website or by contacting H3C engineers. Please download the installation guides from the official website. Please download Troubleshooting and Log Message References from the official website. Follow the latest version number on the website. The guidance document (AGD:H3C Wlan series Preparative and Operative Procedures) is delivered by email. Configuration guides and Command References are delivered by email. Installation Guides are in PDF format. Configuration Guides and Command References are chm format. The AGD is in docs or PDF format. | Models | Item | Name | Version | |---------------------------------------------------------------------|----------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-------------------------------------| | WX5860X | Installation Guides | H3C WX5860X Access Controllers Installation Guide | 5W104 | | WX5860X | Command References | H3C WX5800X Series Access Controllers Command References | 6W100 | | WX5860X | Configuration Guides | H3C WX5800X Series Access Controllers Configuration Guides | 6W100 | | WX2880X, WX2860X, WX2812X-PWR, WSG1840X, WSG1812X-PWR, WSG1808X-PWR | Installation Guides | H3C WX2880X Access Controllers Installation Guide H3C WX2860X Access Controllers Installation Guide H3C WX2812X-PWR Access Controllers Installation Guide H3C WSG1840X Wireless Integrated Services Gateway Installation Guide H3C WSG1812X-PWR Wireless Integrated Services Gateway Installation Guide H3C WSG1808X-PWR Wireless Integrated Services Gateway Installation Guide | 6W101 6W101 5W103 5W103 5W104 5W101 | | WX2880X, WX2860X, WX2812X-PWR, WSG1840X, WSG1812X-PWR, WSG1808X-PWR | Command References | H3C WX2800X&WSG1800X Command References | 6W100 | | WX2880X, WX2860X, WX2812X-PWR, WSG1840X, WSG1812X-PWR, WSG1808X-PWR | Configuration Guides | H3C WX2800X&WSG1800X Configuration Guides | 6W100 | | WA6520 | Installation Guides | H3C WA6520 Access Point Installation Guide | 5W101 | | WA6520-SI | Installation Guides | H3C Wi-Fi6 Indoor Access Points Installation Guide | 6W105 | | WA6526, WA6526E, WA6126 | Installation Guides | H3C Wi-Fi6 Indoor Access Points Installation Guide | 6W104 | | WA6520H | Installation Guides | H3C WA6520H Access Point Installation Guide | 5W100 | | CPE5100X | Installation Guides | H3C CPE5100X 5G Customer Premises Equipment Installation Guide | 6W100 | | WA6120 | Installation Guides | H3C WA6120 Access Point Installation Guide | 6W100 | | WA6120H | Installation Guides | H3C WA6120H Access Point Installation Guide | 6W100 | | WA6120X | Installation Guides | H3C WA6120X Access Point Installation Guide | 5W101 | | WA6020 | Installation Guides | H3C WA6020 Access Point Installation Guide | 6W100 | |-----------------------------------------------|-----------------------|----------------------------------------------------|---------| | WA6022H | Installation Guides | H3C WA6022H Access Point Installation Guide | 6W100 | | WA7130 | Installation Guides | H3C WA7130 Access Point Installation Guide | 5W100 | | WA7120 | Installation Guides | H3C WA7120 Access Point Installation Guide | 5W100 | | WA7120H | Installation Guides | H3C WA7120H Access Point Installation Guide | 5W100 | | WA7120X | Installation Guides | H3C WA7120X Access Point Installation Guide | 5W100 | | WA7220X | Installation Guides | H3C WA7220X Access Point Installation Guide | 5W100 | | WA7220CE | Installation Guides | H3C WA7220CE Access Point Installation Guide | 5W100 | | WA7226 | Installation Guides | H3C WA7226 Access Point Installation Guide | 5W100 | | WA7226E | Installation Guides | H3C WA7226E Access Point Installation Guide | 5W100 | | WA7232 | Installation Guides | H3C WA7232 Access Point Installation Guide | 5W100 | | WA7322H-HI | Installation Guides | H3C WA7322H-HI Access Point Installation Guide | AW100 | | WA7220-HI, WA7338-HI, WA7320i, WA7539, WA7638 | Installation Guides | H3C Wi-Fi7 Indoor Access Points Installation Guide | 5W106 | | WA7330i | Installation Guides | H3C Wi-Fi7 Indoor Access Points Installation Guide | 5W107 | | WA7320 | Installation Guides | H3C WA7320 Access Point Installation Guide | 5W100 | | WA7320H-HI | Installation Guides | H3C WA7320H-HI Access Point Installation Guide | 5W100 | | WA7320XE | Installation Guides | H3C WA7320XE Access Point Installation Guide | 5W100 | | WA7330X | Installation Guides | H3C WA7330X Access Point Installation Guide | 5W100 | | WA7620CE | Installation Guides | H3C WA7620CE Access Point Installation Guide | 5W101 | | WA7630X | Installation Guides | H3C WA7630X Access Point Installation Guide | 5W100 | | WA7610E-T | Installation Guides | H3C WA7610E-T Access Point Installation Guide | 5W100 | | WA7628XE | Installation Guides | H3C WA7628XE Access Point Installation Guide | 5W100 | Table 5 TOE deliverables | WX3840X, WX3820X | Installation Guides | H3C WX3840X Access Controllers Installation Guide H3C WX3820X Access Controllers Installation Guide | 6W105 6W105 | |--------------------|-----------------------|-------------------------------------------------------------------------------------------------------|---------------| | | Command References | H3C WX3800X Series Access Controllers Command References | 6W100 | | | Configuration Guides | H3C WX3800X Series Access Controllers Configuration Guides | 6W100 | ## 1.8 Logical Scope The TOE provides the following functionality: - ⚫ Security audit - ⚫ Communication - ⚫ Cryptographic support - ⚫ Identification and authentication - ⚫ Security management - ⚫ Protection of the TSF - ⚫ TOE access - ⚫ Trusted path/channels. These features are described in more detail in the subsections below. ### 1.8.1 Security audit The TOE is designed to be able to generate logs for a wide range of security relevant events. The TOE can be configured to store the logs locally so they can be accessed by an administrator and to send the logs to a designated external AUDIT server to mitigate the possibility of losing audit records when available space becomes exhausted on the TOE. Locally stored audit records can be reviewed and managed by an administrator. ### 1.8.2 Communication The Security Administrator can manage, enable and disable the communication between the different parts of the TOE (Access Controller and Access Points). The communication between this part is protected with DTLS and TLS. ### 1.8.3 Cryptographic support The TOE includes a cryptographic module that provides random bit generation, key management, encryption/decryption, digital signature, secure hashing and key-hashing features in support of higher-level cryptographic protocols including IPsec, SSH, TLS/DTLS to provide a trusted path for remote administration. ### 1.8.4 Identification and authentication The TOE requires users (i.e., administrators) to be successfully identified and authenticated before they can access any security management functions available in the TOE. The TOE offers both a locally connected console as well as network accessible interfaces (e.g., SSH,) for interactive administrator sessions. The TOE supports the local definition of users with usernames and roles that can be authenticated with passwords or Public-Key. The TOE has policies to force the passwords to meet security requirements and can prevent bruteforcing it. The TOE supports roles to control permissions for administrators (i.e., network-admin and security- auditor are authorized administrators). Additionally, TOE can configure IPSEC connected RADIUS servers for authentication services to support e.g., centralized user management. ### 1.8.5 Security management The TOE provides Command Line (CLI) commands to access the wide range of security management functions. Security management are limited to administrators only after they have provided acceptable user identification and authentication data to the TOE. ### 1.8.6 Protection of the TSF The TOE protects the pre-shared keys, symmetric keys, and private keys from reading them by an unauthorized entity. The TOE stores the users or administrator passwords in non-plaintext form preventing them from reading. The TOE verifies the packet before their installation and uses the digital signature. The TOE performs self-tests on its power on to ensure its correct behaviour. ### 1.8.7 TOE access The TOE can be configured to display advisory banners when user ' s login and will enforce an administrator-defined inactivity timeout value after which an inactive session will be terminated, allowing also the capability of selfterminate its session for the administrator. ### 1.8.8 Trusted path/channels. The TOE uses IPsec to provide an encrypted channel between itself and third-party trusted IT entities in the operating environment including external audit server, external authentication server and NTP server. The TOE secures remote communication with administrators by implementing SSHv2 for CLI access. the integrity and disclosure protection are ensured via the secure protocol. Wlan Clients establish an encrypted IEEE 802.11 link with TOE that protects wireless data in transit from disclosure and modification. ## 1.9 Excluded Functionality The device has two modes: FIPS mode and non-FIPS mode. The device must be configured to operate in FIPS mode, in which the TOE only supports functions compliant with the CC standard. TOE testing must have FIPS mode enabled in order to run in its evaluated configuration. Non-FIPS mode is not included in the evaluation testing and is considered an excluded function. The excluded functionality does not affect the TOE ' s conformance to the claimed Protection Profiles. ### 2 Conformance claims ## 2.1 CC Conformance Claim This Security Target claims conformance to the Common Criteria 2022 release 1 [CC2] [CC3]: - Common Criteria for Information Technology Security Evaluation, Part 2 [CC2]: Security functional components, CC:2022 Revision 1. November 2022 as CC Part 2 extended. - Common Criteria for Information Technology Security Evaluation, Part 3 [CC3]: Security assurance components, CC:2022 Revision 1. November 2022 as CC Part 3 conformant. The methodology used in the evaluation is [CEM]: - Common Methodology for Information Technology Security Evaluation, Evaluation methodology, CC:2022 Revision 1. November 2022.Conformance Rationale ## 2.2 PP Conformance The ST follows PP-Configuration for Network Devices and Wireless Local Area Network Access Systems V2.0 [PPCONFIG] . Since the PP isn ' t certified no claims of conformance are made to it. ## 2.3 Package Conformance The ST claims conformance to the following assurance packages: EAL2+ augmented with ALC_FLR.2 from [CC5] The ST claims conformance to the following functional packages: Functional Package for SSH Version 1.0 [PPSSH] ## 2.4 Conformance Rationale Since the ST only claims conformance to the SSH functional package, the conformance rationale is provided below: | Package SFR | Available in ST | |----------------|--------------------------------| | FCS_SSH_EXT.1 | Yes | | FCS_SSHC_EXT.1 | No (Optional SFR not required) | | FCS_SSHS_EXT.1 | Yes | ### 3 Security Problem Definition The Security Problem Definition is taken from the Security Problem Definition (composed of organizational policies, threat statements, and assumption) described in the Network Devices PP [PP-ND] and PP-Module for Wireless Local Area Network (WLAN) Access System, Version 1.0 (MOD_WLAN_AS_V1.0) [EPWLAN]. ## 3.1 Threats The threats for the Network Device are grouped according to functional areas of the device in the sections below. ### 3.1.1 T.UNAUTHORIZED_ADMINSTRATOR_ACCESS Threat agents may attempt to gain Administrator access to the Network Device by nefarious means such as masquerading as an Administrator to the device, masquerading as the device to an Administrator, replaying an administrative session (in its entirety, or selected portions), or performing man-in-the-middle attacks, which would provide access to the administrative session, or sessions between Network Devices. Successfully gaining Administrator access allows malicious actions that compromise the security functionality of the device and the network on which it resides. ### 3.1.2 T.WEAK_CRYPTOGRAPHY Threat agents may exploit weak cryptographic algorithms or perform a cryptographic exhaust against the key space. Poorly chosen encryption algorithms, modes, and key sizes will allow attackers to compromise the algorithms, or brute force exhaust the key space and give them unauthorized access allowing them to read, manipulate and/or control the traffic with minimal effort. ### 3.1.3 T.UNTRUSTED_COMMUNICATION_CHANNELS Threat agents may attempt to target Network Devices that do not use standardized secure tunnelling protocols to protect the critical network traffic. Attackers may take advantage of poorly designed protocols or poor key management to successfully perform man-in-the-middle attacks, replay attacks, etc. Successful attacks will result in loss of confidentiality and integrity of the critical network traffic, and potentially could lead to a compromise of the Network Device itself. ### 3.1.4 T.WEAK_AUTHENTICATION_ENDPOINTS Threat agents may take advantage of secure protocols that use weak methods to authenticate the endpoints, e.g., a shared password that is guessable or transported as plaintext. The consequences are the same as a poorly designed protocol, the attacker could masquerade as the Administrator or another device, and the attacker could insert themselves into the network stream and perform a man-in-the-middle attack. The result is the critical network traffic is exposed and there could be a loss of confidentiality and integrity, and potentially the Network Device itself could be compromised. ### 3.1.5 T.UPDATE_COMPROMISE Threat agents may attempt to provide a compromised update of the software or firmware which undermines the security functionality of the device. Non-validated updates or updates validated using non-secure or weak cryptography leave the update firmware vulnerable to surreptitious alteration. ### 3.1.6 T.UNDETECTED_ACTIVITY Threat agents may attempt to access, change, and/or modify the security functionality of the Network Device without Administrator awareness. This could result in the attacker finding an avenue (e.g., misconfiguration, flaw in the product) to compromise the device and the Administrator would have no knowledge that the device has been compromised. ### 3.1.7 T.SECURITY_FUNCTIONALITY_COMPROMISE Threat agents may compromise credentials and device data enabling continued access to the Network Device and its critical data. The compromise of credentials includes replacing existing credentials with an attacker ' s credentials, modifying existing credentials, or obtaining the Administrator or device credentials for use by the attacker. Threat agents may also be able to take advantage of weak administrative passwords to gain privileged access to the device. ### 3.1.8 T.SECURITY_FUNCTIONALITY_FAILURE An external, unauthorized entity could make use of failed or compromised security functionality and might therefore subsequently use or abuse security functions without prior authentication to access, change or modify device data, critical network traffic or security functionality of the device. ### 3.1.9 T.NETWORK_DISCLOSURE Devices on a protected network may be exposed to threats presented by devices located outside the protected network, which may attempt to conduct unauthorized activities. If malicious external devices are able to communicate with devices on the protected network, or if devices on the protected network can establish communications with those external devices (e.g., as a result of non-existent or insufficient WLAN data encryption that exposes the WLAN data in transit to rogue elements), then those internal devices may be susceptible to the unauthorized disclosure of information. ### 3.1.10 T.NETWORK_ACCESS Devices located outside the protected network may seek to exercise services located on the protected network that are intended to be only accessed from inside the protected network or only accessed by entities using an authenticated path into the protected network. ### 3.1.11 T.TSF_FAILURE Security mechanisms of the TOE generally build up from a primitive set of mechanisms (e.g., memory management, privileged modes of process execution) to more complex sets of mechanisms. Failure of the primitive mechanisms could lead to a compromise in more complex mechanisms, resulting in a compromise of the TOE Security Functionality (TSF). ### 3.1.12 T.DATA_INTEGRITY Devices on a protected network may be exposed to threats presented by devices located outside the protected network, which may attempt to modify the data without authorization. If known malicious external devices are able to communicate with devices on the protected network or if devices on the protected network can establish communications with those external devices then the data contained within the communications may be susceptible to a loss of integrity. ### 3.1.13 T.REPLAY_ATTACK If an unauthorized individual successfully gains access to the system, the adversary may have the opportunity to conduct a ' replay ' attack. This method of attack allows the individual to capture packets traversing throughout the wireless network and send the packets at a later time, possibly unknown by the intended receiver. ## 3.2 Assumptions This section describes the assumptions made in identification of the threats and security requirements for Network Devices. The Network Device is not expected to provide assurance in any of these areas, and as a result, requirements are not included to mitigate the threats associated. ### 3.2.1 A.PHYSICAL_PROTECTION The Network Device is assumed to be physically protected in its operational environment and not subject to physical attacks that compromise the security or interfere with the device ' s physical interconnections and correct operation. This protection is assumed to be sufficient to protect the device and the data it contains. As a result, the ST does not include any requirements on physical tamper protection or other physical attack mitigations. The ST does not expect the product to defend against physical access to the device that allows unauthorized entities to extract data, bypass other controls, or otherwise manipulate the device. ### 3.2.2 A.LIMITED_FUNCTIONALITY The device is assumed to provide networking functionality as its core function and not provide functionality/services that could be deemed as general-purpose computing. For example, the device should not provide a computing platform for general purpose applications (unrelated to networking functionality). ### 3.2.3 A.NO_THRU_TRAFFIC_PROTECTION A standard/generic Network Device does not provide any assurance regarding the protection of traffic that traverses it. The intent is for the Network Device to protect data that originates on or is destined to the device itself, to include administrative data and audit data. Traffic that is traversing the Network Device, destined for another network entity, is not covered by the ST. It is assumed that this protection will be covered by cPPs and PP-Modules for particular types of Network Devices (e.g., firewall). ### 3.2.4 A.TRUSTED_ADMINISTRATOR The Security Administrator(s) for the Network Device are assumed to be trusted and to act in the best interest of security for the organization. This includes appropriately trained, following policy, and adhering to guidance documentation. Administrators are trusted to ensure passwords/credentials have sufficient strength and entropy and to lack malicious intent when administering the device. The Network Device is not expected to be capable of defending against a malicious Administrator that actively works to bypass or compromise the security of the device. For TOEs supporting X.509v3 certificate-based authentication, the Security Administrator(s) fully validate any CA certificate (root CA certificate or intermediate CA certificate) loaded into the TOE ' s trust store as a trust anchor prior to use. ### 3.2.5 A.REGULAR_UPDATES The Network Device firmware and software is assumed to be updated by an Administrator on a regular basis in response to the release of product updates due to known vulnerabilities. ### 3.2.6 A.ADMIN_CREDENTIALS_SECURE The Administrator ' s credentials (private key) used to access the Network Device are protected by the platform on which they reside. ### 3.2.7 A.COMPONENTS_RUNNING (applies to distributed TOEs only) For distributed TOEs it is assumed that the availability of all TOE components is checked as appropriate to reduce the risk of an undetected attack on (or failure of) one or more TOE components. It is also assumed that in addition to the availability of all components it is also checked as appropriate that the audit functionality is running properly on all TOE components. ### 3.2.8 A.RESIDUAL_INFORMATION The Administrator must ensure that there is no unauthorized access possible for sensitive residual information (e.g., cryptographic keys, keying material, PINs, passwords etc.) on networking equipment when the equipment is discarded or removed from its operational environment. - 3.2.9 A.CONNECTIONS It is assumed that the TOE is connected to distinct networks in a manner that ensures that the TOE's security policies will be enforced on all applicable network traffic flowing among the attached networks. ## 3.3 Organizational Security Policy - 3.3.1 P.ACCESS_BANNER The TOE shall display an initial banner describing restrictions of use, legal agreements, or any other appropriate information to which Administrators consent by accessing the TOE. ### 4 Security Objectives ## 4.1 Security Objectives for the TOE Security Objectives for the TOE are added to comply with ASE_OBJ.2 for EAL2. ### 4.1.1 O.ADMIN_AUTH The TOE shall require identification and authentication of administrators before granting them access to the TOE management functions. The TOE management capabilities available to administrators shall be defined and limited, and actions available prior to authentication shall be limited and constrained. Administrators' authentication process shall consist in local authentication on the TOE using passwords through a secure communication channel, and authentication sessions will be closed by the TOE after a defined period of inactivity. ### 4.1.2 O.STRONG_CRYPTO The TOE shall use robust cryptographic algorithms, compliant to industry approved standards, in order to provide robust cryptographic protection of network communications. ### 4.1.3 O.TRUSTED_COMM The TOE shall implement secure channels that use standardized tunnelling protocols to protect the critical network traffic, ensuring protection of the communications between the TOE and trusted external entities in confidentiality, integrity, and protection against communication replays. ### 4.1.4 O.STRONG_AUTHENTICATION_ENDPOINT The TOE shall implement methods for robust and reliable authentication of trusted entities with the TOE, preventing attacks based on weak authentication methods (e.g., guessing or transported shared keys). ### 4.1.5 O.SECURE_UPDATES The TOE shall provide to administrators the capability of installing software or firmware updates only after a successful verification of their authenticity using secure and strong cryptographic algorithms based on digital signatures. ### 4.1.6 O.ACTIVITY_AUDIT The TOE shall generate audit records for relevant management actions carried by administrators. Audit records will be marked with precise timestamps, associated to user identity, and protected from unauthorized modification or deletion. ### 4.1.7 O.PASSWORD_PROTECTION The TOE shall protect the passwords for local administrator authentication by enforcing complexity and quality rules. Also, the TOE shall limit failed authentication attempts and limit the feedback given to users on failed authentications, in order to prevent brute force or guessing attacks. Also, the TOE shall perform secure storage of passwords, refraining from storing them in plaintext. ### 4.1.8 O.SELF_TEST The TOE shall perform self-tests of the TSF functionality in order to detect potential failures during start-up or operation and prevent further situations that could lead to malfunction. ### 4.1.9 O.BANNER The TOE shall display an advisory notice and consent about use of the TOE to administrators before establishing an administrative user session. ### 4.1.10 O.CRYPTOGRAPHIC_FUNCTIONS The TOE will provide means to encrypt and decrypt data to maintain confidentiality and allow for detection of modification of TSF data that is transmitted outside the TOE. ### 4.1.11 O.AUTHENTICATION The TOE will provide a means to authenticate the user to ensure they are communicating with an authorized external IT entity. ### 4.1.12 O.FAIL_SECURE Upon a self-test failure, the TOE will shut down to ensure that data cannot be passed without adhering to the TOE's security policies. ### 4.1.13 O.SYSTEM_MONITORING The TOE will provide a means to audit events specific to WLAN functionality and security. ### 4.1.14 O.TOE_ADMINISTRATION The TOE will provide the functions necessary to address failed authentication attempts by a remote administrator. ## 4.2 Security Objectives for the Operational Environment The Security Objectives for the Operational Environment are taken from the Security Objectives for the Operational Environment described in Section 5.1 of the Network Devices PP [PP-ND], extended with the ones defined in section 4.2 of PP-Module for Wireless Local Area Network (WLAN) Access System, Version 1.0 (MOD_WLAN_AS_V1.0). ### 4.2.1 OE.PHYSICAL Physical security, commensurate with the value of the TOE and the data it contains, is provided by the environment. ### 4.2.2 OE.NO_GENERAL_PURPOSE There are no general-purpose computing capabilities (e.g., compilers or user applications) available on the TOE, other than those services necessary for the operation, administration and support of the TOE. ### 4.2.3 OE.NO_THRU_TRAFFIC_PROTECTION The TOE does not provide any protection of traffic that traverses it. It is assumed that protection of this traffic will be covered by other security and assurance measures in the operational environment. ### 4.2.4 OE.TRUSTED_ADMIN Security Administrators are trusted to follow and apply all guidance documentation in a trusted manner. For TOEs supporting X.509v3 certificate-based authentication, the Security Administrator(s) are assumed to monitor the revocation status of all certificates in the TOE's trust store and to remove any certificate from the TOE ' s trust store in case such certificate can no longer be trusted. ### 4.2.5 OE.UPDATES The TOE firmware and software is updated by an Administrator on a regular basis in response to the release of product updates due to known vulnerabilities. ### 4.2.6 OE.ADMIN_CREDENTIALS_SECURE The Administrator ' s credentials (private key) used to access the TOE must be protected on any other platform on which they reside. ### 4.2.7 OE.COMPONENTS_RUNNING (applies to distributed TOEs only) For distributed TOEs, the Security Administrator ensures that the availability of every TOE component is checked as appropriate to reduce the risk of an undetected attack on (or failure of) one or more TOE components. The Security Administrator also ensures that it is checked as appropriate for every TOE component that the audit functionality is running properly. ### 4.2.8 OE.RESIDUAL_INFORMATION The Security Administrator ensures that there is no unauthorized access possible for sensitive residual information (e.g., cryptographic keys, keying material, PINs, passwords etc.) on networking equipment when the equipment is discarded or removed from its operational environment. ### 4.2.9 OE.CONNECTIONS TOE administrators will ensure that the TOE is installed in a manner that will allow the TOE to effectively enforce its policies on the network traffic of monitored networks. ## 4.3 Tracing SPDs to Security Objectives The following section provides a tracing between SPDs and Security Objectives. | Threats | Security Objectives | |-------------------------------------|---------------------------------------------| | T.UNAUTHORIZED_ADMINISTRATOR_ACCESS | O.ADMIN_AUTH | | T.WEAK_CRYPTOGRAPHY | O.STRONG_CRYPTO | | T.UNTRUSTED_COMMUNICATION_CHANNELS | O.TRUSTED_COMM | | T.WEAK_AUTHENTICATION_ENDPOINTS | O.STRONG_AUTHENTICATION_ENDPOINT | | T.UPDATE_COMPROMISE | O.SECURE_UPDATES | | T.UNDETECTED_ACTIVITY | O.ACTIVITY_AUDIT | | T.SECURITY_FUNCTIONALITY_COMPROMISE | O.PASSWORD_PROTECTION | | T.SECURITY_FUNCTIONALITY_FAILURE | O.SELF_TEST | | T.NETWORK_DISCLOSURE | O.AUTHENTICATION, O.CRYPTOGRAPHIC_FUNCTIONS | | T.NETWORK_ACCESS | O.AUTHENTICATION, O.TOE_ADMINISTRATION | | T.TSF_FAILURE | O.SYSTEM_MONITORING, O.FAIL_SECURE | | T.DATA_INTEGRITY | O.CRYPTOGRAPHIC_FUNCTIONS | | T.REPLAY_ATTACK | O.AUTHENTICATION, O.CRYPTOGRAPHIC_FUNCTIONS | | OSPs | Security Objectives | |-----------------|-----------------------| | P.ACCESS_BANNER | O.BANNER | | Assumptions | Security Objectives for the Operational Environment | |------------------------------|-------------------------------------------------------| | A.PHYSICAL_PROTECTION | OE.PHYSICAL | | A.LIMITED_FUNCTIONALITY | OE.NO_GENERAL_PURPOSE | | A.NO_THRU_TRAFFIC_PROTECTION | OE.NO_THRU_TRAFFIC_PROTECTION | | A.TRUSTED_ADMINISTRATOR | OE.TRUSTED_ADMIN | | A.REGULAR_UPDATES | OE.UPDATES | | A.ADMIN_CREDENTIALS_SECURE | OE.ADMIN_CREDENTIALS_SECURE | | A.COMPONENTS_RUNNING | OE.COMPONENTS_RUNNING | | A.RESIDUAL_INFORMATION | OE.RESIDUAL_INFORMATION | | A.CONNECTIONS | OE.CONNECTIONS | ## 4.4 Security Objectives Rationale ### 4.4.1 Threats #### 4.4.1.1 T.UNAUTHORIZED_ADMINISTRATOR_ACCESS This threat is countered by O.ADMIN_AUTH which requires identification and authentication of administrator before granting them access to the TOE and to management functions. It also enforces that the TOE requires identification and authentication of administrators before granting them access to the TOE management functions. The TOE management capabilities available to administrators shall be defined and limited, and actions available prior to authentication shall be limited and constrained. Administrators' authentication process shall consist in local authentication of the TOE using passwords through a secure communication channel, and authentication sessions will be closed by the TOE after a defined period of inactivity. #### 4.4.1.2 T.WEAK_CRYPTOGRAPHY This threat is countered by O.STRONG_CRYPTO which requires usage of robust cryptographic algorithms, compliant to industry approved standards, in order to provide robust cryptographic protection of network communications. #### 4.4.1.3 T.UNTRUSTED_COMMUNICATION_CHANNELS This threat is countered by O.TRUSTED_COMM which requires secure communication channels that use standardized tunnelling protocols to protect the critical network traffic, ensuring protection of the communications between the TOE and trusted external entities in confidentiality, integrity, and protection against communication replays. #### 4.4.1.4 T.WEAK_AUTHENTICATION_ENDPOINTS This threat is countered by O.STRONG_AUTHENTICATION_ENDPOINT which requires methods for strong authentication of trusted entities with the TOE, preventing attacks based on weak authentication methods. #### 4.4.1.5 T.UPDATE_COMPROMISE This threat is countered by O.SECURE_UPDATES which requires verification of updates authenticity by administrators based on cryptographic digital signatures. #### 4.4.1.6 T.UNDETECTED_ACTIVITY O.ACTIVITY_AUDIT counters T.UNDETECTED_ACTIVITY by generating audit records for relevant management actions to prevent undetected activity. #### 4.4.1.7 T.SECURITY_FUNCTIONALITY_COMPROMISE This threat is countered by O.PASSWORD_PROTECTION which requires the TOE to enforce password complexity and quality in passwords used by administrators for authentication, hence preventing successful attacks to weak passwords. The same objective also forbids plaintext storage of passwords in the TOE and prevents attacks based on massive authentication attempts or guessing passwords from feedback resulting from failed authentication attempts. #### 4.4.1.8 T.SECURITY_FUNCTIONALITY_FAILURE This threat is countered by O.SELF_TEST which requires that The TOE carries outs TSF self-tests in order to detect potential failures during start-up or operation and prevent further situations that could lead to malfunction. #### 4.4.1.9 T.NETWORK_DISCLOSURE The threat T.NETWORK_DISCLOSURE is countered by O.AUTHENTICATION as proper authentication of external entities ensures that network data is not disclosed to an unauthorized subject. The threat T.NETWORK_DISCLOSURE is countered by O.CRYPTOGRAPHIC_FUNCTIONS as implementation of cryptographic functions ensures that network data is not subject to unauthorized disclosure in transit. #### 4.4.1.10 T.NETWORK_ACCESS The threat T.NETWORK_ACCESS is countered by O.AUTHENTICATION as proper authentication methods ensure that subjects outside the protected network cannot access data inside the protected network until the TSF has authenticated them. The threat T.NETWORK_ACCESS is countered by O.TOE_ADMINISTRATION as the TOE's administration function does not permit execution of management functions that originate from wireless clients outside the protected network. #### 4.4.1.11 T.TSF_FAILURE The threat T.TSF_FAILURE is countered by O.FAIL_SECURE as the TOE responds to self-test failures that are significant enough to show a potential compromise of the TSF by making the TSF unavailable until the failure state has been cleared. The threat T.TSF_FAILURE is countered by O.SYSTEM_MONITORING as the TOE generates audit records of unauthorized usage, communications outages, incorrect configuration, and other behaviors that may indicate a degraded ability to enforce its intended security functionality so that issues can be diagnosed and resolved appropriately. #### 4.4.1.12 T.DATA_INTEGRITY The threat T.DATA_INTEGRITY is countered by O.CRYPTOGRAPHIC_FUNCTIONS as the TOE uses cryptographic functionality to enforce the integrity of protected data in transit. #### 4.4.1.13 T.REPLAY_ATTACK The threat T.REPLAY_ATTACK is countered by O.AUTHENTICATION as the TOE's use of authentication mechanisms prevent replay attacks because the source of the attack will not have the proper authentication data for the TSF to process the replayed traffic. The threat T.REPLAY_ATTACK is countered by O.CRYPTOGRAPHIC_FUNCTIONS as the TOE's use of cryptographic functionality prevents impersonation attempts that use replayed traffic. ### 4.4.2 OSP #### 4.4.2.1 P.ACCESS_BANNER This policy is enforced by O.BANNER which requires that the TOE displays an advisory notice and consent about use of the TOE to administrators before establishing an administrative user session. ### 4.4.3 Assumptions #### 4.4.3.1 A.PHYSICAL_PROTECTION This assumption is directly upheld by OE.PHYSICAL, which requires that physical protection to the TOE is provided by the operational environment. #### 4.4.3.2 A.LIMITED_FUNCTIONALITY A.LIMITED_FUNCTIONALITY is upheld by OE.NO_GENERAL_PURPOSE. #### 4.4.3.3 A.NO_THRU_TRAFFIC_PROTECTION This assumption is directly upheld by OE.NO_THRU_TRAFFIC_PROTECTION, which requires that the TOE does not provide any protection of traffic that traverses it, but such protection is covered by other security and assurance measures in the operational environment. #### 4.4.3.4 A.TRUSTED_ADMINISTRATOR This assumption is directly upheld by OE.TRUSTED_ADMIN, which requires that TOE Administrators are trusted to follow and apply all guidance documentation in a trusted manner. #### 4.4.3.5 A.REGULAR_UPDATES This assumption is directly upheld by OE.UPDATES, which requires that the TOE firmware and software is updated by an administrator on a regular basis in response to the release of product updates due to known vulnerabilities. #### 4.4.3.6 A.ADMIN_CREDENTIALS_SECURE This assumption is directly upheld by OE.ADMIN_CREDENTIALS_SECURE, which requires that the administrator ' s credentials (private key) used to access the TOE are protected on any other platform on which they reside. #### 4.4.3.7 A.RESIDUAL_INFORMATION This assumption is directly upheld by OE.RESIDUAL_INFORMATION which requires administrators to ensure that there is no unauthorized access possible for sensitive residual information on networking equipment when the equipment is discarded or removed from its operational environment. #### 4.4.3.8 A.CONNECTIONS The OE objective OE.CONNECTIONS is realized through A.CONNECTIONS. ### 5 Extended Component Definition Extended Component Definition has been taken from the Network Devices PP [PP-ND] with the modifications provided by the Functional package [PPSSH] and PP-Module for Wireless Local Area Network (WLAN) Access System, Version 1.0 (MOD_WLAN_AS_V1.0) [EPWLAN]. #### Extended SFRs: PP-ND&EPWLAN: FAU_GEN_EXT.1: Security Audit Generation PP-ND&EPWLAN: FAU_STG_EXT.1: Protected Audit Event Storage PP-ND&EPWLAN: FAU_STG_EXT.4: Protected Local Audit Event Storage for Distributed TOEs PP-ND: FAU_STG_EXT.5 Protected Remote Audit Event Storage for Distributed TOEs PP-ND&EPWLAN: FCO_CPC_EXT.1 Component Registration Channel Definition PP-ND: FCS_IPSEC_EXT.1: IPsec Protocol PP-ND: FCS_NTP_EXT.1: NTP Protocol PPSSH: FCS_SSHS_EXT.1: SSH Server Protocol PPSSH: FCS_SSH_EXT.1: SSH Protocol PP-ND: FCS_DTLSC_EXT.1: DTLS Client Protocol Without Mutual Authentication PP-ND: FCS_DTLSS_EXT.1: DTLS Server Protocol Without Mutual Authentication PP-ND: FCS_TLSC_EXT.1: TLS Client Protocol Without Mutual Authentication PP-ND: FCS_TLSS_EXT.1: TLS Server Protocol Without Mutual Authentication EPWLAN: FIA_8021X_EXT.1: 802.1X Port Access Entity (Authenticator) Authentication PP-ND: FIA_PMG_EXT.1: Password Management PP-ND: FIA_UIA_EXT.1: User Identification and Authentication PP-ND: FIA_X509_EXT.1/Rev: X.509 Certificate Validation PP-ND: FIA_X509_EXT.1/ITT X.509 Certificate Validation PP-ND: FIA_X509_EXT.2: X.509 Certificate Authentication PP-ND: FIA_X509_EXT.3: X.509 Certificate Requests PP-ND: FCO_CPC_EXT.1 Component Registration Channel Definition EPWLAN: FMT_SMR_EXT.1: No Administration from Client PP-ND: FPT_APW_EXT.1: Protection of Administrator Passwords PP-ND: FPT_SKP_EXT.1: Protection of TSF Data (for reading of all pre-shared, symmetric and private keys) PP-ND&EPWLAN: FPT_TST_EXT.1: TSF testing PP-ND: FPT_TUD_EXT.1: Trusted update PP-ND: FTA_SSL_EXT.1: TSF-initiated Session Locking ### 6 Security Functional Requirements The conventions used in descriptions of the SFRs are as follows: - Unaltered SFRs are stated in the form used in [CC2] or their extended component definition (ECD); - Refinement made in the PP or ST: the refinement text is indicated with bold text and strikethroughs; - Selection wholly or partially completed in the PP or ST: the selection values are indicated with underlined text e.g., ' [selection: disclosure, modification, loss of use ] ' in [CC2] or an ECD might become ' disclosure ' (completion) or ' [selection: disclosure, modification] ' (partial completion) in the ST; - Assignment wholly or partially completed in the PP or ST: indicated with italicized text ; - Assignment completed within a selection in the PP or ST: the completed assignment text is indicated with italicized and underlined text e.g., ' [selection: change_default, query, modify, delete, [assignment: other operations] ] ' in [CC2] or an ECD might become ' change_default, select tag ' (completion of both selection and assignment) or ' [selection: change_default, select tag , select value ] ' (partial completion of selection, and completion of assignment) in the ST; - Iteration: indicated by adding a string starting with ' / ' (e.g., ' FCS_COP.1/Hash ' ). All the application notes defined in the PP [PP-ND] have been considered when writing this document. Please refer to the PP [PP-ND] for specific details. ## 6.1 Security Audit (FAU) 6.1.1 Security Audit Data generation (FAU_GEN) #### 6.1.1.1 FAU_GEN.1 Audit Data Generation FAU_GEN.1.1 The TSF shall be able to generate an audit data of the following auditable events: - a) Start-up and shut-down of the audit functions; - b) All auditable events for the not specified level of audit; and - c) All administrative actions comprising: - Administrative login and logout (name of Administrator account shall be logged if individual accounts are required for Administrators). - Changes to TSF data related to configuration changes (in addition to the information that a change occurred it shall be logged what has been changed). - Generating/import of, changing, or deleting of cryptographic keys (in addition to the action itself a unique key name or key reference shall be logged). - [selection: Resetting passwords (name of related user account shall be logged)]. FAU_GEN.1.2 ##### d) Specifically defined auditable events listed in Table 6 . The TSF shall record within each audit data at least the following information: - a) Date and time of the event, type of event, subject identity (if applicable), and the outcome (success or failure) of the event; and - b) For each auditable event type, based on the auditable event definitions of the functional components included in the ST , information specified in column three of Table 6 . | Requirement | Auditable Events | Additional Audit Record Contents | |--------------------------|--------------------------------------------------------------|----------------------------------------------------------------| | FAU_GEN.1 | None. | None. | | FAU_GEN.2 | None. | None. | | FAU_GEN.1/WLAN | None | None | | FAU_GEN_EXT.1 | None | None | | FAU_STG_EXT.4 | None | None | | FAU_STG_EXT.5 | None | None | | FAU_STG.2 | None. | None. | | FAU_STG_EXT.1 | Configuration of local audit settings. | Identity of account making changes to the audit configuration. | | FCS_CKM.1 | None. | None. | | FCS_CKM.2 | None. | None. | | FCS_CKM.3 | Success and failure of the activity | None | | FCS_CKM.6 | None. | None. | | FCS_COP.1/DataEncryption | None | None | | FCS_COP.1/SigGen | None. | None. | | FCS_COP.1/Hash | None. | None. | | FCS_COP.1/KeyedHash | None. | None. | | FCS_RBG.1 | Failure of the randomization process, failure to initialize. | None. | | FCS_RBG.3 | None. | None. | | FIA_AFL.1 | Unsuccessful login attempts limit is met or exceeded. | Origin of the attempt (e.g., IP address). | | FIA_PMG_EXT.1 | None. | None. | | FIA_UIA_EXT.1 | All use of identification and authentication mechanism. | Origin of the attempt (e.g., IP address). | | FIA_UAU.7 | None. | None. | | FMT_MOF.1/ManualUpdate | Any attempt to initiate a manual update | None. | | FMT_MTD.1/CoreData | None. | None. | | FMT_SMF.1 | All management activities of TSF data. | None. | | FMT_SMR.2 | None. | None. | |--------------------------------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|--------------------------------------------------------------------------------------------------------------| | FMT_MTD.1/CryptoKeys | None. | None. | | FPT_SKP_EXT.1 | None. | None. | | FPT_APW_EXT.1 | None. | None. | | FPT_TST_EXT.1 | Execution of this set of TSF-self tests. Detected integrity violations. | • None. • The TSF code file that caused the integrity violation. | | FPT_TUD_EXT.1 | Initiation of update; result of the update attempt (success or failure) | None. | | FPT_STM.1 | Changes to the time | Providing a timestamp | | FPT_STM.2 | Discontinuous changes to the time | Changes to the time source | | FTA_SSL_EXT.1 (if 'terminate the session' is selected) | The termination of a local session by the session locking mechanism. | None. | | FTA_SSL.3 | The termination of a remote session by the session locking mechanism. | None. | | FTA_SSL.4 | The termination of an interactive session. | None. | | FTA_TAB.1 | None. | None. | | FTP_ITC.1 | • Initiation of the trusted channel. • Termination of the trusted channel. • Failure of the trusted channel functions. • Failed attempts to establish a trusted channel (including IEEE 802.11) • Detection of modification of channel data | • None • None • Reason for failure • Identification of the initiator and target of channel. • None | | FTP_ITC.1/Client | None. | None. | | FTP_ITT.1 | • Initiation of the trusted channel. • Termination of the trusted channel. • Failure of the trusted channel functions. | Identification of the initiator, target channel and target of failed trusted channels establishment attempt. | | FTP_TRP.1/Admin | • Initiation of the trusted path. • Termination of the trusted path. • Failure of the trusted path functions. | • None • None • Reason for failure | | FMT_MOF.1/Functions | None. | None. | | FCO_CPC_EXT.1 | • Enabling communications between a pair of components. • Disabling communications between a pair of components. | Identities of the endpoint pairs enabled or disabled. | | FCS_IPSEC_EXT.1 | • Failure to establish an IPsec SA • Protocol failures. • Establishment/Termination of an IPsec SA. | • Reason for failure • Reason for failure Non-TOE endpoint of connection. • Non-TOE endpoint of connection. | | FCS_NTP_EXT.1 | • Configuration of a new time server • Removal of configured time server | Identity if new/removed time server | | FCS_SSH_EXT.1 | Failure to establish an SSH session | Reason for failure | | FCS_SSHS_EXT.1 | None | None | Table 6 Security Functional Requirements and Auditable Events | FCS_TLSC_EXT.1 | Failure to establish a TLS Session | Reason for failure | |------------------------|-------------------------------------------------------------------------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------| | FCS_TLSS_EXT.1 | Failure to establish a TLS Session | Reason for failure | | FCS_DTLSC_EXT.1 | Failure to establish a DTLS session | Reason for failure | | FCS_DTLSS_EXT.1 | Failure to establish a DTLS session | Reason for failure | | | Detected replay attacks | Identity (e.g., source IP address) of the source of the replay attack | | FIA_X509_EXT.1/Rev | • Unsuccessful attempt to validate a certificate • Any addition, replacement or removal of trust anchors in the TOE's trust store • | • Reason for failure of certificate validation Identification of certificates added, replaced or removed as trust anchor in the TOE's trust store | | FIA_X509_EXT.1/ ITT | • Unsuccessful attempt to validate a certificate • Any addition, replacement or removal of trust anchors in the TOE's trust store | • Reason for failure of certificate validation • Identification of certificates added, replaced or removed as trust anchor in the TOE's trust store | | FIA_X509_EXT.2 | None | None | | FIA_X509_EXT.3 | None | None | | FCS_CKM.1/WPA | None. | None. | | FCS_CKM.2/GTK | None. | None. | | FCS_CKM.2/PMK | None. | None. | | FIA_8021X_EXT.1 | Attempts to access the 802.1X controlled port prior to successful completion of the authentication exchange. | Provided client identity (e.g., Media Access Control [Media Access Control (MAC)] address). | | FIA_8021X_EXT.1 | Failed authentication attempt. | Provided client identity (e.g., MAC address). | | FIA_UAU.6 | Attempts to re-authenticate. | Origin of the attempt (e.g., IP address). | | FMT_SMF.1/AccessSystem | None | None | | FMT_SMR_EXT.1 | None | None | | FPT_FLS.1 | Failure of the TSF. | Indication that the TSF has failed with the type of failure that occurred. | | FTA_TSE.1 | Failure of the TSF. | Indication that the TSF has failed with the type of failure that occurred. | #### 6.1.1.2 FAU_GEN.2 User identity association FAU_GEN.2.1 For audit events resulting from actions of identified users, the TSF shall be able to associate each auditable event with the identity of the user that caused the event. 6.1.2 Security audit event storage (FAU_STG) - 6.1.2.1 FAU_STG.2 Protected audit data storage FAU_STG.2.1 The TSF shall protect the stored audit records in the audit trail from unauthorised deletion. FAU_STG.2.2 The TSF shall be able to [selection: prevent ] unauthorised modifications to the stored audit records in the audit trail. #### 6.1.2.2 FAU_STG_EXT.1 Protected Audit Event Storage FAU_STG_EXT.1.1 The TSF shall be able to transmit the generated audit data to an external IT entity using a trusted channel according to FTP_ITC.1. - FAU_STG_EXT.1.2 The TSF shall be able to store generated audit data on the TOE itself. In addition [ selection: · - The TOE shall be a distributed TOE that stores audit data on the following TOE components : [assignment: Access Controller]. FAU_STG_EXT.1.3 The TSF shall maintain a [selection: log file, buffer,] of audit records in the event that an interruption of communication with the remote audit server occurs. FAU_STG_EXT.1.4 The TSF shall be able to store [selection: persistent] audit records locally with a minimum storage size of [assignment: 1 Megabyte (MB) ]. FAU_STG_EXT.1.5 The TSF shall [selection: overwrite previous audit records according to the following rule: [assignment : oldest audit record is overwritten], [assignment: no other action] ] when the local storage space for audit data is full. FAU_STG_EXT.1.6 The TSF shall provide the following mechanisms for administrative access to locally stored audit records [selection: manual export, ability to view locally]. - 6.2 Cryptographic Support (FCS) 6.2.1 Cryptographic Key Management (FCS_CKM) - 6.2.1.1 FCS_CKM.1 Cryptographic Key Generation (Refinement) FCS_CKM.1.1 The TSF shall generate asymmetric cryptographic keys in accordance with a specified cryptographic key generation algorithm: [selection: - RSA schemes using cryptographic key sizes of [assignment: 3072 bits or greater] that meet the following: FIPS PUB 186-4, ' Digital Signature Standard (DSS) ' , Appendix B.3; - ECC schemes using ' NIST curves ' [selection: P-256, P-384, P521] that meet the following: FIPS PUB 186-4, ' Digital Signature Standard (DSS) ' , Appendix B.4; - FFC Schemes using ' safe-prime ' groups that meet the following: ' NIST Special Publication 800-56A Revision 3, Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography ' and [selection 3526] ] and specified cryptographic key sizes [assignment: cryptographic key sizes] that meet the following: [assignment: list of standards]. #### 6.2.1.2 FCS_CKM.2 Cryptographic Key Establishment (Refinement) FCS_CKM.2.1 The TSF shall perform cryptographic key establishment in accordance with a specified cryptographic key establishment method: [selection: - Elliptic curve-based key establishment schemes that meet the following: NIST Special Publication 800-56A Revision 3, ' Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography ' ; - FFC Schemes using ' safe-prime ' groups that meet the following: ' NIST Special Publication 800-56A Revision 3, ' Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography ' and [selection: RFC 3526]. ] that meets the following: [assignment: list of standards]. #### 6.2.1.3 FCS_CKM.3 Cryptographic key access FCS_CKM.3.1 The TSF shall perform [assignment: Recover certificate and private key when changing devices ] in accordance with a specified cryptographic key access method [assignment: Export the certificate and private key to a PKCS12 file ] that meets the following: [assignment: PKCS#12 ]. #### 6.2.1.4 FCS_CKM.6 Timing and event of cryptographic key destruction FCS_CKM.6.1 FCS_CKM.6.2 The TSF shall destroy [assignment: private key, keys and keying material of IPsec, keys and keying material of TLS and DTLS, keys and keying material of SSH ] when [selection: no longer needed, [assignment: administrator manually destroys] ]. The TSF shall destroy cryptographic keys and keying material specified by FCS_CKM.6.1 in accordance with a specified cryptographic key destruction method [assignment: single overwrite consisting of zeros ] that meets the following: [assignment: NIST. 800-57 Part 1 Revision 5]. 6.2.2 Cryptographic Operation (FCS_COP.1) 6.2.2.1 FCS_COP.1/SigGen Cryptographic Operation (Signature Generation and Verification) FCS_COP.1.1/SigGen The TSF shall perform cryptographic signature services (generation and verification) in accordance with a specified cryptographic algorithm [selection: - RSA Digital Signature Algorithm - Elliptic Curve Digital Signature Algorithm ] and cryptographic key sizes [ - For RSA: modulus 3072 bits or greater, - For ECDSA: 256 bits or greater ] that meet the following: [selection : - For RSA schemes: FIPS PUB 186-4, ' Digital Signature Standard (DSS) ' , Section 5.5, using PKCS #1 v2.1 Signature Schemes RSASSA-PSS and/or RSASSA-PKCS1v1_5; ISO/IEC 9796-2, Digital signature scheme 2 or Digital Signature scheme 3, - For ECDSA schemes: FIPS PUB 186-4, ' Digital Signature Standard (DSS) ' , Section 6 and Appendix D, Implementing ' NIST curves ' [selection: P-256, P-384, P-521]; ISO/IEC 148883, Section 6.4 ]. #### 6.2.2.2 FCS_COP.1/Hash Cryptographic Operation (Hash Algorithm) FCS_COP.1.1/Hash The TSF shall perform cryptographic hashing services in accordance with a specified cryptographic algorithm [selection: SHA-256, SHA384, SHA-512] and cryptographic key sizes [assignment: cryptographic key sizes] and message digest sizes [selection: 256, 384, 512] bits that meet the following: ISO/IEC 10118-3:2004 . - 6.2.2.3 FCS_COP.1/KeyedHash Cryptographic Operation (Keyed Hash Algorithm) FCS_COP.1.1/KeyedHash The TSF shall perform keyed-hash message authentication in accordance with a specified cryptographic algorithm [selection: HMAC-SHA-256, HMAC-SHA-384, HMAC-SHA-512, implicit] and cryptographic key sizes [ assignment:256, 384, 512 ] and message digest sizes [selection: 256, 384, 512] bits that meet the following: ISO/IEC 9797-2:2011, Section 7 ' MAC Algorithm 2 ' . - 6.2.3 Random Bit Generation (FCS_RBG) - 6.2.3.1 FCS_RBG.1 Random Bit Generation 3. FCS_RBG.1.1 The TSF shall perform deterministic random bit generation services using [assignment: CTR_DRBG (AES )] in accordance with [assignment: ISO/IEC 18031:2011 ] after initialization with a seed. 4. FCS_RBG.1.2 The TSF shall use a [selection: TSF noise source [assignment: software- based noise source ]] for initialized seeding. FCS_RBG.1.3 The TSF shall update the RBG state by [selection: uninstantiating and reinstantiating] using a [selection: TSF noise source [assignment: software-based noise source ]] in the following situations: [selection: on the condition: [assignment: new key generation ]] in accordance with [assignment: ISO/IEC 18031:2011 ]. #### 6.2.3.2 FCS_RBG.3 Random bit generation (internal seeding - single source) FCS_RBG.3.1 The TSF shall be able to seed the RBG using a [selection: TSF softwarebased noise source] [assignment: software-based noise source ] with a minimum of [assignment: 256 ] bits of min-entropy. ## 6.3 Identification and Authentication (FIA) 6.3.1 Authentication Failure Management (FIA_AFL) - 6.3.1.1 FIA_AFL.1 Authentication Failure Management (Refinement) - 6.3.2 Password Management (Extended - FIA_PMG_EXT) - 6.3.2.1 FIA_PMG_EXT.1 Password Management | FIA_AFL.1.1 | The TSF shall detect when an Administrator configurable positive integer within [assignment: 2-10 ] unsuccessful authentication attempts occur related to Administrators attempting to authenticate remotely using a password . | |---------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | FIA_AFL.1.2 | When the defined number of unsuccessful authentication attempts has been met, the TSF shall [selection: prevent the offending Administrator from successfully establishing a remote session using any authentication method that involves a password until [assignment: unlock ] is taken by an Administrator]. | The TSF shall provide the following password management capabilities FIA_PMG_EXT.1.1 for administrative passwords: - a) Passwords shall be able to be composed of any combination of upper and lower case letters, numbers, and the following special characters: [selection: ' ! ' , ' @ ' , ' # ' , ' $ ' , ' % ' , ' ^ ' , ' & ' , ' * ' , ' ( ' , ' ) ' , [assignment: ' ' ' , ' + ' , ' , ' , ' - ' , ' . ' , ' / ' , ' : ' , ' ; ' , ' < ' , ' = ' , ' > ' , ' [ ' , ' \ ' , ' ] ' , ' _ ' , ' ` ' , ' { ' , ' } ' , and ' ~ ' ]]; - b) Minimum password length shall be configurable to between [ assignment: 15 ] and [assignment: 32 ] characters. 6.3.3 User Identification and Authentication (Extended - FIA_UIA_EXT) - 6.3.3.1 FIA_UIA_EXT.1 User Identification and Authentication FIA_UIA_EXT.1.1 The TSF shall allow the following actions prior to requiring the non-TOE entity to initiate the identification and authentication process: - Display the warning banner in accordance with FTA_TAB.1; - [selection: [assignment: ICMP echo] ]. - FIA_UIA_EXT.1.2 The TSF shall require each administrative user to be successfully identified and authenticated before allowing any other TSF-mediated actions on behalf of that administrative user. - FIA_UIA_EXT.1.3 The TSF shall provide the following remote authentication mechanisms [selection: SSH password, SSH public key] and local authentication mechanisms [selection: password-based]. - FIA_UIA_EXT.1.4 The TSF shall authenticate any administrative user ' s claimed identity according to each authentication mechanism specified in FIA_UIA_EXT.1.3. 6.3.4 User authentication (FIA_UAU) (Extended - FIA_UAU_EX - 6.3.4.1 FIA_UAU.7 Protected Authentication Feedback FIA_UAU.7.1 The TSF shall provide only obscured feedback to the administrative user while the authentication is in progress at the local console . ## 6.4 Security Management (FMT) 6.4.1 Specification of Management Functions (FMT_SMF) - 6.4.1.1 FMT_SMF.1 Specification of Management Functions 2. FMT_SMF.1.1 The TSF shall be capable of performing the following management functions: - Ability to administer the TOE remotely; - Ability to configure the access banner; - Ability to configure the remote session inactivity time before session termination; - Ability to update the TOE, and to verify the updates using digital signature capability prior to installing those updates; - [selection: - o Ability to configure audit behaviour (e.g., changes to storage locations for audit; changes to behaviour when local audit storage space is full); - o Ability to modify the behaviour of the transmission of audit data to an external IT entity; - o Ability to configure local audit behaviour (e.g., changes to storage locations for audit; changes to behaviour when local audit storage space is full, changes to local audit storage size); - o Ability to configure the list of TOE-provided services available before an entity is identified and authenticated, as specified in FIA_UIA_EXT.1; - o Ability to manage the cryptographic keys; - o Ability to configure the cryptographic functionality; - o Ability to configure thresholds for SSH rekeying; - o Ability to configure the lifetime for IPsec SAs; - o Ability to configure the list of supported (D)TLS ciphers; - o Ability to configure the interaction between TOE components; - o Ability to re-enable an Administrator account; - o Ability to set the time which is used for time-stamps; - o Ability to configure NTP; - o Ability to configure the reference identifier for the peer; - o Ability to manage the TOE's trust store and designate X509.v3 certificates as trust anchors; - o Ability to administer the TOE locally. - o Ability to configure the local session inactivity time before session termination or locking - o Ability to configure the authentication failure parameters for FIA_AFL.1; - o Ability to manage the trusted public keys database; - o No other capabilities. ]. 6.4.2 Security management roles (FMT_SMR) - 6.4.2.1 FMT_SMR.2 Restrictions on security roles FMT_SMR.2.1 The TSF shall maintain the roles: - Security Administrator. FMT_SMR.2.2 The TSF shall be able to associate users with roles. FMT_SMR.2.3 The TSF shall ensure that the conditions - The Security Administrator role shall be able to administer the TOE remotely are satisfied. - 6.5 Protection of the TSF (FPT) 6.5.1 Protection of TSF Data (Extended - FPT_SKP_EXT) - 6.5.1.1 FPT_SKP_EXT.1 Protection of TSF Data (for reading of all pre-shared, symmetric and private keys) 2. FPT_SKP_EXT.1.1 The TSF shall prevent reading of all pre-shared keys, symmetric keys, and private keys. - 6.5.2 Protection of Administrator Passwords (Extended - FPT_APW_EXT) - 6.5.2.1 FPT_APW_EXT.1 Protection of Administrator Passwords - 6.5.3 Trusted Update (FPT_TUD_EXT) - 6.5.3.1 FPT_TUD_EXT.1 Trusted Update - FPT_APW_EXT.1.1 The TSF shall store administrative passwords in non-plaintext form. - FPT_APW_EXT.1.2 The TSF shall prevent the reading of plaintext passwords. administrative | FPT_TUD_EXT.1.1 | The TSF shall provide Security Administrators the ability to query the currently executing version of the TOE firmware/software and [selection: the most recently installed version of the TOE firmware/software ]. | |-------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | FPT_TUD_EXT.1.2 | The TSF shall provide Security Administrators the ability to manually initiate updates to TOE firmware/software and [selection: no other update mechanism]. | | FPT_TUD_EXT.1.3 | The TSF shall provide means to authenticate firmware/software updates to the TOE using a [selection: digital signature] prior to installing those updates. | 6.5.4 Time stamps (Extended - FPT_STM)) - 6.5.4.1 FPT_STM.1 Reliable Time Stamps FPT_STM.1.1 The TSF shall be able to provide reliable time stamps. - 6.5.4.2 FPT_STM.2 Time source FPT_STM.2.1 The TSF shall allow the [assignment : Security Administrator ] - 6.6 TOE Access (FTA) 6.6.1 TSF-initiated Session Locking (Extended - FTA_SSL_EXT) - 6.6.1.1 FTA_SSL_EXT.1 TSF-initiated Session Locking FTA_SSL_EXT.1.1 The TSF shall, for local interactive sessions, [selection: terminate the session] after a Security Administrator-specified time period of inactivity. 6.6.2 Session Locking and Termination (FTA_SSL) - 6.6.2.1 FTA_SSL.3 TSF-initiated Termination (Refinement) FTA_SSL.3.1 The TSF shall terminate a remote interactive session after a Security Administrator-configurable time interval of session inactivity . - 6.6.2.2 FTA_SSL.4 User-initiated Termination (Refinement) 2. FTA_SSL.4.1 The TSF shall allow user Administratorinitiated termination of the user ' s Administrator ' s own interactive session. 6.6.3 TOE Access Banners (FTA_TAB) - 6.6.3.1 FTA_TAB.1 Default TOE Access Banners (Refinement) FTA_TAB.1.1 Before establishing an administrative user session, the TSF shall display a Security Administrator-specified advisory notice and consent warning message regarding unauthorised use of the TOE. - 6.7 Trusted Path/Channels (FTP) 6.7.1 Trusted Channel (FTP_ITC) - 6.7.1.1 FTP_ITC.1 Inter-TSF Trusted Channel (Refinement) [EPWLAN]FTP_ITC.1.1 The TSF shall be capable of using IEEE 802.1X, [selection:IPsec], and [selection: no other protocol] to provide a trusted communication channel between itself and another trusted IT product authorized IT entities supporting the following capabilities: 802.1X authentication server, audit server , [selection ： authentication server [assignment: NTP server ]] that is logically distinct from other communication to [assignment: to set the time and synchronise time with an NTP server ]. 6.7.2 channels and provides assured identification of its end points and protection of the channel data from modification or disclosure and detection of modification of the channel data. [EPWLAN]FTP_ITC.1.2 The TSF shall permit the TSF or the authorized IT entities to initiate communication via the trusted channel. FTP_ITC.1.3 The TSF shall initiate communication via the trusted channel for [ assignment: audit service, authentication service, 802.1x authentication service and NTP service ]. Trusted Path (FTP_TRP) #### 6.7.2.1 FTP_TRP.1/Admin Trusted Path (Refinement) FTP_TRP.1.1/Admin The TSF shall be capable of using [selection: SSH] to provide a communication path between itself and authorized remote Administrators users that is logically distinct from other communication paths and provides assured identification of its end points and protection of the communicated data from disclosure and provides detection of modification of the channel data . FTP_TRP.1.2/Admin The TSF shall permit remote Administrators users to initiate communication via the trusted path. initial FTP_TRP.1.3/Admin The TSF shall require the use of the trusted path for Administrator authentication and all remote administration actions . ## 6.8 Selection-Based Requirements 6.8.1 Cryptographic Support (FCS) #### 6.8.1.1 FCS_IPSEC_EXT.1 IPsec Protocol - FCS_IPSEC_EXT.1.1 The TSF shall implement the IPsec architecture as specified in RFC 4301. FCS_IPSEC_EXT.1.2 The TSF shall have a nominal, final entry in the SPD that matches anything that is otherwise unmatched and discards it. - FCS_IPSEC_EXT.1.3 The TSF shall implement [selection: tunnel mode, transport mode]. - FCS_IPSEC_EXT.1.4 The TSF shall implement the IPsec protocol ESP as defined by RFC 4303 using the cryptographic algorithms [selection: AES-GCM-128 (RFC 4106), AES-GCM-192 (RFC 4106), AES-GCM-256 (RFC 4106)] together with a Secure Hash Algorithm (SHA)-based HMAC [selection: no HMAC algorithm]. FCS_IPSEC_EXT.1.5 The TSF shall implement the protocol: [selection: · IKEv2 as defined in RFC 7296 and [selection: with mandatory support for NAT traversal as specified in RFC 7296, section 2.23)], and [selection: RFC 4868 for hash functions] ]. FCS_IPSEC_EXT.1.6 The TSF shall ensure the encrypted payload in the [selection: IKEv2] protocol uses the cryptographic algorithms [selection: AES-GCM-128, AES-GCM-192, AES-GCM-256 (specified in RFC 5282)] FCS_IPSEC_EXT.1.7 The TSF shall ensure that [selection: o IKEv2 SA lifetimes can be configured by a Security Administrator based on [selection: length of time, where the time values can be configured within [assignment: 124 ] hours ]. FCS_IPSEC_EXT.1.8 The TSF shall ensure that [selection: · IKEv2 Child SA lifetimes can be configured by a Security Administrator based on [selection: o number of bytes; o length of time, where the time values can be configured within [assignment: 1-8 ] hours; ] FCS_IPSEC_EXT.1.9 The TSF shall generate the secret value x used in the IKE Diffie-Hellman key exchange ( ' x ' in g^x mod p) using the random bit generator specified in FCS_RBG.1 , and having a length of at least [assignment: 256 (for DH Group 19), 256 (for DH Group 24), 384 (for DH Group 20) ] bits. FCS_IPSEC_EXT.1.10 The TSF shall generate nonces used in [selection: IKEv2] exchanges of length [selection: at least 128 bits in size and at least half the output size of the negotiated pseudorandom function (PRF) hash]. FCS_IPSEC_EXT.1.11 The TSF shall ensure that IKE protocols implement DH Group(s) [selection: · [selection: 19 (256-bit Random ECP), 20 (384-bit Random ECP), 24 (2048-bit MODP with 256-bit POS)] according to RFC 5114. ]. The TSF shall be able to ensure that the strength of the symmetric algorithm (in terms of the number of bits in the key) negotiated to protect the [selection: IKEv2 IKE_SA] connection is greater than or FCS_IPSEC_EXT.1.12 equal to the strength of the symmetric algorithm (in terms of the number of bits in the key) negotiated to protect the [selection: IKEv2 CHILD_SA] connection. FCS_IPSEC_EXT.1.13 The TSF shall ensure that all IKE protocols perform peer authentication using [selection: RSA, ECDSA] that use X.509v3 certificates that conform to RFC 4945 and [selection: Pre-shared Keys]. FCS_IPSEC_EXT.1.14 The TSF shall only establish a trusted channel if the presented identifier in the received certificate matches the configured reference identifier, where the presented and reference identifiers are of the following fields and types: [selection: SAN: IP address, SAN: Fully Qualified Domain Name (FQDN), CN: IP address, CN: Fully Qualified Domain Name (FQDN), Distinguished Name (DN)] and [selection: no other reference identifier type]. #### 6.8.1.2 FCS_NTP_EXT.1 NTP Protocol FCS_NTP_EXT.1.1 The TSF shall use only the following NTP version(s) [selection: NTP v3 (RFC 1305), NTP v4 (RFC 5905 ) ]. FCS_NTP_EXT.1.2 The TSF shall update its system time using [selection: - Authentication using [selection: SHA256, SHA384, SHA512] as the message digest algorithm(s); - [selection: IPsec] to provide trusted communication between itself and an NTP time source. ]. FCS_NTP_EXT.1.3 The TSF shall not update NTP timestamp from broadcast and/or multicast addresses. FCS_NTP_EXT.1.4 The TSF shall support configuration of at least three (3) NTP time sources in the Operational Environment. #### 6.8.1.3 FCS_SSH_EXT.1 SSH Protocol FCS_SSH_EXT.1.1 The TOE shall implement SSH acting as a [selection: server] in accordance with that complies with RFCs 4251, 4252, 4253, 4254, [selection: 4256, 4344, 5647, 5656, 6187, 6668] and [no other standard]. FCS_SSH_EXT.1.2 The TSF shall ensure that the SSH protocol implementation supports the following authentication methods: [selection: - ' password ' , complying with (RFC 4252), - publickey (RFC 4252): [selection o ecdsa-sha2-nistp256 (RFC 5656), o ecdsa-sha2-nistp384 (RFC 5656), ] and no other methods. FCS_SSH_EXT.1.3 The TSF shall ensure that, as described in RFC 4253, packets greater than [assignment: 256k ] bytes in an SSH transport connection are dropped. FCS_SSH_EXT.1.4 The TSF shall protect data in transit from unauthorised disclosure using the following mechanisms: [selection: - AEAD_AES_128_GCM (RFC 5647), - AEAD_AES_256_GCM (RFC 5647), - [aes128-gcm@openssh.com (RFC 5647),](mailto:aes128-gcm@openssh.com) - [aes256-gcm@openssh.com (RFC 5647)](mailto:aes256-gcm@openssh.com) ] and no other mechanisms. FCS_SSH_EXT.1.5 The TSF shall protect data in transit from modification, deletion, and insertion using: [selection: - AEAD_AES_128_GCM (RFC 5647), - AEAD_AES_256_GCM (RFC 5647), - Implicit ] and no other mechanisms. FCS_SSH_EXT.1.6 The TSF shall establish a shared secret with its peer using: [selection: - ecdsa-sha2-nistp256 (RFC 5656), - ecdsa-sha2-nistp384 (RFC 5656) ] and no other mechanism. FCS_SSH_EXT.1.7 The TSF shall use SSH KDF as defined in [selection: - RFC 5656 (Section 4) ] to derive the following cryptographic keys from a shared secret: session keys. FCS_SSH_EXT.1.8 The TSF shall ensure that [selection: · A rekey of the session keys, ] occurs when any of the following thresholds are met: - One hour connection time - No more than one gigabyte of transmitted data, or - No more than one gigabyte of received data. - 6.8.1.4 FCS_SSHS_EXT.1 SSH Protocol - Server FCS_SSHS_EXT.1.1 The TSF shall authenticate itself to its peer (SSH Client) using: [ selection: - ecdsa-sha2-nistp256 (RFC 5656), ]. FCS_DTLSC_EXT.1.2 The TSF shall verify that the presented identifier matches [selection: the identifier per RFC 5280 Appendix A using [selection: id-at-title] and no other attribute types]. FCS_DTLSC_EXT.1.3 The TSF shall not establish a trusted channel if the server certificate is invalid. [selection: without any administrator override mechanism]. FCS_DTLSC_EXT.1.4 The TSF shall [selection: present the Supported Groups Extension with the following curves/groups: [selection: secp256r1, secp384r1, secp521r1] and no other curves/groups] in the Client Hello. FCS_DTLSC_EXT.1.5 The TSF shall [selection: present the signature_algorithms extension with support for the following algorithms: [selection: - rsa_pkcs1 with sha256 (0x0401) - rsa_pkcs1 with sha384 (0x0501) - rsa_pkcs1 with sha512 (0x0601) - ecdsa_secp256r1 with sha256 (0x0403) - ecdsa_secp384r1 with sha384 (0x0503) - ecdsa_secp521r1 with sha512 (0x0603) - rsa_pss_rsae with sha256 (0x0804) - rsa_pss_rsae with sha384 (0x0805) - rsa_pss_rsae with sha512 (0x0806) - rsa_pss_pss with sha256 (0x0809) - rsa_pss_pss with sha384 (0x080a) - rsa_pss_pss with sha512 (0x080b)] and no other signature Schemes. ]. #### 6.8.1.5 FCS_DTLSC_EXT.1 DTLS Client Protocol Without Mutual Authentication FCS_DTLSC_EXT.1.1 The TSF shall implement [selection: DTLS 1.2 (RFC 6347)] supporting the following ciphersuites: [selection: - TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 as defined in RFC 5289 - TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5289 - TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 as defined in RFC 5289 - TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5289 - ecdsa-sha2-nistp384 (RFC 5656), FCS_DTLSC_EXT.1.6 ] The TSF [selection: does not provide] the ability to configure the list of supported ciphersuites as defined in FCS_DTLSC_EXT.1.1. FCS_DTLSC_EXT.1.7 The TSF shall prohibit the use of the following extensions: - Early data extension - Post-handshake client authentication according to RFC 9147, Section 5.8.4. FCS_DTLSC_EXT.1.8 The TSF shall [selection: not use PSKs]. FCS_DTLSC_EXT.1.9 The TSF shall [selection: reject [selection: DTLS 1.2, DTLS 1.3] renegotiation attempt ]. FCS_DTLSC_EXT.1.10 The TSF shall [selection: terminate the DTLS session] if a message received contains an invalid MAC. FCS_DTLSC_EXT.1.11 The TSF shall detect and silently discard replayed messages for: - DTLS records previously received; - DTLS records too old to fit in the sliding window. - 6.8.1.6 FCS_DTLSS_EXT.1 DTLS Server Protocol Without Mutual Authentication FCS_DTLSS_EXT.1.1 The TSF shall implement [selection: DTLS 1.2 (RFC 6347)] and reject all other DTLS versions. The DTLS implementation will support the following ciphersuites: [selection: - TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 as defined in RFC 5289 - TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5289 - TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 as defined in RFC 5289 - TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5289 ] and no other ciphersuites. The TSF shall not proceed with a connection handshake attempt if the DTLS server cannot successfully validate the cookie returned by the - FCS_DTLSS_EXT.1.2 DTLS Client. FCS_DTLSS_EXT.1.3 The TSF shall authenticate itself using X.509 certificate(s) using [selection: RSA with key size [selection: 3072, 4096] bits; ECDSA over NIST curves [selection: secp256r1, secp384r1, secp521r1] and no other curves]. FCS_DTLSS_EXT.1.4 The TSF shall perform key exchange using [selection: - EC Diffie-Hellman key agreement over NIST curves [selection: secp256r1, secp384r1, secp521r1] and no other curves]. ]. FCS_DTLSS_EXT.1.5 The TSF shall [selection: silently discard the record] if a message received contains an invalid MAC. FCS_DTLSS_EXT.1.6 The TSF shall detect and silently discard replayed messages for: - DTLS records previously received. - DTLS records too old to fit in the sliding window. FCS_DTLSS_EXT.1.7 The TSF shall support [selection: no session resumption or session tickets]. FCS_DTLSS_EXT.1.8 The TSF [selection: provides] the ability to configure the list of supported ciphersuites as defined in FCS_DTLSS_EXT.1.1. FCS_DTLSS_EXT.1.9 The TSF shall prohibit the use of the following extensions: - Early data extension FCS_DTLSS_EXT.1.10 The TSF shall [selection: not use PSKs ]. FCS_DTLSS_EXT.1.11 The TSF shall [selection: reject [selection: DTLS 1.2, DTLS 1.3] renegotiation attempts]. #### 6.8.1.7 FCS_TLSC_EXT.1 TLS Client Protocol Without Mutual Authentication FCS_TLSC_EXT.1.1 The TSF shall implement [selection: TLS 1.2 (RFC 5246)] supporting the following ciphersuites: [selection: - TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 as defined in RFC 5289 - TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5289 - TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 as defined in RFC 5289 - TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5289 ] and no other ciphersuites. FCS_TLSC_EXT.1.2 The TSF shall verify that the presented identifier matches [selection: the identifier per RFC 5280 Appendix A using [selection: id-at-title] and no other attribute types]. FCS_TLSC_EXT.1.3 The TSF shall not establish a trusted channel if the server certificate is invalid [selection: without any administrator override mechanism]. FCS_TLSC_EXT.1.4 The TSF shall [selection: present the Supported Groups Extension with the following curves/groups: [selection: secp256r1, secp384r1, secp521r1] and no other curves/groups] in the Client Hello. FCS_TLSC_EXT.1.5 The TSF shall [selection: - Present the signature_algorithms extension with support for the following algorithm s: [selection: - o rsa_pkcs1 with sha256(0x0401), - o rsa_pkcs1with sha384(0x0501), - o rsa_pkcs1 with sha512(0x0601), - o ecdsa_secp256r1 with sha256(0x0403), - o ecdsa_secp384r1 with sha384(0x0503), - o ecdsa_secp521r1 with sha512(0x0603), - o rsa_pss_rsae with sha256(0x0804), - o rsa_pss_rsae with sha384(0x0805), - o rsa_pss_rsae with sha512(0x0806), - o rsa_pss_pss with sha256(0x0809), - o rsa_pss_pss with sha384(0x080a), - o rsa_pss_pss with sha512(0x080b) - o ] and no other algorithms; ]. FCS_TLSC_EXT.1.6 The TSF [selection: does not provide] the ability to configure the list of supported ciphersuites as defined in FCS_TLSC_EXT.1.1. FCS_TLSC_EXT.1.7 The TSF shall prohibit the use of the following extensions: - Early data extension - Post-handshake client authentication according to RFC 8446, Section 4.2.6. FCS_TLSC_EXT.1.8 The TSF shall [selection: not use PSKs]. FCS_TLSC_EXT.1.9 The TSF shall [selection: reject [selection: TLS 1.2, TLS 1.3] renegotiation attempts]. #### 6.8.1.8 FCS_TLSS_EXT.1 TLS Server Protocol Without Mutual Authentication FCS_TLSS_EXT.1.1 The TSF shall implement [selection: TLS 1.2 (RFC 5246)] and reject all other TLS and SSL versions. The TLS implementation will support the following ciphersuites: [selection: ] FCS_TLSS_EXT.1.4 The TSF shall support [selection: no session resumption]. FCS_TLSS_EXT.1.5 The TSF [selection: provides ] the ability to configure the list of supported ciphersuites as defined in FCS_TLSS_EXT.1.1. FCS_TLSS_EXT.1.6 The TSF shall prohibit the use of the following extensions: - Early data extension. FCS_TLSS_EXT.1.7 The TSF shall [selection: not use PSKs]. FCS_TLSS_EXT.1.8 The TSF shall [selection: reject [selection: TLS 1.2, TLS 1.3] - renegotiation attempts]. 6.8.2 Identification and Authentication (FIA) #### 6.8.2.1 FIA_X509_EXT.1/Rev X.509 Certificate Validation FIA_X509_EXT.1.1/Rev The TSF shall validate certificates in accordance with the following rules: - RFC 5280 certificate validation and certification path validation supporting a minimum path length of three certificates . - The certification path must terminate with a trusted CA certificate designated as a trust anchor. - The TSF shall validate a certification path by ensuring that all CA certificates in the certification path contain the basicConstraints extension with the CA flag set to TRUE. - The TSF shall validate the revocation status of the certificate using [selection: a Certificate Revocation List - TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 as defined in RFC 5289 - TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5289 - TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 as defined in RFC 5289 - TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5289 ] and no other ciphersuites. FCS_TLSS_EXT.1.2 The TSF shall authenticate itself using X.509 certificate(s) using [selection: RSA with key size [selection: 3072, 4096] bits, ECDHE curves [selection: secp256r1, secp384r1, secp521r1] and no other curves]. FCS_TLSS_EXT.1.3 The TSF shall perform key exchange using: [selection: - EC Diffie-Hellman key agreement over NIST curves [selection: secp256r1, secp384r1, secp521r1] and no other curves; FIA_X509_EXT.1.2/Rev (CRL) as specified in RFC 5280 Section 6.3, Certificate Revocation List (CRL) as specified in RFC 5759 Section 5, no revocation method ]. - The TSF shall validate the extendedKeyUsage field according to the following rules: - o Certificates used for trusted updates and executable code integrity verification shall have the Code Signing purpose (id-kp 3 with OID 1.3.6.1.5.5.7.3.3) in the extendedKeyUsage field. - o Server certificates presented for DTLS/TLS shall have the Server Authentication purpose (id-kp 1 with OID 1.3.6.1.5.5.7.3.1) in the extendedKeyUsage field. - o Client certificates presented for DTLS/TLS shall have the Client Authentication purpose (id-kp 2 with OID 1.3.6.1.5.5.7.3.2) in the extendedKeyUsage field. - o OCSP certificates presented for OCSP responses shall have the OCSP Signing purpose (id-kp 9 with OID 1.3.6.1.5.5.7.3.9) in the extendedKeyUsage field. The TSF shall only treat a certificate as a CA certificate if the basicConstraints extension is present and the CA flag is set to TRUE. #### 6.8.2.2 FIA_X509_EXT.1/ITT X.509 Certificate Validation FIA_X509_EXT.1.1/ITT The TSF shall validate certificates in accordance with the following rules: - RFC 5280 certificate validation and certification path validation supporting a minimum path length of two certificates . - The certification path must terminate with a trusted CA certificate designated as a trust anchor. - The TSF shall validate a certification path by ensuring that all CA certificates in the certification path contain the basicConstraints extension with the CA flag set to TRUE. - The TSF shall validate the revocation status of the certificate using [selection: a Certificate Revocation List (CRL) as specified in RFC 5280 Section 6.3, Certificate Revocation List (CRL) as specified in RFC 5759 Section 5]. - The TSF shall validate the extendedKeyUsage field according to the following rules: - o Server certificates presented for DTLS/TLS shall have the Server Authentication purpose (id-kp 1 with OID 1.3.6.1.5.5.7.3.1) in the extendedKeyUsage field. FIA_X509_EXT.1.2/ITT - o Client certificates presented for DTLS/TLS shall have the Client Authentication purpose (id-kp 2 with OID 1.3.6.1.5.5.7.3.2) in the extendedKeyUsage field. - o OCSP certificates presented for OCSP responses shall have the OCSP Signing purpose (id-kp 9 with OID 1.3.6.1.5.5.7.3.9) in the extendedKeyUsage field. The TSF shall only treat a certificate as a CA certificate if the basicConstraints extension is present and the CA flag is set to TRUE. #### 6.8.2.3 FIA_X509_EXT.2 X.509 Certificate Authentication | FIA_X509_EXT.2.1 | The TSF shall use X.509v3 certificates as defined by RFC 5280 to support authentication for [selection: DTLS, IPsec, TLS] and [selection: no additional uses]. | |--------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------| | FIA_X509_EXT.2.2 | When the TSF cannot establish a connection to determine the validity of a certificate, the TSF shall [selection: not accept the certificate]. | - 6.8.2.4 FIA_X509_EXT.3 X.509 Certificate Requests - 6.8.3 Communication (FCO) - 6.8.3.1 FCO_CPC_EXT.1 Component Registration Channel Definition | FIA_X509_EXT.3.1 | The TSF shall generate a Certificate Request as specified by RFC 2986 and be able to provide the following information in the request: public key and [selection: Common Name, Organization, Organizational Unit, Country]. | |--------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | FIA_X509_EXT.3.2 | The TSF shall validate the chain of certificates from the Root CA upon receiving the CA Certificate Response. | | FCO_CPC_EXT.1.1 | The TSF shall require a Security Administrator to enable communications between any pair of TOE components before such communication can take place. | |-------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | FCO_CPC_EXT.1.2 | The TSF shall implement a registration process in which components establish and use a communications channel that uses [selection: A channel that meets the secure channel requirements in [selection: FPT_ITT.1] for at least TSF data . | | FCO_CPC_EXT.1.3 | The TSF shall enable a Security Administrator to disable communications between any pair of TOE components. | 6.8.4 Security Management (FMT) - 6.8.4.1 FMT_MOF.1/Functions Management of Security Functions Behaviour FMT_MOF.1.1/Functions The TSF shall restrict the ability to [selection: modify the behaviour of] the functions [selection: transmission of audit data to an external IT entity] to Security Administrators. - 6.8.4.2 FMT_MOF.1/ManualUpdate Management of Security Functions Behaviour - 6.8.4.3 FMT_MTD.1/CoreData Management of TSF Data FMT_MOF.1.1/ ManualUpdate The TSF shall restrict the ability to enable the functions to perform manual updates to Security Administrators . The TSF shall restrict the ability to manage the TSF data to Security FMT_MTD.1.1/ CoreData Administrators . - 6.8.4.4 FMT_MTD.1/CryptoKeys Management of TSF Data FMT_MTD.1.1/CryptoKeys The TSF shall restrict the ability to manage the cryptographic keys to Security Administrators. 6.8.5 Protection of the TSF (FPT) #### 6.8.5.1 FPT_ITT.1 Basic internal TSF data transfer protection (Refinement) FPT_ITT.1.1 The TSF shall protect TSF data from disclosure and detect its modification when it is transmitted between separate parts of the TOE through the use of [selection: TLS, DTLS] . ## 6.9 Edited Requirements from PP Module 6.9.1 Security Audit (FAU) #### 6.9.1.1 FAU_GEN_EXT.1 Security Audit Generation FAU_GEN_EXT.1.1 The TSF shall be able to generate audit records for each TOE component. The audit records generated by the TSF of each TOE component shall include the subset of security relevant audit events which can occur on the TOE component. #### 6.9.1.2 FAU_STG_EXT.4 Protected Local Audit Event Storage for Distributed TOEs FAU_STG_EXT.4.1 The TSF of each TOE component which stores security audit data locally shall perform the following actions when the local storage space for audit data is full: [assignment: access controller and for each component its action chosen according to the following : [selection: overwrite previous audit records according to the following rule: [assignment: oldest audit record is overwritten ],]]. #### 6.9.1.3 FAU_STG_EXT.5 Protected Remote Audit Event Storage for Distributed TOEs FAU_STG_EXT.5.1 Each TOE component which does not store security audit data locally shall be able to buffer security audit data locally until it has been transferred to another TOE component that stores or forwards it. All transfer of audit records between TOE components shall use a protected channel according to [selection: FPT_ITT.1]. 6.9.2 Cryptographic Support (FCS) #### 6.9.2.1 FCS_COP.1/DataEncryption Cryptographic Operation (AES Data Encryption/Decryption) [EPWLAN]FCS_COP.1.1/DataEncryption The TSF shall perform encryption/decryption in accordance with a specified cryptographic algorithm Advanced Encryption Standard 6.9.3 Protection of the TSF (FPT) - 6.9.3.1 FPT_TST_EXT.1 TSF Testing FPT_TST_EXT.1.1 (AES) used in Cipher Block Chaining (CBC), CCM mode Protocol (CCMP), and [ selection : Galois-Counter Mode (GCM), GCMP ] modes and cryptographic key sizes 256 bits(IPsec, TLS, DTLS and SSH) and [ selection : 128 bits (IPsec, TLS,DTLS, WIFI, and SSH) , 192 bits (IPsec and WIFI) ] that meet the following: AES as specified in ISO 18033-3, CBC as specified in ISO 10116, CCMP as specified in NIST SP 800-38C and IEEE 802.11-2020, [ selection : GCM as specified in ISO 19772, GCMP as specified in NIST SP 800-38D and IEEE 802.11ax-2021 ]. The TSF shall run a suite of the following self-tests during initial start-up (on power on) and [selection : at the request of the authorized user] to demonstrate the correct operation of the TSF: integrity verification of stored TSF executable code when it is loaded for execution through the use of the TSF-provided cryptographic service specified in FCS_COP.1/SigGen, [selection: [assignment: AES, SHA, HMAC, RSA, ECDSA and DRBG ] . [PP-ND] FPT_TST_EXT.1.2 T he TSF shall respond to [selection: [assignment: Cryptographic algorithm power-on self-test failure ]] by [selection: rebooting]. ## 6.10 New Requirements from PP Module 6.10.1 Cryptographic Support (FCS) - 6.10.1.1 FCS_CKM.1/WPA Cryptographic Key Generation (Symmetric Keys for WPA2 Connections) FCS_CKM.1.1/WPA The TSF shall generate symmetric cryptographic keys in accordance with a specified cryptographic key generation algorithm [PRF-384 and [ selection : PRF-704] and specified cryptographic key sizes [256 bits and [ selection : 128 bits]] using a Random Bit Generator as specified in FCS_RBG.1 that meet the following: [IEEE 802.11-2020 and [ selection : IEEE 802.11ax-2021]. - 6.10.1.2 FCS_CKM.2/GTK Cryptographic Key Distribution (GTK) FCS_CKM.2.1/GTK The TSF shall distribute GTK in accordance with a specified cryptographic key distribution method: [ selection : AES Key Wrap with Padding in an EAPOL-Key frame] that meets the following: [NIST SP 800-38F, IEEE 802.11-2020 for the packet format and timing considerations] and does not expose the cryptographic keys . - 6.10.1.3 FCS_CKM.2/PMK Cryptographic Key Distribution (PMK) FCS_CKM.2.1/PMK The TSF shall receive the 802.11 PMK in accordance with a specified cryptographic key distribution method: [from 802.1X Authorization Server] that meets the following: [ IEEE 802.11-2020 ] and does not expose the cryptographic keys . ### 6.10.2 Identification and Authentication (FIA) #### 6.10.2.1 FIA_8021X_EXT.1 802.1X Port Access Entity (Authenticator) Authentication | FIA_8021X_EXT.1.1 | The TSF shall conform to IEEE Standard 802.1X for a Port Access Entity (PAE) in the ' Authenticator ' role. | |---------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------| | FIA_8021X_EXT.1.2 | The TSF shall support communications to a RADIUS authentication server conforming to RFCs 2865 and 3579. | | FIA_8021X_EXT.1.3 | The TSF shall ensure that no access to its 802.1X controlled port is given to the wireless client prior to successful completion of this authentication exchange. | #### 6.10.2.2 FIA_UAU.6 Re-Authenticating FIA_UAU.6.1 The TSF shall re-authenticate the administrative user under the conditions [ when the user changes their password , [ selection : following TSF-initiated session locking ]]. ### 6.10.3 Security Management (FMT) - 6.10.3.1 FMT_SMF.1/AccessSystem Specification of Management Functions (WLAN Access Systems) FMT_SMF.1.1/AccessSystem The TSF shall be capable of performing the following management functions: - Configure the security policy for each wireless network, including: - Security type - Authentication protocol - Client credentials to be used for authentication - Service Set Identifier (SSID) - If the SSID is broadcasted - Frequency band set to [ selection : 2.4 GHz, 5 GHz,6 GHz - Transmit power level #### 6.10.3.2 FMT_SMR_EXT.1 No Administration from Client FMT_SMR_EXT.1.1 The TSF shall ensure that the ability to administer remotely the TOE from a wireless client shall be disabled by default. ### 6.10.1 Security Audit (FAU) #### 6.10.1.1 FAU_GEN.1/WLAN Audit Data Generation FAU_GEN.1.1/WLAN The TSF shall be able to generate an audit record of the following auditable events: - a. Start-up and shutdown of the audit functions; - b. All auditable events for the [not specified] level of audit; and - c. [Auditable events listed in the Auditable Events table ( Table 7 ) - d. Failure of wireless sensor communication] | Requirement | Auditable Events | Additional Audit Record Contents | |------------------------|--------------------------------------------------------------------------------------------------------------|---------------------------------------------------------------------------------------------| | FCS_CKM.1/WPA | None. | None. | | FCS_CKM.2/GTK | None. | None. | | FCS_CKM.2/PMK | None. | None. | | FIA_8021X_EXT.1 | Attempts to access the 802.1X controlled port prior to successful completion of the authentication exchange. | Provided client identity (e.g., Media Access Control [Media Access Control (MAC)] address). | | FIA_8021X_EXT.1 | Failed authentication attempt. | Provided client identity (e.g., MAC address). | | FIA_UAU.6 | Attempts to re-authenticate. | Origin of the attempt (e.g., IP address). | | FMT_SMF.1/AccessSystem | None. | None. | | FMT_SMR_EXT.1 | None. | None. | | FPT_FLS.1 | Failure of the TSF. | Indication that the TSF has failed with the type of failure that occurred. | | FPT_TST_EXT.1 | Execution of TSF self-test. | None. | | FPT_TST_EXT.1 | Detected integrity violations. | The TSF code file that caused the integrity violation. | | FTA_TSE.1 | Failure of the TSF. | Indication that the TSF has failed with the type of failure that occurred. | Table 7: Auditable Events | FTP_ITC.1 | Failed attempts to establish a trusted channel (including IEEE 802.11). Identification of channel. | the initiator and target of | |-------------|------------------------------------------------------------------------------------------------------|-------------------------------| | FTP_ITC.1 | Detection of modification of channel data. | None. | ### 6.10.2 Protection of the TSF (FPT) #### 6.10.2.1 FPT_FLS.1 Failure with Preservation of Secure State FPT_FLS.1.1 The TSF shall preserve a secure state when the following types of failures occur: [assignment: failure of the self-tests ]. ### 6.10.3 TOE Access (FTA) #### 6.10.3.1 FTA_TSE.1 TOE Session Establishment FTA_TSE.1.1 The TSF shall be able to deny session establishment of a wireless client session based on [ TOE interface, time, day, [selection : [assignment: no other attributes] ]]. ### 6.10.4 Trusted Path/Channels (FTP) #### 6.10.4.1 FTP_ITC.1/Client Inter-TSF Trusted Channel (WLAN Client Communications) | FTP_ITC.1.1/Client | The TSF shall be capable of using WPA3-Enterprise, WPA2- Enterprise and [ selection : WPA3-SAE, WPA2-PSK] as defined by IEEE 802.11-2020 to provide a trusted communication channel between itself and WLAN clients that is logically distinct from other communication channels and provides assured identification of its end points and protection of the channel data from disclosure and detection of modification of the channel data. | |----------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | FTP_ITC.1.2/Client | The TSF shall permit the authorized IT entities to initiate communication via the trusted channel. | | FTP_ITC.1.3/Client | The TSF shall initiate communication via the trusted channel for [no services]. | ### 7 Security Assurance Requirements This Security Target claims conformance to EAL2 with the following SARs: · ADV_ARC.1 · ADV_FSP.2 · ADV_TDS.1 · AGD_OPE.1 · AGD_PRE.1 · ALC_FLR.2 · ALC_CMC.2 · ALC_CMS.2 · ALC_DEL.1 · ASE_CCL.1 · ASE_ECD.1 · ASE_INT.1 · ASE_OBJ.2 · ASE_REQ.2 · ASE_SPD.1 · ASE_TSS.2 · ATE_COV.1 · ATE_FUN.1 · ATE_IND.2 - AVA_VAN.2 The assurance package was chosen to add another level of security and more assurance to the evaluation of the TOE. ### 8 TOE Summary Specification ## 8.1 Security audit FAU_GEN.1, FAU_GEN.2, FAU_GEN_EXT.1, FAU_GEN.1/WLAN: The TOE is designed to be able to generate log records for a wide range of security relevant and other events as they occur. The events that can cause an audit record to be logged include starting and stopping the audit function as well as all of the events identified in Table 6. 1)Administrative login and logout (including the name of the user account). 2)Enabling and disabling communications between a pair of components. 3)Changes to TSF data related to configuration changes (in addition to the information that a change occurred it shall be logged what has been changed). 4)Generating/import of, changing, or deleting of cryptographic keys (in addition to the action itself a unique key name or key reference is logged). 5)Resetting passwords (name of related user account is logged). 6)Attempts to initiate a TOE update. 7)Modification of the behavior of the transmission of audit data to an external IT entity. APs generate audit records for the security relevant audit events which occur on that device and send these to the AC via the CAPWAP tunnel. In general, the logged audit records identify the date and time, the nature or type of the triggering event, an indication of whether the event succeeded, failed or had some other outcome, and the identity of the agent (e.g., user) responsible for the event. The logged audit records also include event-specific content that includes at least all of the content required in Table 6. FAU_STG_EXT.1: The TOE includes an internal log implementation that can be used to store and review audit records locally. However, the internal audit log is a circular buffer that will overwrite the oldest records when it becomes full. The TOE can be configured to send generated audit records to an external Audit server in to mitigate the possibility of losing audit records. Audit records generated by the AP are sent to the AC, where they are stored and then forwarded to the remote audit server. If the connection between the AP and the controller is lost, logs will continue to be stored on the AP. Once the connection is restored, the AP can automatically send the logs to the AC. Logs are not persistently stored after an AP restart. The TOE uses IPsec to protect the communication channel with the remote audit server and DTLS to protect the communication channel between the AC and the AP. If an external audit server is enabled, all audit logs are written simultaneously (in real-time) to both the local audit log on the AC and the audit server. The local audit log and the logs sent to the remote server are the same. For audit records stored locally on the AC, the minimum log capacity size is 1MB. The local AC log storage uses a newover-oldest method, so when available space is exhausted, the audit logs will be overwritten. FAU_STG.2: The internal log can be accessed only by a user with the network-admin, network-operator, securityaudit role, who can review or archive stored audit records using available CLI commands specifically designed for the management of the internal LOG. Only network-admin and security-audit user can delete log. The functions available to review audit records allow the audit records to be sorted in forward or reverse order according to date/time and to be searched using regular expressions. AP ' s audit log sends to AC through capwap tunnel. FAU_STG_EXT.4, FAU_STG_EXT.5: AP buffers audit records for transmission to AC for storage. If the buffer is full, the oldest audit records will be overwritten. The transmission of audit records to the AC is conducted over a DTLSprotected channel, according to FPT_ITT.1. FMT_MOF.1.1/Functions: The security administrator can configure and modify the local audit log to be sent to the audit server using the ' info-center loghost ' command. The Security audit function is designed to satisfy the following security functional requirements: FAU_GEN.1.1/WLAN, FAU_GEN.1, FAU_GEN.2, FAU_GEN_EXT.1, FAU_STG.2, FAU_STG_EXT.1, FAU_STG_EXT.4, FAU_STG_EXT.5, FMT_MOF.1/Functions. ## 8.2 Cryptographic support The TOE includes a crypto-module providing supporting cryptographic functions. FCS_CKM.1 For asymmetric key pairs used for authentication, the TOE can generate RSA (3072, and 4096 bits) and ECDSA (P-256, P-384, and P-521) pair-wise keys. Additionally, the administrator can load and remove user SSH public keys that the TOE will use to authenticate SSH clients. FCS_CKM.2 Key Exchange Mechanism, The TOE supports generating temporary ECDH and DH key pairs for TLS/DTLS, IPsec, and SSHv2 for use in the key exchange process. TLS/DTLS key exchange: The TOE uses the temporary Elliptic Curve Diffie-Hellman (ECDH) key agreement protocol, supporting the following curves: secp256r1 (P-256), secp384r1 (P-384), secp521r1 (P-521) IPsec key exchange: In IKEv2, the TOE uses temporary ECDH keys (supporting group 19 [NIST P-256], group 20 [NIST P-384]) and DH keys (group 24). SSHv2 key exchange: TOE uses a mutually agreed key exchange algorithm (supporting ecdh-sha2-nistp256, ecdhsha2-nistp384) during the SSH login process to generate a temporary key pair, which is used to produce the subsequent shared key. All key exchanges use temporary keys to provide forward secrecy. | Scheme | SFR | Service | |----------|-----------------|------------------------------------------------------------------------------------| | DH | FCS_IPSEC_EXT.1 | Protect the transmission of audit logs, authentication messages, and NTP messages. | | ECDH | FCS_IPSEC_EXT.1 | Protect the transmission of audit logs, authentication messages, and NTP messages. | |--------|-------------------|--------------------------------------------------------------------------------------| | ECDH | FCS_SSH_EXT.1 | SSH Remote administration | | ECDH | FCS_SSHS_EXT.1 | SSH Remote administration | | ECDH | FCS_DTLSC_EXT.1 | AP communicates with AC | | ECDH | FCS_DTLS_EXT.1 | AP communicates with AC | | ECDH | FCS_TLSC_EXT.1 | AP communicates with AC | | ECDH | FCS_TLSS_EXT.1 | AP communicates with AC | FCS_CKM.3: The TSF shall perform private key in accordance with a specified cryptographic key access method Export the certificate and private key to a PKCS12 file that meets the following: PKCS#12. Use ' pki export domain ' Command to export private key. FCS_COP.1/DataEncryption: The TOE encryption algorithm supports the GCM mode of AES as available ciphers, and all with key size 128, 192, and 256-bit. which are implemented in the TLS, DTLS, SSH and IPSec protocols. Wireless use AES (CCMP and GCMP) algorithms, with encryption key lengths of 128 bits and 192bits. Since NDcPP 3.0e no longer requires the implementation of FCS_IPSEC_EXT.1 CBC, Therefore, this SFR does not select CBC. FCS_COP.1/Hash: The TOE performs SHA-256, SHA-384, and SHA-512 cryptographic hashing services in accordance with ISO/IEC 10118-3:2004. The SHA hash algorithm is used as part of HMAC, but is also used as part of RSA digital signature creation and verification. FCS_COP.1/KeyedHash: The TOE HMAC algorithms supports the HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA512. | Algorithm | Block Size | Key Size | Digest Size | |-------------|--------------|------------|---------------| | HMAC-SHA256 | 512 bits | 256 bits | 256 bits | | HMAC-SHA384 | 1024 bits | 384 bits | 384 bits | | HMAC-SHA512 | 1024 bits | 512 bits | 512 bits | FCS_COP.1/SigGen: The TOE supports both RSA (modulus 3072 bits or greater) and ECDSA (p-256, P-384, p-521) signing and verification. The TOE verifies RSA signatures on firmware updates and supports RSA and ECDSA authentication during TLS/DTLS, SSH and IPsec. FCS_RBG.1: The TOE instantiates its AES-256 CTR_DRBG with a minimum of 256 bits of entropy from one softwarebased noise sources. that includes the following: - ◼ Compute timing jitter (CPU instruction-level latency) - ◼ Memory bus contention (cache miss timing deviation) - ◼ Interrupt event entropy (hardware interrupt response time variation) FCS_RBG.3: The TOE (Target of Evaluation) can use a software-based noise source to seed the Random Bit Generator (RBG), and the minimum entropy of this noise source is no less than 256 bits. FCS_NTP_EXT.1: The TOE provides the ability to synchronize its time with a NTP server using NTP v3 and v4. The time data is protected by SHA256, SHA384, and SHA512. The TOE updates its system time using IPsec to provide trusted communication between itself and an NTP time source. FCS_SSH_EXT.1.1 The TOE supports SSHv2 interactive command-line secure administrator sessions. The TOE implements the SSHv2 protocol, compliant to the following RFCs: 4251, 4252, 4253, 4254, 4256, 4344, 5647, 5656, 6187, 6668. FCS_SSH_EXT.1.2 The TOE supports public key-based and password-based authentication. The TOE allows use of the ecdsa-sha2nistp256, ecdsa-sha2-nistp384 algorithms for public key authentication. The TOE establishes a user identity when an SSH client presents a public key or correct password. The TOE continuously receives data from the network, with a buffer threshold of 256KB. It uses a "cumulative calculation + forced discard" processing strategy. When the amount of unprocessed data exceeds 256KB due to insufficient processing capacity or other reasons, the protection mechanism is triggered, and subsequent incoming network packets will be actively discarded until the backlog is processed below the threshold, at which point the FCS_SSH_EXT.1.3 system will resume receiving. FCS_SSH_EXT.1.4 The TOE supports AEAD_AES_128_GCM, AEAD_AES_256_GCM, aes128-gcm@openssh.com and aes256gcm@openssh.com for both encryption and data integrity. FCS_SSH_EXT.1.5 The TOE protect data in transit from modification, deletion, and insertion using AEAD_AES_128_GCM (RFC 5647), AEAD_AES_256_GCM (RFC 5647), Implicit. FCS_SSH_EXT.1.6 The TOE uses ecdh-sha2-nistp256/384 for SSHv2 key exchange. FCS_SSH_EXT.1.7 The TOE use SSH KDF as defined in RFC 5656 (Section 4) to derive the following cryptographic keys from a shared secret: session keys. FCS_SSH_EXT.1.8 Rekeying based on time, with a range of 30 to 60 minutes, configured by the user. Rekeying based on data traffic, with a range of 512 to 1024 MB, configured by the user. FCS_IPSEC_EXT.1.1 The TOE includes an implementation of IPsec/IKEv2 in accordance with RFC 2407, 2408, 2409, 3526, 3602, 4106, 4109, 4301, 4303, 4868, 4945, 5114, 5996. The process described for IPsec packet processing applies to both initial packets (before an SA is established) and packets that are already part of an established SA, with the following distinctions: Before the IPsec connection establishment is successful, if packets matching the IPsec policy, they will be directly discarded and not cached. Once the SA is established, subsequent packets matching the IPsec policy are processed using the relevant SA parameters (encryption, authentication) and flow through the IPsec tunnel. An IPsec policy set can contain multiple entries, each with a different access list (ACL). The IPsec policy entries are searched in a sequence - the TOE attempts to match the packet to the ACL specified in that entry. The traffic matching the permit IPsec policy ACL would then flow through the IPSec tunnel and be classified as ' PROTECTED ' . Traffic that does not match a permit IPsec policy ACL and is also blocked by packet filter ACL on the interface would be DISCARDED. Traffic that does not match a permit ACL in the IPsec policy, but that is not disallowed by packet filter ACLs on the interface is allowed to BYPASS the tunnel. FCS_IPSEC_EXT.1.3 The TOE supports IPsec in transport mode and tunnel mode. FCS_IPSEC_EXT.1.4 The IPsec AH and ESP protocol AES-GCM-128, AES-GCM-192 and AES-GCM-256 (as specified by RFC 4106) together with no HMAC algorithm. FCS_IPSEC_EXT.1.5 The TOE implements IKE2 with support for NAT traversal as defined in RFC 7296 and RFC 4868 for hash functions (HMAC-SHA-256, HMAC-SHA-384 and HMAC-SHA-512). FCS_IPSEC_EXT.1.6 The encrypted payload in the IKEv2 protocol uses the cryptographic algorithms AES-GCM-128, AES-GCM-192, AESGCM-256 (specified in RFC 5282). FCS_IPSEC_EXT.1.7 IKEv2 SA lifetimes can be configured by a Security Administrator based on length of time. The IKEv2 profile view ' sa duration ' command is used to configure the lifetime of the IKEv2 SA. Parameter is seconds: The lifetime of the IKEv2 SA, with a value range of 120 to 86400, in seconds. FCS_IPSEC_EXT.1.8 IKEv2 Child SA lifetimes can be configured by a Security Administrator based on number of bytes or length of time. In the IPsec policy view, the ' sa duration ' command is used to configure the lifetime of the IPsec SA. time-based seconds: specifies the time-based lifetime, with a value range of 180 to 604800 seconds. traffic-based kilobytes: specifies the traffic-based lifetime, with a value range of 2560 to 4294967295 kilobytes. FCS_IPSEC_EXT.1.9 The TOE generates the secret value x used in the IKEv2 Diffie-Hellman key exchange using the FIPS validated RBG specified in FCS_RBG.1 and having possible lengths of 256 bits for DH group 24, 256 bits for DH group 19, and 384 bits for DH group 20. The TOE generates nonces used in the IKEv2 exchanges of 256 bits in size. Nonces are generated using RBG meet the requirements specified in FCS_RBG1 for random bit generation. FCS_IPSEC_EXT.1.10 The TSF generate nonces used in IKEv2 exchanges of length 256 bits. FCS_IPSEC_EXT.1.11 During the IKE_SA_INIT exchange phase, the originator uses a "guess" method to speculate on the most likely DH group that the responder will use and sends this guess in the first message. The responder then responds based on the DH group guessed by the originator. If the originator's guess is correct, the IKE_SA_INIT exchange can be completed with just two messages. If the guess is incorrect, the responder will reply with an INVALID_KE_PAYLOAD message, specifying the DH group to be used. Following this, the originator will re-initiate the negotiation using the DH group specified by the responder. This DH guessing mechanism makes the originator's DH group configuration more flexible, allowing it to adapt to different responders. Multiple DH parameters can be configured, with their precedence decreasing in the order of configuration. FCS_IPSEC_EXT.1.12 The Administrator is responsible for ensuring that IKE/IPsec policies are configured so that the strength of the negotiated symmetric algorithm (in terms of the number of bits in the key) in the IKEv2 CHILD_SA is less than or equal to the strength of the IKEv2 IKE_SA. FCS_IPSEC_EXT.1.13 IKE protocols perform peer authentication using RSA, ECDSA that use X.509v3 certificates that conform to RFC 4945 and Pre-shared Keys. The TOE supports both RSA (modulus 3072 bits or greater) and ECDSA (p-256, P-384, p-521) signing and verification. Pre-shared Keys: Both parties in the communication authenticate the peer's identity using a shared key. The PSK configured for IKE negotiation on both sides must be the same, otherwise authentication will fail. Whether set in plaintext or ciphertext, the PSK is stored in the configuration file in ciphertext form. The "pre-shared-key" command in IKEv2 peer view is used to configure the pre-shared key for an IKEv2 peer. FCS_IPSEC_EXT.1.14 The TOE will only establish a trusted IPsec channel if the presented identifier in the received certificate matches the configured reference identifier, where the presented and reference identifiers are of the following type: IP address and Fully Qualified Domain Name (FQDN) in SAN or CN, Distinguished Name (DN). Certificate-based access control policies allow you to authorize access to a device based on the attributes of an authenticated client's certificate. A certificate-based access control policy is a set of access control rules (permit or deny statements), each associated with a certificate attribute group. A certificate attribute group contains multiple attribute rules, each defining a matching criterion for an attribute in the certificate issuer name, subject name, or alternative subject name field. If the corresponding attributes in a certificate meet all the attribute requirements of the attribute set associated with an access control rule, the certificate is considered to match the rule. If there are multiple rules in an access control policy, the rules are traversed in ascending order of their rule numbers. Once the certificate matches a rule, the inspection is immediately terminated and no further rules are checked. The following conditions describe how a certificate-based access control policy verifies the validity of a certificate: · If a certificate matches a permit statement, the certificate passes the verification. · If a certificate matches a deny statement or does not match any statements in the policy, the certificate is regarded invalid. · If a statement is associated with a non-existing attribute group, or the attribute group does not have attribute rules, the certificate matches the statement. · If the certificate-based access control policy specified for a security application does not exist, all certificates in the application pass the verification. A certificate matches an attribute group if it matches all attribute rules in the group. SAN and CN do not share matching; they are two independent attribute rules. FCS_DTLSC_EXT & FCS_DTLSS_EXT DTLS & FCS_TLSC_EXT & FCS_TLSS_EXT TLS: DTLS and TLS are used to protect TSF data from disclosure and detect its modification when it is transmitted between AP and AC. AP services as TLS and DTLS client and AC service as TLS and DTLS server. FCS_DTLSC_EXT & FCS_DTLSS_EXT DTLS & FCS_TLSC_EXT & FCS_TLSS_EXT TLS: DTLS and TLS are used to protect TSF data from disclosure and detect its modification when it is transmitted between AP and AC. AP services as TLS and DTLS client and AC service as TLS and DTLS server. FCS_DTLSC_EXT.1.1, FCS_DTLSS_EXT.1.1, FCS_TLSC_EXT.1.1, FCS_TLSS_EXT.1.1: TOE supports the following cipher suites: ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, ECDHE_RSA_WITH_AES_128_GCM_SHA256, ECDHE_RSA_WITH_AES_256_GCM_SHA384 If TOE uses an unsupported or undefined SSL and TLS version, the AC and AP negotiation fails, and the connection cannot be established. FCS_DTLSC_EXT.1.2: DTLS client and server confirm to DTLS 1.2 (RFC 6347). DTLS session is established only when the server certificate is valid. The AP verify the presented identifier of AC ' s certificate using id-at-title. TLS client and server confirm to TLS 1.2 (RFC 5246). TLS session is established only when the server certificate is valid. The AP verify the presented identifier of AC ' s certificate using id-at-title. FCS_DTLSC_EXT.1.4: TOE supports group extensions with the following curves/groups in the Client Hello message: secp256r1, secp384r1, secp521r1, consistent with the curves/groups of the imported certificate. FCS_DTLSC_EXT.1.5: TOE supports the signature_algorithms expansion, which is executed by default and is not configurable. FCS_DTLSC_EXT.1.6: The TSF does not provide the ability to configure the list of supported ciphersuites as defined in FCS_DTLSC_EXT.1.1. FCS_DTLSC_EXT.1.10: The TOE supports terminate the DTLS session if a message received contains an invalid MAC. FCS_DTLSC_EXT.1.11: The TOE supports detecting and discarding replayed DTLS packets, such as DTLS records that have been previously received or DTLS records that are too old and fall outside the sliding window. Sequence Number Verification Mechanism: - ⚫ Each DTLS record contains a 16-bit sequence number. - ⚫ The sequence number increments in the order of transmission. - ⚫ The receiver must detect and discard duplicate records (replay attack) or outdated records (out of window range). Sliding Window: the TOE uses a fixed-size bitmap window (default size 64) to track valid sequence numbers: - ⚫ Window Top (window_top): The highest sequence number currently received. - ⚫ Window Bitmap (window_bitmap): A 64-bit mask that marks which sequence numbers within the window have been received. Window Range: Valid sequence numbers must satisfy window_top - 64 < seq ≤ window_top + 1. FCS_DTLSS_EXT.1.2: The TOE does not provide the ability to verify the client IP. The TOE generates cookies using HMAC-SHA256, with the calculation incorporating the client IP address, timestamp, and server key. Upon receiving a ClientHello message, the TOE verifies the validity of the cookie's HMAC signature. FCS_DTLSS_EXT.1.3: The TSF shall authenticate itself using X.509 certificate(s) using: - ◼ RSA with key size 3072, 4096 bits; ECDSA over NIST curves secp256r1, secp384r1, secp521r1. FCS_DTLSS_EXT.1.4: The TSF shall perform key exchange using: EC Diffie-Hellman key agreement over NIST curves secp256r1, secp384r1, secp521r1. FCS_DTLSS_EXT.1.5: The TSF shall silently discard the record if a message received contains an invalid MAC. FCS_DTLSS_EXT.1.6: The TSF shall detect and silently discard replayed messages for DTLS records previously received or DTLS records too old to fit in the sliding window. Sequence Number Verification Mechanism: - ⚫ Each DTLS record contains a 16-bit sequence number. - ⚫ The sequence number increments in the order of transmission. - ⚫ The receiver must detect and discard duplicate records (replay attack) or outdated records (out of window range). Sliding Window Mechanism: the TOE uses a fixed-size bitmap window (default size 64) to track valid sequence numbers: - ⚫ Window Top (window_top): The highest sequence number currently received. - ⚫ Window Bitmap (window_bitmap): A 64-bit mask that marks which sequence numbers within the window have been received. - ⚫ Window Range: Valid sequence numbers must satisfy window_top - 64 < seq ≤ window_top + 1. FCS_DTLSS_EXT.1.7: TOE does not support session resumption. FCS_DTLSS_EXT.1.8: The TSF provide the ability to configure the list of supported ciphersuites as defined in FCS_DTLSS_EXT.1.1. FCS_DTLSS_EXT.1.10: The TSF shall not use PSKs. FCS_TLSC_EXT.1.2: TLS client and server confirm to TLS 1.2 (RFC 5246). TLS session is established only when the server certificate is valid. The AP verify the presented identifier of AC ' s certificate using id-at-title. The TOE does not support using IP addresses as reference identifiers in common name. FCS_TLSC_EXT.1.4: The TOE supports group extensions with the following curves/groups in the Client Hello message: secp256r1, secp384r1, secp521r1, consistent with the curves/groups of the imported certificate. FCS_TLSC_EXT.1.5: The TOE supports the signature_algorithms expansion, which is executed by default and is not configurable. FCS_TLSC_EXT.1.6: The TOE does not support the configuration of ciphersuites. FCS_TLSC_EXT.1.8: The TSF shall not use PSKs. FCS_TLSS_EXT.1.2: The TSF shall authenticate itself using X.509 certificate(s) using: - ◼ RSA with key size 3072, 4096 bits; - ◼ ECDSA over NIST curves secp256r1, secp384r1, secp521r1. FCS_TLSS_EXT.1.3: The TSF shall perform key exchange using: EC Diffie-Hellman key agreement over NIST curves secp256r1, secp384r1, secp521r1. FCS_TLSS_EXT.1.4: TOE does not support session resumption. FCS_TLSS_EXT.1.5: The TOE supports ciphersuites can be configured. FCS_TLSS_EXT.1.7: The TSF shall not use PSKs EPWLAN: FCS_CKM.1/WPA & FCS_CKM.2/GTK & FCS_CKM.2/PMK The TOE supports cryptographic key distribution for 802.11 PMK key reception from an 802.1X authentication server. If the WLAN client successfully authenticates using 802.1X, the RADIUS authentication server returns an AccessAccept packet and generates a Pairwise Master Key (PMK) that meets [IEEE 802.11-2012 and does not expose the cryptographic keys. The RADIUS authentication server then distributes the PMK to the Access Controller and the WLAN client. The target object (TOE) also generates a Group Master Key (GMK). The TOE provides IPsec to protect the PMK received from the RADIUS authentication server. The PMK is received by the TOE via the MS-MPPE-RecvKey EAP attribute. If PSK authentication is used for identity verification, the PMK is generated from the PSK key, and both the client and the AC use this PMK to generate the PTK and GTK. The Access Controller and the WLAN client execute a four-way handshake process to derive a Pairwise Transient Key (PTK) from the master key, and, if necessary, a Group Temporal Key (GTK). The TSF implements the PRF-384 and PRF-704 key derivation algorithms according to the [IEEE 802.11-2020] and [IEEE 802.11ax-2021] standards to derive the required number of bits for generating the Pairwise Transient Key (PTK) and the Group Temporal Key (GTK). The Access Controller securely distributes the GTK to the WLAN client using a Key Encryption Key (KEK) and distributes the PTK and GTK to the AP via an internally trusted channel protected by DTLS. The TSF use AES Key Wrap in an EAPOL-Key frame to distribute Group Temporal Key (GTK), that meets NIST SP 800-38F, IEEE 802.11-2012 for the packet format and timing considerations and does not expose the cryptographic keys. The GTK is used to protect multicast/broadcast traffic and is shared among all WLAN clients and APs. Key management defines how to generate and update the PTK and group temporary key (GTK). The PTK is used in unicast and the GTK is used in multicast and broadcast. PTK structure: KCK | KEK | TK EAPOL-Key Confirmation Key (KCK) is used to verify the integrity of an EAPOL-Key frame. EAPOL-Key Encryption Key (KEK) is used to encrypt the key data in the EAPOL-Key frame. Temporal Key (TK) is used to encrypt unicast packets. The GTK includes the TK and other fields. The TK is used to encrypt multicast and broadcast packets. EAPOL-Key packet: The IEEE 802.11i protocol uses EAPOL-Key packets during key negotiation. RSN uses EAPOL-Key packets in the four-way handshake to negotiate the PTK and the GTK. RSN key negotiation uses the following process: 1. The AC sends the client EAPOL-Key message 1 that contains a random value ANonce. 2. The client performs the following operations: - a. Uses the random value SNonce, ANonce, and PMK to generate a PTK by using the KDF (key derivation function). - b. Uses the KCK in the PTK to generate the MIC ( Message integrity check ). - c. Returns EAPOL-Key message 2 that contains the SNonce and MIC. 3. The AC performs the following operations: - a. Uses the SNonce, ANonce, and PMK to generate a PTK by using the KDF. - b. Uses the KCK in the PTK to generate the MIC. - c. Compares the received MIC with the local MIC. - d. Generates a GTK with the random GMK and MAC address of the AP by using the KDF if the two MICs are the same. - e. Returns EAPOL-Key message 3 that contains the key installation request tag, MIC, and GTK. 4. The client performs the following operations: - a. Compares the received MIC with the local MIC. - b. Installs the PTK and GTK if the two MICs are the same. - c. Returns EAPOL-Key message 4 that contains the MIC. 5. The AC performs the following operations: - a. Compares the received MIC with the local MIC. - b. Installs the PTK and GTK if the two MICs are the same. WLAN networks enhance WLAN security through key update mechanisms in identity authentication and key management. Key updates include PTK updates and GTK updates. PTK Update: PTK update is a security measure for updating the encryption key of unicast datagrams. It employs a mechanism of re-performing a four-way handshake to negotiate a new PTK key, thereby enhancing security. GTK Update: GTK update is a security measure for updating the encryption key of multicast datagrams. It uses a mechanism of re-performing a two-way multicast handshake to negotiate a new GTK key, thereby enhancing security. The implementation of TOE was also subjected to systematic internal testing during the product development process, and regression testing was conducted according to internal policies, including packet capture to acknowledge message structure. H3C conducts interoperability tests by connecting to H3C Wi-Fi access points using different client operating systems (include Windows, Mac OS X, Linux, Apple iOS, Android, etc.). Guaranteed through Wi-Fi Alliance testing and certification. The developer's test approach includes systematic functional testing to verify that product development meets standard requirements. Guaranteed through Wi-Fi Alliance testing and certification. Additionally, internal development policies include code review and approval processes to further ensure compliance during implementation. The Cryptographic support function is designed to satisfy the following security functional requirements: FCS_CKM.1, FCS_CKM.2, FCS_CKM.6, FCS_COP.1/DataEncryption, FCS_COP.1/SigGen, FCS_COP.1/Hash, FCS_COP.1/KeyedHash, FCS_RBG.1,FCS_RBG.3, FCS_IPSEC_EXT.1, FCS_NTP_EXT.1, FCS_SSH_EXT.1,FCS_SSHS_EXT.1, FCS_DTLSC_EXT.1, FCS_DTLSS_EXT.1, FCS_TLSC_EXT.1, FCS_TLSS_EXT.1, FCS_CKM.1/WPA, FCS_CKM.2/GTK, FCS_CKM.2/PMK. ## 8.3 Identification and authentication The TOE is designed to require users to be identified and authenticated before they can access any of the TOE functions. The TOE supports the local definition of users with corresponding password and role. The passwords can be composed of any combination of upper- and lower-case letters, numbers, and special characters. Minimum password length is settable by the authorized security administrator, the minimum length range is 15 to 32 and supports password of 15 to 63 characters. The administrator can also configure the TOE to authenticate users using an external authentication server. The TOE supports RADIUS and HWTACACS servers. A trusted channel using IPsec is established between TOE and external authentication server. Administrators can connect to the TOE via a local console or remotely using SSHv2 Local administrators can access the TOE CLI interface via a serial console (direct) connection by using username and password. Remote administrators can access the CLI interface via an SSH protocol connection from an SSH client. TOE provide password-based and public-key-based authentication mechanism for SSH. For public-key-based, administrator must import user public key into the configuration of TOE. The algorithm of public-key or certification public-key support ECDSA. When logging via password, only obscured feedback is provided so the password is not visible when the user is inputting it. The TOE provides the security administrator the ability to specify the maximum number of unsuccessful authentication attempts before administrator or user is locked out. While the TOE supports a range from 2-10. When the defined number of unsuccessful authentication attempts has been met, the TOE shall prevent the offending Administrator from accessing TOE using any authentication method until unlock is taken by a Security Administrator or an Administrator defined time period has elapsed. IPsec, TLS/DTLS support X.509 certificate authentication. The certificate chain is a sequence of certificates, from a peer certificate to the root CA certificate. Within the PKI hierarchy, all enrolled peers can validate the certificate of one another if the peers share a trusted root CA certificate or a common subordinate CA. Each CA corresponds to a trust point. When a certificate chain is received from a peer, TOE processing of a certificate chain path continues until the first trusted certificate, or trust point, is reached. TOE validate certificates in certificate chain according RFC 5280 certificate validation. The TOE also validates the revocation status of the certificate using a Certificate Revocation List (CRL) and check the basicConstraints extension and the CA flag to determine whether they are present and set to TRUE. If the connection to determine the certificate validity cannot be established, the certificate is not accepted and the connection will not be established. The TOE forces the administrator to re-authenticate when its password is changed. The TOE can use pre-shared keys for IEEE 802.11 WPA2-PSK, that support both text-based and bit-based pre-shared keys. For text-based pre-shared keys that are 8 to 63 characters, and are composed of any combination of upper- and lower-case letters, numbers, and special characters (that include: ' ! ' , ' @ ' , ' # ' , ' $ ' , ' % ' , ' ^ ' , ' & ' , ' * ' , ' ( ' , and ' ) ' ). For bit-based pre-shared keys that are 64 hexadecimal digits. The TOE support wireless 802.1X Authentication. When a wireless client associates with TOE under an 802.1x authentication architecture, an EAP exchange takes place, followed by a four-way handshake to verify the encryption keys. The TOE acts as the authenticator, relaying information between the authentication server and supplicant. The EAP type must be consistent between the authentication server and supplicant, and is transparent to the TOE. Before 802.1x authentication was successful, the TOE only forward EAPOL frame from or to wireless client. The Identification and authentication function is designed to satisfy the following security functional requirements: FIA_AFL.1: After an administrator specified (2-10) number of failed attempts, the TOE will lockout (blacklist) the offending remote administrator and log the event. The offending administrator will remain locked out until the administrator configured lock-out period has expired or administrator unlock. FIA_AFL.1 is enforced by the TOE ， but is not applicable when using external authentication servers. FIA_PMG_EXT.1: The TOE authentication mechanism provides configuration for minimum password length. The following calculation is based on the following facts: Minimum password length You can define the minimum length of user passwords. The system rejects the setting of a password that is shorter than the configured minimum length. The minimum length range is 15 to 32. Password composition policy A password can be a combination of characters from the following types: - Uppercase letters A to Z. - Lowercase letters a to z. - Digits 0 to 9. - Special characters in Table 1. ####### Table 1 Special Characters | Character name | Symbol | Character name | Symbol | |--------------------|----------|---------------------|----------| | Ampersand sign | & | Apostrophe | ' | | Asterisk | * | At sign | @ | | Back quote | ` | Back slash | \ | | Blank space | N/A | Caret | ^ | | Colon | : | Comma | , | | Dollar sign | $ | Dot | . | | Equal sign | = | Exclamation point | ! | | Left angle bracket | < | Left brace | { | | Left bracket | [ | Left parenthesis | ( | | Minus sign | - | Percent sign | % | | Plus sign | + | Pound sign | # | | Quotation marks | " | Right angle bracket | > | | Right brace | } | Right bracket | ] | | Right parenthesis | ) | Semi-colon | ; | | Character name Slash | Symbol / | Character name Tilde | Symbol | |------------------------|------------|------------------------|----------| | Underscore | _ | Vertical | ~ | | | | bar | | | Password complexity checking policy For higher security, you can configure a password complexity checking policy to ensure that all user passwords are relatively complicated. When a user configures a password, the system checks the complexity of the password. If the password is complexity-incompliant, the configuration will fail. ###### Password history record The password for the device management user is stored in a hashed ciphertext format and cannot be restored to plaintext. Therefore, when configuring a new password for the device management user: if the new password is set in a hashed manner, it will not be compared with all recorded historical passwords and the current password; if the new password is configured in plaintext, it must be different from all recorded historical passwords and the current password. Additionally, when the user is required to enter the old password for verification, it must be checked that the new password and the user-entered old password differ by at least 4 characters, and these 4 characters must be distinct from each other; otherwise, the password change will fail. FIA_UIA_EXT.1: The TOE requires an administrator to be successfully identified and authenticated before allowing any other TSF-mediated actions on behalf of that user. Before requiring a non-TOE entity to initiate the identity verification and authentication process, the TOE will display warning notifications and unauthorized usage consent warnings specified by the authorized administrator (FTA_TAB.1). The TOE requires the administrator to successfully identify and authenticate before accessing the management console and performing any other TSF-mediated operations on behalf of the user. Once the TOE is operational, the administrator can access the TOE interface through the AC using the CLI (SSH). The login process is initiated by the administrator via the required interface, and the administrator receives an authentication challenge. If the administrator enters valid credentials, the authentication process will be successfully completed, and the management interface will be displayed to the administrator. Administrators cannot log in to the AP since those interfaces are disabled after initial configuration. The TOE supports replaying ICMP echo prior to requiring the non-TOE entity to initiate the identification and authentication process. FIA_UAU.7: TOE provides only vague feedback to administrative users when verifying identity on the local console, without echoing the entered password. FIA_X509_EXT.1/ITT: The TOE performs X.509 certificate validation at the following points: - ◼ When importing a certificate. - ◼ When establishing an SSL or DTLS trusted channel, verify the peer (AP verifies AC). The TSF shall validate certificates in accordance with the following rules: - ◼ RFC 5280 certificate validation and certification path validation supporting a minimum path length of two certificates. - ◼ The certification path must terminate with a trusted CA certificate designated as a trust anchor. - ◼ The TSF shall validate a certification path by ensuring that all CA certificates in the certification path contain the basicConstraints extension with the CA flag set to TRUE. - ◼ The TSF shall validate the revocation status of the certificate using CRL. - ◼ The TSF shall validate certificates in accordance with the following rules: - ◆ Server certificates presented for TLS shall have the Server Authentication purpose (id-kp 1 with OID 1.3.6.1.5.5.7.3.1) in the extendedKeyUsage field. FIA_X509_EXT.1/Rev: The TOE performs X.509 certificate validation at the following points: - ◼ When importing a certificate. - ◼ During IPsec peer authentication In all scenarios, certificates are checked for several validation characteristics: - ◼ If the certificate 'notAfter' date is in the past, then this is an expired certificate which is considered invalid; - ◼ The certificate chain must terminate with a trusted CA certificate designated as a trust anchor; - ◼ A trusted CA certificate is defined as any certificate loaded into the TOE trust store that has, at a minimum, a basicConstraints extension with the CA flag set to TRUE; Certificate revocation checking is performed when the certificate is presented to the TOE and when it is loaded into the TOE, and only the leaf certificate is validated. The TOE does not use any extendedKeyUsage rules for FIA_X509_EXT.1/Rev. FIA_X509_EXT.1/Rev focuses only on IPsec and does not involve code signing or web servers. Certificate checks support only CRL and not OCSP. FIA_X509_EXT.2: The TOE uses X.509v3 certificates defined in RFC 5280 to support IPsec or SSL authentication, which can be imported and specified. When a connection cannot be established to determine the validity of a certificate, the certificate is not accepted. No other distinctions are made between trusted channels, and certificate validation is performed in the same manner across trusted channels. FIA_X509_EXT.3: The TOE generates Certificate Request Messages and includes the following information: public key, common name, organization, organizational unit, country, FQDN, title. Upon receiving the CA Certificate response, the TOE will validate the chain of certificates from the Root CA. FIA_UAU.6: The TOE requires a user to reauthenticate when a password is changed or the session is locked. FIA_8021X_EXT.1: For 802.1X authentication, extended authentication protocol (EAP) is used to communicate between the wireless client and the TOE over the local area network (EAPOL). The TOE also establishes an IPsec tunnel with the RADIUS authentication server. Management can be performed via an external RADIUS server that complies with RFC 2865 and RFC 3579 standards. The TSF follows port-based network control as defined in Clause 7.1 and EAP as defined in Clause 8 and Clause 11 of [IEEE 802.1X-2010]. For Clause 8, the TOE acts only as an Authenticator. For Clause 11, the TOE supports only the first four message processes of Table 11-3 - EAPOL Packet Types. These meet the wireless 802.1x authentication requirements. FIA_AFL.1, FIA_PMG_EXT.1, FIA_UIA_EXT.1, FIA_UAU.7, FIA_X509_EXT.1/Rev, FIA_X509_EXT.2, FIA_X509_EXT.3, FIA_UAU.6, FIA_8021X_EXT.1, FIA_X509_EXT.1/ITT. ## 8.4 Security management The TOE implements a role mechanism that is used to specify the role and corresponding permissions which authenticated users possess. The TOE maintains Security Administrators that includes privileged and semi-privileged roles. The privileged role can access all features and resources in the system except some specific commands, and can perform all of the operations defined in FMT_SMF.1. This is privilege level 15 or Network-admin or Network Administrator. Semi-privileges roles are any that have a subset of the privileges of the level 15. Privilege level 0, 1 (also known as network-operator) and 9 are defined by default and are customizable, privilege 2 to 8 and 10 to 14 are undefined by default and are customizable. It exists also a pre-defined privilege level called Security-audit with rights to display and maintain security log files. Use of the level-0 through level-14 roles, as well as the network-operator role, is not required in order to properly administer a TOE. These roles possess a subset of the permissions of the network-admin role and thus are capable of only some of the management functions available to him. The TOE offers command-line interface providing a range of security management functions for use by Security Administrators. Among the functions available are those functions that are necessary to manage all aspects of the cryptographic functions of the TOE, those necessary to enable or disable the network services offered by the TOE, and the functions necessary to review the TOE versions, update the TOE components, and also to verify the validity of those updates. FMT_MOF.1/ Functions: Only Security Administrators can modify the behavior of the transmission of audit data to an external audit server. A user with no administrator privileges cannot configure and enable the info-center function. FMT_MTD.1/CoreData: Only Security Administrators can manage TSF data. There are no security functions available through any interfaces prior to administrator login. Non-administrative users (i.e., wireless users) do not have access to the TOE via the CLI, therefore, they do not have any access to the security functions of the TOE. FMT_MOF.1.1/ ManualUpdate: Management of security functions behaviour related to manual updates is provided by FMT_MOF.1/ManualUpdate. In order to meet this SFR, The TSF restricts the ability to enable the functions to perform manual updates to Security Administrators. In addition, only security administrators have the right to create or delete users in the TOE. While changing the local user privilege level, the configured new level of the local user cannot be higher than that of the login-in user. In this way no user except administrators can change another user to be at the privilege level of administrator, and only administrators have the ability to perform manual update. Therefore, the manual update is restricted to administrators. The TOE uses groups to organize users. Security administrators must first transfer the candidate AP update onto the AC. It will be downloaded to the AP the next time the AP component connects to the AC (assuming the digital signature is valid). FMT_SMF.1: Management of security functions behaviour related to transmission of audit data to external IT entities is provided FMT_SMF.1. The TOE meets this SFR by enforcing that: - Only Security Administrators have right to configure audit servers where audit records are exported to. - Only Security Administrators have the privilege to choose the trusted channel for external audit server and decide whether transmit the audit data to an external IT entity or not. - Only Security Administrators have the privilege to modify the behaviour of TOE Security Functions (e.g., cryptographic algorithm, audit server). The TOE also offers the following functions, which are limited to the privileged level Network Administrator: - Restart the TOE. - configure the access banner. - configure the remote session inactivity time before session termination. - update the TOE, and to verify the updates using digital signature capability prior to installing those updates. - configure audit behaviour (e.g., changes to storage locations for audit; changes to behaviour when local audit storage space is full). - configure local audit behaviour (e.g., changes to storage locations for audit; changes to behaviour when local audit storage space is full, changes to local audit storage size). - configure the list of TOE-provided services available before an entity is identified and authenticated, as specified in FIA_UIA_EXT.1. - manage the cryptographic keys. - configure the cryptographic functionality. - configure thresholds for SSH rekeying. - configure the lifetime for IPsec SAs. - configure the list of supported (D)TLS ciphers. - configure the interaction between TOE components. - re-enable an Administrator account. - set the time which is used for time-stamps. - configure NTP. - configure the reference identifier for the peer. - manage the TOE's trust store and designate X509.v3 certificates as trust anchors. - administer the TOE locally. - configure the local session inactivity time before session termination or locking. - configure the authentication failure parameters for FIA_AFL.1. - manage the trusted public keys database. All of the above functions can be performed on the AC using the CLI. A default administrator account is configured during initial configuration where the password is set by the admin. The interaction of TOE components can be configured via the AC per FCO_CPC_EXT.1 and as described in section 8.8. FMT_SMR.2: The Target of Evaluation (TOE) provides an administrator role that corresponds to the security administrator role specified in the NDcPP. The administrator can use the Command Line Interface (CLI) to manage all aspects of the TOE locally or remotely. FMT_MTD.1/CryptoKeys: The TSF shall restrict the ability to manage the cryptographic keys to Security Administrators. Only Security Administrators have the capability to modify, delete, generate, and import the cryptographic keys and certificates. EPWLAN: FMT_SMR_EXT.1: The TOE cannot be administrated by a wireless client. EPWLAN: FMT_SMF.1/AccessSystem: Wireless security types supported include WPA3-Enterprise, WPA2-Enterprise, WPA3-SAE, and WPA2-PSK. WLAN clients can connect to the wireless network securely via 2.4 GHz, 5 GHz, or 6 GHz bands. If a client uses an unsupported security type to connect, it will fail. The Security management function is designed to satisfy the following security functional requirements: FMT_MOF.1/ManualUpdate, FMT_MTD.1/CoreData, FMT_MTD.1/CryptoKeys, FMT_SMF.1, FMT_SMR.1, FMT_SMR.2. ## 8.5 Protection of the TSF FPT_SKP_EXT.1: The TOE stores all pre-shared keys, symmetric keys, and private keys in the file system in Flash that can ' t be read, copy or extract by administrators; hence no interface access is available. Section 8.2 describes how the pre-shared keys, symmetric keys and private keys are stored. FPT_APW_EXT.1: The administrator's password is encrypted using SHA-512 and stored as irreversible ciphertext data. The plaintext password of the administrator cannot be obtained externally from the device. FPT_TST_EXT.1/ FPT_FLS.1: During start-up of the TOE, the TOE first checks the integrity of the firmware, and then runs a series of self-tests to ensure it is performing its cryptographic functions correctly. If any of these checks fails, the device will halt and require administrator intervention to successfully start-up. The following tests are performed: - ⚫ Cryptographic Module Known Answer Tests: - ◼ SHA (SHA256, SHA384, SHA512) - ◼ HMAC (HMAC_SHA256, HMAC_SHA384, HMAC_SHA512) - ◼ AES (AES-128-GCM, AES-192-GCM, AES-256-GCM) - ◼ RSA - ◼ ECDSA - ◼ RNG - ⚫ Bootloader Module - ◼ Firmware Integrity Test FPT_TUD_EXT.1: Security administrators can check the version of the installed firmware through the command line and manually initiate a firmware update. There are means to authenticate those updates to the TOE using a digital signature and prior to installing them. For AC, When the firmware version is updated 1. Use the display version command to verify the current firmware version. 2. Use the release notes for the firmware software version to evaluate the upgrade impact on your network and verify the following items: ¡ Software and hardware compatibility. ¡ Version and size of the upgrade firmware. ¡ Compatibility of the upgrade firmware with the current and startup firmware image. 3. Use the dir command to verify that the device has sufficient storage space for the upgrade images. If the storage space is not sufficient, delete unused files by using the delete /unreserved command. 4. Use SCP or SFTP to transfer the upgrade image file to the root directory of a file system. Use ' bootloader ' command to set files for next startup. At this point, the digital signature of the next boot file will be verified. If the digital signature verification fails, the TOE will not update the startup image and you will receive a verification failure message. If the digital signature verification success, users use ' display boot-loader ' to display current firmware images and next startup firmware images. Use ' reboot ' command to restart the device to update the version. For AP, use ' display wlan ap-model name ' command on AC to display current AP version. The AP's version needs to be transferred to the AC's apimge directory. When the AP connects to the AC, if the versions do not match, the AP will automatically download the version from the AC. If the AP's digital signature verification fails, the AP will not write the version to the local flash. If the AP's digital signature verification succeeds, the AP will write the version from memory to the flash and then automatically restart to update the version. The software images for the TOE are digitally signed for authenticity and integrity verification. This mechanism ensures that the firmware installed on the TOE is from a trusted source and has not been tampered with in the transfer, storage, or installation phase. The TOE software digital signature verification for authenticity and integrity in the following situations: · Before the TOE loads a software image during startup. If the digital signature verification fails, the TOE will not load the image and you will receive a verification failure message. · When you specify a software image to upgrade the device from the BootWare menu. If the digital signature verification fails, the TOE will not set the image for upgrade and you will receive a verification failure message. · Before the TOE loads a BootWare image to the Normal area of BootWare. If the digital signature verification fails, the TOE will not load the image and you will receive a verification failure message. · When you specify a firmware image as a startup image through the boot loader. The TOE will verify the digital signature of the image before it updates the startup image list with the specified image. If the digital signature verification fails, the TOE will not update the startup image and you will receive a verification failure message. · Before the TOE activates a feature or patch image. If the digital signature verification fails, the TOE will not activate the image and you will receive a digital signature failure message. s embedded OS manages the clock and exposes clock-related functions for use by the TOE. The TOE software can also be configured to utilize the NTP protocol to keep the local hardware-based real-time clock synchronized with other network devices. The communication between TOE and NTP server will be protected by IPsec security channel. AP FPT_STM.1, FPT_STM.2: The hardware of the TOE includes a hardware-based real-time clock. The TOE ' connects to AC and synchronizes time from AC to keep both devices' time consistent. FPT_ITT.1: The communication between the different parts of the TOE is protected with DTLS. The Protection of the TSF function is designed to satisfy the following security functional requirements: FPT_SKP_EXT.1, FPT_APW_EXT.1, FPT_TST_EXT.1, FPT_TUD_EXT.1, FPT_STM.1, FPT_STM.2, FPT_ITT.1, FPT_FLS.1. ## 8.6 TOE access FTA_SSL_EXT.1/ FTA_SSL.3: The TOE can be configured by an administrator (in the Network- admin role) to set an interactive session timeout value (any integer value in minutes and also optionally in seconds, with 0 disabling the timeout - the default timeout is 10 minutes). A session that is inactive (i.e., no commands issuing from the remote client) for the defined timeout value will be terminated, both for local and for remote sessions. The user will be required to re-enter their user id and their password so they can be re-authenticated in order to establish a new session. FTA_SSL.4: The user also has the ability to terminate his own sessions (log out). The TOE allows users to terminate their own local and remote CLI sessions by issuing the ' quit command. FTA_TAB.1: The TOE can be configured to display administrator-configured advisory banners that will be displayed in conjunction with user login prompts. The banner contents are configured by a user in the Network-admin role. When accessing the CLI locally via the console or remotely via SSH, this banner is displayed. The configuration information is consistent across all interfaces. It can be configured using the ' header ' command in the CLI. FTA_TSE.1: The TOE has a scheduler that allows to shut down the communication between TOE and wlan client based on time, day and specific access point. The TOE access function is designed to satisfy the following security functional requirements: FTA_SSL_EXT.1, FTA_SSL.3, FTA_SSL.4, FTA_TAB.1, FTA_TSE.1 ## 8.7 Trusted path/channels. FTP_TRP.1/Admin: To support secure remote administration, the TOE includes implementations of SSH. In each case, a remote host (presumably acting on behalf of an administrator) can initiate a secure remote connection for the purpose of security management. Note that only the local console is available by default and each of these remote administration services can be independently enabled by an administrator. FTP_ITC.1: The TOE uses the IPsec/IKEv2 protocol to establish trusted channels between the AC and the external authentication server, Audit server, 802.1x server, and NTP server. These IPsec channels are peer-to-peer connections whereby the TOE can act as either the server or the client. As indicated earlier, the TOE can be configured to export audit records to an external audit server. In order to protect exported audit records from disclosure or modification, the TOE can be configured to utilize an IPSEC secure channel for this purpose. This protection is initiated by the TOE whenever Audit connections are established for the purpose of exporting audit records. IPsec can protect hwtacase, RADIUS messages between AC and authentication servers, as well as 802.1x servers. The communication with NTP server and authentication server also protected by IPsec secure channel. All of the secure protocols are supported by the cryptographic operations provided by the FCS requirements in this Security Target. EPWLAN: FTP_ITC.1/Client: For wireless users operating in a Robust Security Network (RSN), WPA3-Enterprise, WPA2-Enterprise, WPA3-SAE and WPA2-PSK as defined by IEEE 802.11-2020 are used to provide a trusted channel between the TOE and WLAN clients. If the client attempts to use another security type to establish a connection, the authentication attempt will be rejected. ## 8.8 Communication FCO_CPC_EXT.1: After starting up with zero configurations, an AP automatically creates VLAN-interface 1 and enables the DHCP client, DHCPv6 client, and DNS features on the interface. Then it obtains its own IP address from the DHCP server and discovers ACs by using the following methods: · Static IP address. If AC IP addresses have been manually configured for the AP, the AP sends a unicast discovery request to each AC IP address to discover ACs. ####### · DHCP options. The AP obtains AC IPv4 addresses from Option 138, Option 43, and IPv6 addresses from Option 52 sent from the DHCP server. It uses these addresses in descending order. - DNS. - a. The AP obtains the domain name suffix from the DHCP server. - b. The AP adds the suffix to the host name. - c. The DNS server translates the domain name into IP addresses. ####### · Broadcast. The AP broadcasts discovery requests to IP address 255.255.255.255 to discover ACs. ####### · IPv4 multicast: The AP sends multicast discovery requests to IPv4 address 224.0.1.140 to discover ACs. · IPv6 multicast. The AP sends multicast discovery requests to IPv6 address FF0E::18C to discover ACs. The methods of static IP address, DHCPv4 options, broadcast/IPv4 multicast, IPv4 DNS, IPv6 multicast, DHCPv6 option, and IPv6 DNS are used in descending order. The AP does not stop AC discovery until it establishes a CAPWAP tunnel with one of the discovered ACs. The AP sends a discovery request to each AC to discover ACs. - Upon receiving a discovery request, an AC determines whether to send a discovery response by performing the following steps: - a. Identifies whether the discovery request is a unicast packet. - Unicast packet - The AC proceeds to step . - Broadcast or multicast packet - The AC proceeds to step if it is disabled with the feature of responding only to unicast discovery requests. If this feature is enabled, the AC does not send a discovery response. - b. Identifies whether it has manual AP configuration for the AP model specified in the discovery request. - If manual AP configuration exists, the AC sends a discovery response to the AP. The discovery response contains information about whether the AC has the manual configuration for the AP, the AP connection priority, and the AC's load status. - If no manual AP configuration exists, the AC does not send a discovery response. The Security Administrator must enable communications between the Remote Access Points and Controller components before any communication can take place. The security administrator must manually configure the AP template and set up tunnel encryption so that the AP can establish a connection with the AC. The AC's factory firmware includes a default certificate, which the AP can check to establish an initial DTLS and TLS tunnel (FPT_ITT.1) with the AC. The AC and AP can also be pre-configured with ECDSA or RSA certificates. The import and configure certificate function on the AP are only temporarily enabled for this purpose, which will also enforce the AP to use the pre-configured certificate in the connection, supporting more certificate security checks (FIA_X509_EXT.1.1/ITT). After the AP establishes a channel with the AC, the configuration function on the AP will be disabled. The security administrator can disable communication between the AP and the controller by deleting the AP template from the AC. The communication function is designed to satisfy the following security functional requirements: FCO_CPC_EXT.1. ### 9 Rationales ## 9.1 Security Objectives Rationale This rationale consists of a table mapping SFRs against security objectives. | Security Objectives | Security Functional Requirements | |----------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | O.ADMIN_AUTH | FMT_SMR.2, FMT_SMF.1, FMT_MTD.1/CoreData, FMT_MOF.1/Functions, FIA_UIA_EXT.1, FTA_TAB.1, FIA_UIA_EXT.1, FTA_SSL_EXT.1, FTA_SSL.3, FTA_SSL.4, FTP_TRP.1/Admin, FIA_AFL.1 | | O.STRONG_CRYPTO | FCS_CKM.1, FCS_CKM.2, FCS_CKM.3, FCS_COP.1/DataEncryption, FCS_COP.1/SigGen, FCS_COP.1/Hash, FCS_COP.1/KeyedHash, FCS_RBG.1, FCS_RBG.3,, FMT_SMF.1 | | O.TRUSTED_COMM | FTP_ITC.1, FTP_ITC.1/Client FTP_TRP.1/Admin, FPT_ITT.1, FCS_DTLSC_EXT.1, FCS_DTLSS_EXT.1, FCS_IPSEC_EXT.1, FCS_TLSC_EXT.1, FCS_TLSS_EXT.1, FCS_SSHS_EXT.1, FCS_SSH_EXT.1, FIA_X509_EXT.1, FIA_X509_EXT.2, FIA_X509_EXT.3 | | O.STRONG_AUTHENTICATION_ENDPOINT | FTP_ITC.1, FTP_TRP.1/Admin, FPT_ITT.1, FCO_CPC_EXT.1 | | O.SECURE_UPDATES | FPT_TUD_EXT.1, FMT_SMF.1, FMT_MOF.1/ManualUpdate | | O.ACTIVITY_AUDIT | FAU_GEN.1, FAU_GEN.2, FPT_STM.1, FPT_STM.2, FCS_NTP_EXT.1, FAU_STG.2, FAU_STG_EXT.1, FMT_MOF.1/Functions | | O.PASSWORD_PROTECTION | FPT_SKP_EXT.1, FCS_CKM.6, FMT_SMF.1, FMT_MTD.1/CryptoKeys, FIA_UAU.7, FIA_PMG_EXT.1, FPT_APW_EXT.1 | | O.SELF_TEST | FPT_TST_EXT.1 | | O.CRYPTOGRAPHIC_FUNCTIONS | FCS_COP.1/DataEncryption, FCS_CKM.1/WPA, FCS_CKM.2/GTK, FCS_CKM.2/PMK | | O.AUTHENTICATION | FCO_CPC_EXT.1, FIA_8021X_EXT.1, FIA_UAU.6, FTA_TSE.1 | | O.FAIL_SECURE | FPT_TST_EXT.1, FPT_FLS.1 | | O.SYSTEM_MONITORING | FAU_GEN.1/WLAN, FAU_GEN_EXT.1, FAU_STG_EXT.1 | | O.TOE_ADMINISTRATION | FMT_SMR_EXT.1, FMT_SMF.1/AccessSystem | | O.BANNER | FTA_TAB.1 | Below is the rationale for the security objectives mapping: ### 9.1.1 O.ADMIN_AUTH: - The Administrator role is defined in FMT_SMR.2 and the relevant administration capabilities are defined in FMT_SMF.1 and FMT_MTD.1/CoreData, with optional additional capabilities in FMT_MOF.1/Functions - The actions allowed before authentication of an Administrator are constrained by FIA_UIA_EXT.1, and include the advisory notice and consent warning message displayed according to FTA_TAB.1 - The requirement for the Administrator authentication process is described in FIA_UIA_EXT.1 - Locking of Administrator sessions is ensured by FTA_SSL_EXT.1 (for local sessions), FTA_SSL.3 (for remote sessions), and FTA_SSL.4 (for all interactive sessions) - The secure channel used for remote Administrator connections is specified in FTP_TRP.1/Admin - If the TOE provides remote administration using a password-based authentication mechanism, FIA_AFL.1 provides actions on reaching a threshold number of consecutive password failures. ### 9.1.2 O.STRONG_CRYPTO - Requirements for key generation and key distribution are set in FCS_CKM.1 and FCS_CKM.2 respectively - Requirements for Cryptographic key access in FCS_CKM.3 - Requirements for use of cryptographic schemes are set in FCS_COP.1/DataEncryption, FCS_COP.1/SigGen, FCS_COP.1/Hash, and FCS_COP.1/KeyedHash - Requirements for random bit generation to support key generation and secure protocols (see SFRs resulting from T.UNTRUSTED_COMMUNICATION_CHANNELS) are set in FCS_RBG.1, FCS_RBG.3. - Management of cryptographic functions is specified in FMT_SMF.1 ### 9.1.3 O.TRUSTED_COMM - The general use of secure protocols for identified communication channels is described at the top level in FTP_ITC.1, FTP_ITC.1/Client and FTP_TRP.1/Admin; for distributed TOEs the requirements for intercomponent communications are addressed by the requirements in FPT_ITT.1 - Requirements for the use of secure communication protocols are set for allowed protocols in FCS_DTLSC_EXT.1, FCS_DTLSS_EXT.1, FCS_IPSEC_EXT.1, FCS_TLSC_EXT.1, FCS_TLSS_EXT.1. - Requirements for the use of secure communication protocols implemented by the packages specified in Section 2.2 may be found in the respective package ' s document. FCS_SSHS_EXT.1, FCS_SSH_EXT.1. - Optional and selection-based requirements for use of public key certificates to support secure protocols are defined in FIA_X509_EXT.1, FIA_X509_EXT.2, FIA_X509_EXT.3 ### 9.1.4 O.STRONG_AUTHENTICATION_ENDPOINT - The use of appropriate secure protocols to provide authentication of endpoints (as in the SFRs addressing T.UNTRUSTED_COMMUNICATION_CHANNELS) are ensured by the requirements in FTP_ITC.1 and FTP_TRP.1/Admin; for distributed TOEs the authentication requirements for endpoints in intercomponent communications are addressed by the requirements in FPT_ITT.1 - Additional possible special cases of secure authentication during registration of distributed TOE components are addressed by FCO_CPC_EXT.1. ### 9.1.5 O.SECURE_UPDATES - Requirements for protection of updates are set in FPT_TUD_EXT.1 - Requirements for management of updates are defined in FMT_SMF.1 and (for manual updates) in FMT_MOF.1/ManualUpdate ### 9.1.6 O.ACTIVITY_AUDIT - Requirements for basic auditing capabilities are specified in FAU_GEN.1 and FAU_GEN.2, with timestamps provided according to FPT_STM.1, FPT_STM.2 and if applicable, protection of NTP channels in FCS_NTP_EXT.1. - Requirements for protecting audit records stored on the TOE are specified in FAU_STG.2. - Requirements for secure storage and transmission of local audit records to an external IT entity via a secure channel are specified in FAU_STG_EXT.1. - If (optionally) configuration of the audit functionality is provided by the TOE then this is specified in FMT_SMF.1 and confining this functionality to Security Administrators is required by FMT_MOF.1/Functions. ### 9.1.7 O.PASSWORD_PROTECTION - Protection of secret/private keys against compromise is specified in FPT_SKP_EXT.1 - Secure destruction of keys is specified in FCS_CKM.6 - If (optionally) management of keys is provided by the TOE then this is specified in FMT_SMF.1 and confining this functionality to Security Administrators is required by FMT_MTD.1/CryptoKeys - If optional local administration using a password-based authentication mechanism is provided by the TOE, FIA_UAU.7 provides protection of password entry by providing only obscured feedback at the local console. - If the TOE provides password-based authentication mechanisms, requirements for password lengths and available characters are set in FIA_PMG_EXT.1. Requirements for secure storage of passwords are set in FPT_APW_EXT.1 ### 9.1.8 O.SELF_TEST - Requirements for running self-test(s) are defined in FPT_TST_EXT.1 ### 9.1.9 O.CRYPTOGRAPHIC_FUNCTIONS - FCS_COP.1/DataEncryption supports the objective by requiring the TSF to implement AES in the modes needed to support its other functions. - · - FCS_CKM.1/WPA supports the objective by requiring the TSF to generate symmetric keys used for WPA2. - FCS_CKM.2/GTK supports the objective by requiring the TSF to distribute group temporal keys used for IEEE 802.11. - FCS_CKM.2/PMK supports the objective by requiring the TSF to distribute pairwise master keys used for IEEE 802.11. ### 9.1.10 O.AUTHENTICATION - FCO_CPC_EXT.1 supports the objective by requiring the TSF to implement a mechanism that authenticates its distributed components to each other. - FIA_8021X_EXT.1 supports the objective by requiring the TSF to act as the authenticator for 802.1X authentication. - FIA_UAU.6 supports the objective by requiring the TSF to re-authenticate a security administrator under certain circumstances. - FTA_TSE.1 supports the objective by requiring the TSF to deny the establishment of a wireless client session for reasons unrelated to the correctness of an authentication credential. ### 9.1.11 O.FAIL_ SECURE - FPT_TST_EXT.1 supports the objective by requiring the TSF to perform self-tests that may aid in the detection of a TSF failure. - FPT_FLS.1 supports the objective by requiring the TSF to preserve a secure state in the event of a self-test failure. ### 9.1.12 O.SYSTEM_MONITORING - FAU_GEN.1/WLAN supports the objective by requiring the TSF to generate audit records for securityrelevant WLAN behavior. - FAU_GEN_EXT.1 supports the objective by requiring the TSF to generate appropriate security-relevant auditable events on each of its distributed components. - FAU_STG_EXT.1 supports the objective by defining how distributed TOE components store their generated audit records. ### 9.1.13 O.TOE_ADMINISTRATION - FMT_SMR_EXT.1 supports the objective by requiring the TSF to prevent any administrative actions that originate from the 'external' network. - FMT_SMF.1/AccessSystem supports the objective by defining management functionality that is specific to WLAN AS devices. ### 9.1.14 O.BANNER - An advisory notice and consent warning message is required to be displayed by FTA_TAB.1 ## 9.2 SFRs to component of the TOE rationale This rationale consists of a table mapping SFRs to each of the components of the TOE. | SFR | TOE Component | |--------------------------|-------------------| | FAU_GEN.1 | All | | FAU_GEN.2 | All | | FAU_STG.2 | Access Controller | | FAU_STG_EXT.1 | All | | FAU_GEN_EXT.1 | ALL | | FAU_STG_EXT.4 | Access Controller | | FAU_STG_EXT.5 | Access Point | | FCS_CKM.1 | All | | FCS_CKM.2 | All | | FCS_CKM.3 | Access Controller | | FCS_CKM.6 | All | | FCS_COP.1/DataEncryption | All | | FCS_COP.1/SigGen | All | | FCS_COP.1/Hash | All | | FCS_COP.1/KeyedHash | All | | FIA_AFL.1 | Access Controller | | FIA_PMG_EXT.1 | Access Controller | | FIA_UIA_EXT.1 | Access Controller | | FIA_UAU.7 | Access Controller | | FMT_MOF.1/ManualUpdate | All | |--------------------------|-------------------| | FMT_MTD.1/CoreData | All | | FMT_SMF.1 | Access Controller | | FMT_SMR.2 | Access Controller | | FPT_SKP_EXT.1 | All | | FPT_APW_EXT.1 | Access Controller | | FPT_TST_EXT.1 | All | | FPT_TUD_EXT.1 | All | | FPT_STM.1 | ALL | | FPT_STM.2 | ALL | | FMT_MOF.1/Functions | Access Controller | | FTA_SSL_EXT.1 | Access Controller | | FTA_SSL.3 | Access Controller | | FTA_SSL.4 | Access Controller | | FTA_TAB.1 | Access Controller | | FTP_ITC.1 | Access Controller | | FTP_TRP.1/Admin | Access Controller | | FCS_IPSEC_EXT.1 | Access Controller | | FCS_NTP_EXT.1 | Access Controller | | FCS_SSHS_EXT.1 | Access Controller | | FCS_SSH_EXT.1 | Access Controller | | FCS_DTLSC_EXT.1 | Access Point | | FCS_DTLSS_EXT.1 | Access Controller | | FCS_TLSC_EXT.1 | Access Point | | FCS_TLSS_EXT.1 | Access Controller | | FCS_RBG.1 | All | | FCS_RBG.3 | All | | FIA_X509_EXT.1/ITT | All | | FIA_X509_EXT.1/Rev | Access Controller | | FIA_X509_EXT.2 | All | | FIA_X509_EXT.3 | Access Controller | | FCO_CPC_EXT.1 | ALL | | FMT_MTD.1/CryptoKeys | Access Controller | |------------------------|---------------------| | FPT_ITT.1 | All | | FAU_GEN.1.1/WLAN | ALL | | FMT_SMR_EXT.1 | ALL | | FTP_ITC.1/CLIENT | ALL | | FCS_CKM.1/WPA | Access Controller | | FCS_CKM.2/GTK | Access Controller | | FCS_CKM.2/PMK | Access Controller | | FIA_UAU.6 | Access Controller | | FMT_SMF.1/AccessSystem | Access Controller | | FIA_8021X_EXT.1 | Access Controller | | FPT_FLS.1 | All | | FTA_TSE.1 | ALL | ## 9.3 Dependency Rationale This rationale provided in [PP-ND] annex E.1 shows that all dependencies of all security requirements have been addressed. the parts of [PPND] that were changed relative to [CC2] have been replaced by the corresponding parts in [CC2], and ST has been updated based on the dependencies in [CC2]. According to Appendix D of [EPWLAN]: This PP-Module has no implicitly satisfied requirements. All SFR dependencies are explicitly met either through SFRs defined by the PP-Module or inherited from the Base-PP. The dependencies of FCS_SSH_EXT.1 are satisfied by the SFRs of the Base-PP [PP-ND] and the dependency of FCS_SSHS_EXT.1 are satisfied by the presence of FCS_SSH_EXT.1. ### 10 Abbreviations and glossary [CC] Common Criteria [EAL] Evaluation Assurance Level [ST] Security Target [TOE] Target of Evaluation [TSF] TOE Security Functionality [PP] Protection Profile [AGD] Guidance Documents ### 11 References [CC1] Common Criteria for Information Technology Security Evaluation. Part 1: Introduction and General Model, CC:2022, Revision 1, November 2022. [CC2] Common Criteria for Information Technology Security Evaluation. Part 2: Security functional components, CC:2022, Revision 1, November 2022. [CC3] Common Criteria for Information Technology Security Evaluation. Part 3: Security assurance components, CC:2022, Revision 1, November 2022. [CC4] Common Criteria for Information Technology Security Evaluation. Part 4: Framework for the specification of evaluation methods and activities, CC:2022, Revision 1, November 2022. [CC5] Common Criteria for Information Technology Security Evaluation. Part 5: Pre-defined packages of security requirements, CC:2022, Revision 1, November 2022. [CEM] Common Criteria for Information Technology Security Evaluation. Evaluation methodology, CEM:2022, Revision 1, November 2022. [PP-ND] Collaborative Protection Profile for Network Devices, v3.0e, 06-December-2023. [PPSSH] Functional Package for Secure Shell (SSH), v1.0, 2021-05-13. [EPWLAN] PP-Module for Wireless Local Area Network (WLAN) Access System, v1.0, 2022-03-31 [PP-CONFIG] PP-Configuration for Network Devices and Wireless Local Area Network Access Systems, v2.0, 2024-04-25.