Junos 24.4R2 for MX240/480/960 Routers and EX9204/9208/9214 Switches Security Target Document Version: 0.6 Document Date: June 18, 2026 2400 Research Blvd Suite 395 Rockville, MD 20850 HPE Juniper Networking, Junos 24.4R2 for MX240/480/960 Routers and EX9204/9208/9214 Switches Security Target 2 Revision History Version Date Changes Version 0.1 May 6, 2025 Initial Release Version 0.2 May 29, 2025 Added Flaw Remediation Version 0.3 June 16, 2025 Minor Fixes Version 0.4 August 27, 2025 QA Updates Version 0.5 March 17, 2026 Addressing comments Version 0.6 June 18, 2026 Updates as part of addressing ECR comments HPE Juniper Networking, Junos 24.4R2 for MX240/480/960 Routers and EX9204/9208/9214 Switches Security Target 3 Contents 1. Introduction..........................................................................................................................................................5 1.1 Security Target and TOE Reference............................................................................................................5 1.2 TOE Overview .............................................................................................................................................5 1.3 TOE Description ..........................................................................................................................................7 1.3.1 Physical Boundaries ...............................................................................................................................8 1.3.2 Security Functions Provided by the TOE..............................................................................................10 1.3.3 TOE Documentation.............................................................................................................................16 1.3.4 References ...........................................................................................................................................16 1.4 TOE Environment......................................................................................................................................17 1.5 Product Functionality not Included in the Scope of the Evaluation .........................................................17 2. Conformance Claims...........................................................................................................................................19 2.1 CC Conformance Claims............................................................................................................................19 2.2 Protection Profile Conformance...............................................................................................................19 2.3 Conformance Rationale............................................................................................................................19 2.3.1 Technical Decisions..............................................................................................................................19 3. Security Problem Definition................................................................................................................................23 3.1 Threats......................................................................................................................................................23 3.2 Assumptions .............................................................................................................................................25 3.3 Organizational Security Policies................................................................................................................27 4. Security Objectives .............................................................................................................................................28 4.1 Security Objectives for the TOE................................................................................................................28 4.2 Security Objectives for the Operational Environment .............................................................................29 5. Security Requirements........................................................................................................................................31 5.1 Conventions..............................................................................................................................................32 5.2 Security Functional Requirements............................................................................................................32 HPE Juniper Networking, Junos 24.4R2 for MX240/480/960 Routers and EX9204/9208/9214 Switches Security Target 4 5.2.1 Security Audit (FAU).............................................................................................................................33 5.2.2 Cryptographic Support (FCS)................................................................................................................36 5.2.3 Identification and Authentication (FIA) ...............................................................................................44 5.2.4 Security Management (FMT) ...............................................................................................................45 5.2.5 Protection of the TSF (FPT) ..................................................................................................................47 5.2.6 TOE Access (FTA)..................................................................................................................................49 5.2.7 Trusted Path/Channels (FTP) ...............................................................................................................49 5.3 TOE SFR Dependencies Rationale for SFRs ...............................................................................................50 5.4 Security Assurance Requirements............................................................................................................50 5.5 Assurance Measures.................................................................................................................................51 6. TOE Summary Specification................................................................................................................................53 6.1 CAVP Algorithm Certificate Details...........................................................................................................66 6.2 Cryptographic Key Destruction.................................................................................................................69 7. Acronym Table....................................................................................................................................................72 HPE Juniper Networking, Junos 24.4R2 for MX240/480/960 Routers and EX9204/9208/9214 Switches Security Target 5 1. INTRODUCTION The Security Target (ST) serves as the basis for the Common Criteria (CC) evaluation and identifies the Target of Evaluation (TOE), the scope of the evaluation, and the assumptions made throughout. This document will also describe the intended operational environment of the TOE, and the functional and assurance requirements that the TOE meets. 1.1 SECURITY TARGET AND TOE REFERENCE This section provides the information needed to identify and control the TOE and the ST. Table 1 – TOE/ST Identification Category Identifier ST Title Junos 24.4R2 for MX240/480/960 Routers and EX9204/9208/9214 Switches Security Target ST Version 0.6 ST Date June 18, 2026 ST Author Acumen Security, LLC. TOE Identifier Junos 24.4R2 for MX240/480/960 Routers and EX9204/9208/9214 Switches TOE Version 24.4R2 TOE Developer HPE Juniper Networking Key Words Network Device 1.2 TOE OVERVIEW The TOE is HPE Juniper Networking Junos 24.4R2 for MX240/480/960 Routers and EX9204/9208/9214 Switches with MACsec on the MPC10E/EX9200/MPC3E Series Line Cards. The following appliance models constitute the variations of the TOE: Model Routing Engine (RE) RE-CPU MACsec Line card MIC-3D-10GE-SFP-E within MPC3E-3D-NG MX240 RE-S-X6-128G RE-S-X6-64G HASWELL-EP, Intel Xeon E5- 2608L V3 MPC10E-10C and MPC10E-15C, with JNPR Penta Silicon MACsec ASIC BCM82756 MACsec ASIC with CAVP num AES4550 MX480 MX960 EX9204 EX9200-RE2 Not supported EX9208 HPE Juniper Networking, Junos 24.4R2 for MX240/480/960 Routers and EX9204/9208/9214 Switches Security Target 6 EX9214 HASWELL-EP, Intel Xeon E5- 2608L V3 EX9200-15C with JNPR Penta Silicon MACsec ASIC Note that the RE-S-X6 and EX9200-RE2 routing engines have identical hardware and are simply marketed with different names. The TOE is a secure network device that protects itself largely by offering only a minimal logical interface to the network and attached nodes. It includes the Junos OS firmware, JUNOS OS 24.4R2, which is a special purpose OS offering no general-purpose computing capabilities. Junos OS implements both management and control functions as well as all IP routing. All of the appliance’s primary functions are to support the definition and enforcement of information flow policies among network nodes. Each information flows from one network node to other passes through an instance of the TOE. Information flow is controlled based on network node addresses and protocol. The TOE also ensure that security-relevant activity is audited and implements the necessary tools to manage all security functions. The TOE implements a variety of high-speed interfaces (only Ethernet is in the scope of the evaluation) for enterprise branch, campus, and data center networks. The appliances are physically self-contained, housing the firmware and hardware necessary to perform all routing functions. The architecture components of the MX240, MX480, and MX960 are: • Modular Control Plane: The platforms utilize a redundant Routing Engine (RE) for the control plane, with available models including the RE-S-X6-64G and RE-S-X6-128G, both featuring a 6-core 2.0 GHz CPU with 64 GB and 128 GB of memory, respectively. • Unified Operating System: The architecture runs on the modular Junos OS, which provides routing, switching, security, and service features, as well as supporting automation tools and telemetry. • Programmable Forwarding: At the core of the hardware is the programmable Trio chipset, which enables wire-rate forwarding, service agility, and allows for the implementation of inline services and telemetry. • Inline MACsec Technology: The platforms support robust data plane security through features like integrated Layer 2 MACsec, with line cards such as the MPC-10E providing inline AES-256 MACsec line- side encryption. The architecture components of the EX9204, EX9208, EX9214 are: • Modular Chassis Design: The EX9204 (4-slot), EX9208 (8-slot), and EX9214 (14-slot) are modular chassis that share a common set of line cards, Routing Engines, and Switch Fabric modules. • Centralized Control Plane: The architecture is built for high availability with support for redundant EX9200-RE2 Routing Engines. The RE2 features a six-core, 2 GHz Intel processor with 64 GB of DRAM to run the Junos OS and manage all control plane functions. HPE Juniper Networking, Junos 24.4R2 for MX240/480/960 Routers and EX9204/9208/9214 Switches Security Target 7 • Programmable Forwarding ASIC: The platforms are based on "Juniper One," a custom-designed ASIC that provides a programmable Packet Forwarding Engine (PFE), allowing new networking protocols and features to be added via software updates. • High-Density Cryptographic-Capable Line Cards: The chassis support various line cards, including the EX9200-15C, which provides 15 ports of 100GbE/40GbE with Media Access Control Security (MACsec) capability, each of which can house 10-gigabit small form-factor pluggable plus (SFP+) transceivers and includes hardware support for cryptographic functions. • Integrated MACsec Technology: These cryptographic capabilities are exposed via MACsec technology (IEEE 802.1ae) with AES-256-bit encryption, supported online cards like the EX9200-15C to provide link- layer data confidentiality, integrity, and authentication. • Secure OS and Logging: The EX9200-RE2 runs the carrier-class Junos OS, which stores its images and system logs on dual 64 GB SSDs. For secure management, the OS provides secure access protocols, including SSHv2. • Separated Management and Control: The EX9200-RE2 modules communicate with the line cards over a dedicated internal out-of-band Gigabit Ethernet control interface, separating management traffic from the data plane. The appliance supports numerous routing and switching standards for flexibility and scalability. Juniper’s Virtual Chassis technology allows multiple interconnected switches to operate as a single, logical unit, enabling users to manage all platforms as one virtual device. The functions of the appliances can all be managed through the Junos firmware, either from a connected terminal console or via a network connection. Network management is secured using the SSH protocol. All management, whether from a user connecting to a terminal or from the network, requires successful authentication. In the evaluated deployment the TOE is managed and configured via Command Line Interface, either via a directly connected console or over the network secured using the SSH protocol. The TOE implements MACsec between adjacent devices. All traffic communicated between the devices including frames for LLDP (Link Layer Discovery Protocol), DHCP (Dynamic Host Configuration Protocol), ARP (Address Resolution Protocol), STP (Spanning Tree Protocol), Ethernet Control frames, etc. (the exceptions to this protection are Destination MAC and Source MAC addresses in MACsec and MKA frames). MACsec can be deployed in point-to-point mode or shared mode with multiple stations. In the evaluated configuration MACsec must be configured individually on each point-to-point Ethernet link, such that a pair of MACsec devices (connected by a physical medium) protect Ethernet frames switched or routed from one device to the other. The two MACsec devices are provided with a Connectivity Association Key (CAK) and utilize the MACsec Key Agreement (MKA) protocol to create a secure tunnel. MKA is used by the two MACsec devices to agree upon MACsec keys. MACsec must be configured to protect all traffic between the devices, with the exception of the MKA or Ethernet control traffic such as EAP over LAN (EAPOL) frames. The devices will first exchange MKA frames, which serve to determine if the peer is an authorized peer and agree upon a shared key and MACsec cipher suite used to set up a transmit (Tx) Security Association (SA) and a receive (Rx) SA. Once the SAs are set up, MACsec- protected frames traverse the unprotected link. 1.3 TOE DESCRIPTION HPE Juniper Networking, Junos 24.4R2 for MX240/480/960 Routers and EX9204/9208/9214 Switches Security Target 8 This section provides an overview of the TOE architecture, including physical boundaries, security functions, and relevant TOE documentation and references. Figure 1 – Representative TOE Deployment 1.3.1 PHYSICAL BOUNDARIES The TOE is a hardware appliance which is comprised of hardware components running on JUNOS-OS software. The boundaries are illustrated in Figure 2 – TOE Boundaries. HPE Juniper Networking, Junos 24.4R2 for MX240/480/960 Routers and EX9204/9208/9214 Switches Security Target 9 Figure 2 – TOE Boundaries The physical boundary of the TOE is the entire chassis of the appliance. The TOE interfaces are comprised of the network interfaces which pass traffic, and the management interface which handle administrative actions. Table 2 – TOE Physical Boundary Components Component Required Purpose/Description Hardware – Switch fabric Yes The switch fabric boards/modules provide a highly scalable, non-blocking, centralized switch fabric matrix through which all network data passes. Routing Engine (Control Board) Yes The Routing Engine (RE) runs the Junos firmware and implements Layer 3 routing services and Layer 2 switching services. The RE also implements the management functions for configuration and operation of the TOE and controls the flow of information through the TOE, including support for appliance interface control and control plane functions such HPE Juniper Networking, Junos 24.4R2 for MX240/480/960 Routers and EX9204/9208/9214 Switches Security Target 10 Component Required Purpose/Description as chassis component, system management and user access to the appliance. Packet Forwarding Engine (PFE) Yes The PFE implements all operations necessary for transit packet forwarding. The PFE implements an extensive set of Layer 2 and Layer 3 services that can be deployed in any combination of L2- L3 applications. The RE and PFE perform their primary tasks independently, while constantly communicating through a high-speed internal link. This arrangement provides streamlined forwarding and routing control and the capability to run Internet-scale networks at high speeds. 1.3.2 SECURITY FUNCTIONS PROVIDED BY THE TOE The TOE provides the security functions required by the Collaborative Protection Profile for Network Devices, hereafter referred to as NDcPP v3.0e or NDcPP. The TOE also provides the security functions required by the Functional Package for SSH, hereafter referred to as PKG_SSH_V1.0 and the PP-Module for MACsec Ethernet Encryption, Version 1.0, hereafter referred to as MOD_MACsec_V1.0. Each of these security functionalities are listed in more detail in the sections below. 1.3.2.1 SECURITY AUDIT The TOE generates audit events for all start-up and shutdown functions as well as all auditable events specified in Table 12 – Security Functional Requirements and Auditable Events and Table 13 – Security Functional Requirements and Auditable Events/MACsec. Auditable events are stored in the syslog files on the appliance and can be sent to an external log server (via Netconf over SSH). Auditable events include start-up and shutdown of the audit functions, authentication events, and all SFR-specific events required by the applicable Protection Profiles, Packages and Modules. Audit records include the date and time, event category, event type, username, and the outcome of the event (success or failure). Local syslog storage limits are configurable and are monitored. If the storage limit is reached the oldest logs will be overwritten. 1.3.2.2 CRYPTOGRAPHIC SUPPORT The TOE implements an SSH server to support protected communications for administrators to establish secure sessions and to connect to external syslog servers. The TOE requires that applications exchanging information with it are successfully authenticated prior to any exchange (i.e. applications connecting over SSH). Layer 2 communication over point-to-point Ethernet links between the TOE and compliant peers can be secured using MACsec. The TOE includes cryptographic modules that implement the underlying cryptographic services, including key management and protection of stored keys, algorithms, random bit generation and crypto administration. The cryptographic modules provide confidentiality and integrity services for authentication and for protecting communications with connecting applications. Details on cryptographic implementations by the TOE are mentioned in the Table 3 – TOE Cryptography Implementation. HPE Juniper Networking, Junos 24.4R2 for MX240/480/960 Routers and EX9204/9208/9214 Switches Security Target 11 Table 3 – TOE Cryptography Implementation Cryptographic Methods Usage FCS_CKM.1 Cryptographic Key Generation • Cryptographic key generation conforming to FIPS PUB 186-5 “Digital Signature Standard (DSS)”, Appendix A.1. o RSA: Key sizes supported are 2048, 3072 and 4096 bits. • Cryptographic key generation conforming to FIPS PUB 186-5 “Digital Signature Standard (DSS)”, Appendix A.2. o Elliptic NIST curves supported are: P-256, P-384, and P-521. FCS_CKM.2 Cryptographic Key Establishment • 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”; FCS_CKM.4 Cryptographic Key Destruction • Refer to Table 18 – Zeroization of Keys and CSP for Key Zeroization details. FCS_COP.1/DataEncryption Cryptographic Operations (AES Data Encryption/Decryption) • AES encryption and decryption conforming with ISO 18033-3. • AES key size supported is 128 and 256 bits • AES mode supported is CBC, CTR and GCM as specified in ISO 10116, ISO 10116 and ISO 19772 respectively. FCS_COP.1/SigGen Cryptographic Operation (Signature Generation and Verification) • RSA digital signature algorithm conforming to FIPS PUB 186-5, “Digital Signature Standard (DSS)”, Section 5.4, using PKCS #1 v2.2 Signature Schemes RSASSA-PSS and/or RSASSA-PKCS1v1_5; ISO/IEC 9796-2, Digital signature scheme 2 or Digital Signature scheme 3. o RSA key sizes supported are: 2048, 3072 and 4096 bits. • Elliptical curve digital signature algorithm conforming to FIPS PUB 186-5, “Digital Signature Standard (DSS)”, Section 6 and NIST SP 800-186 Section 3.2.1, Implementing NIST curves ISO/IEC 14888-3, Section 6.6. o Elliptical curve key sizes supported are 256 bits, 384 and 521 bits. FCS_COP.1/Hash Cryptographic Operations (Hash Algorithm) • Cryptographic hashing services conforming to ISO/IEC 10118-3:2004. • Hashing algorithms supported are SHA-1, SHA- 256, SHA-384, and SHA-512. • Message digest sizes supported are: 160, 256, 384, and 512 bits. HPE Juniper Networking, Junos 24.4R2 for MX240/480/960 Routers and EX9204/9208/9214 Switches Security Target 12 Cryptographic Methods Usage FCS_COP.1/KeyedHash Cryptographic Operation (Keyed Hash Algorithm) • Keyed-hash message authentication conforming to ISO/IEC 9797-2:2011, Section 7 “MAC Algorithm2”. • Keyed hash algorithm supported are: HMAC-SHA- 256, and HMAC-SHA-512 • Key sizes supported are: 256 and 512 bits. • Message digest sizes supported are: 256, and 512 bits. FCS_COP.1/CMAC Cryptographic Operation (AES- CMAC Keyed Hash Algorithm) • Keyed-hash message authentication as per NIST SP 800-38B standard • Algorithm: AES-CMAC • Key Sizes: 128, 256 bits • Digest Size: 128 bits FCS_COP.1 Cryptographic Operation (MACsec AES Data Encryption/Decryption) • Key Wrap: o Algorithm: AES Key Wrap o Standard: NIST SP 800-38F o Key Sizes: 128, 256 bits • Data Encryption/Decryption: o Algorithm: AES in Galois/Counter Mode (GCM) o Standard: ISO 19772 o Key Sizes: 128, 256 bits FCS_RBG_EXT.1 Random Bit Generation • Deterministic Random Bit Generation: o Standard: ISO/IEC 18031:2011 o Algorithm: HMAC_DRBG o Hash Functions: SHA-512 • Entropy Source: o Type: Software-based noise source o Minimum Entropy: 256 bits o Entropy Strength: At least equal to the greatest security strength of generated keys and hashes (as per ISO/IEC 18031:2011 Table C.1) FCS_SSHS_EXT.1 SSH Server Protocol • The TOE supports SSH v2 protocol compliant to the following RFCs: RFCs 4251, 4252, 4253, 4254, 4256, 4344, 5647, 5656, 6668, 8308 and 8332. • The TOE supports password-based, keyboard- interactive and public-key-based authentication. • SSH public-key authentication uses ssh-rsa (RFC 4253), rsa-sha2-256 (RFC 8332), rsa-sha2-512 (RFC 8332), ecdsa-sha2-nistp256 (RFC 5656), ecdsa-sha2-nistp384 (RFC 5656), ecdsa-sha2- nistp521 (RFC 5656), HPE Juniper Networking, Junos 24.4R2 for MX240/480/960 Routers and EX9204/9208/9214 Switches Security Target 13 Cryptographic Methods Usage • SSH transport uses the following encryption algorithms: aes128-ctr (RFC 4344), aes256-ctr (RFC 4344), aes128-cbc (RFC 4253), aes256-cbc (RFC 4253), aes128-gcm@openssh.com (RFC 5647) and aes256-gcm@openssh.com (RFC 5647). • Packets greater than 256K bytes in an SSH transport connection are dropped. • SSH transport uses the following data integrity MAC algorithms: hmac-sha2-256 (RFC 6668), and hmac-sha2-512 (RFC 6668). • Key exchange algorithms supported are: ecdh- sha2-nistp256 (RFC 5656), ecdh-sha2-nistp384 (RFC 5656) and ecdh-sha2-nistp512 (RFC 5656). • The TOE ensures that during SSH connections, the same session keys are used for a threshold of no longer than one hour and no more than one gigabyte of transmitted data. FCS_MACSEC_EXT.1 MACsec • MACsec Implementation: o Standard: IEEE 802.1AE-2018 • Secure Channel Identifier (SCI): o Derivation: From peer's MAC address and port o Validation: Reject MPDUs with incorrect SCI during a session • Permitted EtherTypes: o EAPOL (88-8E) o MACsec frames (88-E5) o MAC control frames (88-08) FCS_MACSEC_EXT.2 MACsec Integrity and Confidentiality • MACsec Implementation: o Integrity Protection: Supported o Confidentiality Offset: 0, 30, 50 • Integrity Check Value (ICV): o Derivation: Using the Secure Association Key (SAK) o Size: 8-16 octets o Protection: Destination/Source MAC addresses and all MPDU fields • Integrity Check Value Key (ICK): o Derivation: From Connectivity Association Key (CAK) using a Key Derivation Function (KDF) HPE Juniper Networking, Junos 24.4R2 for MX240/480/960 Routers and EX9204/9208/9214 Switches Security Target 14 Cryptographic Methods Usage FCS_MACSEC_EXT.3 MACsec Randomness • Secure Association Key (SAK) Generation: o Method: Key derivation from Connectivity Association Key (CAK) per IEEE 802.1X-2020 section 9.8.1 o Uniqueness Probability: No less than 1 in 2 powers of the generated key size • SAK Nonce Generation: o Source: TOE's random bit generator (as specified by FCS_RBG_EXT.1) FCS_MACSEC_EXT.4 MACsec Key Usage • Peer Authentication: o Method: Pre-shared keys (PSKs) [no other method] • SAK Distribution: o Method: AES key wrap • CAK Lifetime: o Support: Specifiable lifetime • Connectivity Association Key Names (CKNs): o Association: With SAKs, defined by KDF using CAK as input data (per IEEE 802.1X- 2020, Section 9.8.1) • Association: With CAKs o Length: 1-32 octets FCS_MKA_EXT.1 MACsec Key Agreement • Key Agreement Protocol (MKA): o Standard: IEEE 802.1X-2020 and 802.1Xbx-2014 • MKPDU Integrity: o Protection: Using ICV derived from ICK o ICK Derivation: From CAK using a KDF • MKA Timeouts: o Lifetime Timeout: 6.0 seconds o Hello timeout: 2.0 seconds • SAK Refresh/Distribution (Key Server): o Refresh: On expiration o Distribution: By pre-shared key (PSK) pairwise CAKs o Distribution: Fresh SAK on member addition/removal • MKPDU Validation: HPE Juniper Networking, Junos 24.4R2 for MX240/480/960 Routers and EX9204/9208/9214 Switches Security Target 15 Cryptographic Methods Usage o Standard: IEEE 802.1X-2020 Section 11.11.2 o Discard Conditions: ▪ Individual destination address ▪ Length < 32 octets ▪ Length < (Basic Parameter Set body length + 16 octets ICV) ▪ Unrecognized CAK Name • MKPDU Processing (Post-Validation): o Algorithm Agility Parameter: ▪ Implemented Algorithm: ICV verification per IEEE 802.1X- 2020 Section 9.4.1 ▪ Unrecognized/Unimplemented Algorithm: Discard MKPDU o Decoding: Per IEEE 802.1X-2020 Section 11.11.4 (for validated and verified MKPDUs) 1.3.2.3 IDENTIFICATION AND AUTHENTICATION The TOE supports Role Based Access Control. All users must be authenticated to the TOE prior to being granted access to any management actions. The TOE supports password-based authentication and public key based authentication. Based on the assigned role, a user is granted a set of privileges to access the system. Administrative users must provide unique identification and authentication data before any administrative access to the system is granted. Authentication data entered and stored on the TOE is protected. 1.3.2.4 SECURITY MANAGEMENT The TOE provides a Security Administrator role that is responsible for: • 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 • Ability to start and stop services • Ability to configure local audit behaviour • Ability to modify the behaviour of the transmission of audit data to an external IT entity • Ability to manage the cryptographic keys • Ability to configure the cryptographic functionality • Ability to configure thresholds for SSH rekeying • Ability to re-enable an Administrator account HPE Juniper Networking, Junos 24.4R2 for MX240/480/960 Routers and EX9204/9208/9214 Switches Security Target 16 • Ability to configure the local session inactivity time before session termination or locking • Ability to configure the authentication failure parameters for FIA_AFL.1 • Ability to set the time which is used for timestamps • Ability to configure NTP • Ability to administer the TOE locally • Ability to manage the trusted public keys database • Ability to manage a PSK-based CAK and install it in the device • Ability to manage the Key Server to create, delete, and activate MKA participants using the CLI commands • Ability to specify the lifetime of a CAK • Ability to enable, disable, or delete a PSK-based CAK using CLI commands The devices are managed through a Command Line Interface (CLI). The CLI is accessible through local (serial) console connection or remote administrative (SSH) session. 1.3.2.5 PROTECTION OF THE TSF The TOE protects all passwords, pre-shared keys, symmetric keys and private keys from unauthorized disclosure. Passwords are stored using sha256 or sha512. The TOE executes self-tests during initial start-up to ensure correct operation and enforcement of its security functions. An administrator can install software updates to the TOE. The TOE allows manual setting of time by the administrator and is also capable of syncing time to an NTP server. 1.3.2.6 TOE ACCESS The TOE displays a customizable banner before any administrative session can be established with it. The TOE will terminate local or remote interactive sessions after a specified period of session inactivity configured by an administrator. An administrator can terminate their own interactive local or remote sessions. 1.3.2.7 TRUSTED PATH/CHANNELS The TOE supports SSHv2 for secure communications with authorized IT entities such as syslog servers. The TOE supports SSHv2 (remote CLI) for secure remote administration. The TOE also supports MACsec for securing data at Layer 2 between TOE and MACsec supporting peer device. 1.3.3 TOE DOCUMENTATION The following documents are essential to understanding and controlling the TOE in the evaluated configuration: • Junos OS Common Criteria Evaluated Configuration Guide for MX240, MX480, MX960, EX9204, EX9208, EX9214 Devices, Published 2025-12-04 1.3.4 REFERENCES HPE Juniper Networking, Junos 24.4R2 for MX240/480/960 Routers and EX9204/9208/9214 Switches Security Target 17 In addition to TOE documentation, the following reference may also be valuable when understanding and controlling the TOE: • collaborative Protection Profile for Network Devices, Version 3.0e, 06 December 2023 [CPP_ND_V3.0E] • Functional Package for SSH, Version 1.0, 14 May 2021 [PKG_SSH_v1.0] • PP-Module for MACsec Ethernet Encryption [MOD_MACsec V1.0] 1.4 TOE ENVIRONMENT Figure 3 – TOE Environment The following environmental components are required to operate the TOE in the evaluated configuration: Table 4 – Required Environmental Components Components Description Local Management Console Any management workstation (computer) that is directly (serially) connected to the TOE’s console port may be used by the TOE administrator for local administration of the TOE. Remote Management Workstation Any management workstation (computer) with a SSHv2 client installed that may be used by the TOE administrator for remote administration of the TOE through SSH protected channel. Syslog Server A syslog server, used for remote storage of audit records that have been generated by and transmitted from the TOE securely using SSH tunnel (SSHv2). NTP Server A NTPv4 server, used to provide reliable timestamps to the TOE. MACsec Peer A MACsec Peer, used for establishing MACsec communication for securing Layer 2 data using MACsec functionality. 1.5 PRODUCT FUNCTIONALITY NOT INCLUDED IN THE SCOPE OF THE EVALUATION HPE Juniper Networking, Junos 24.4R2 for MX240/480/960 Routers and EX9204/9208/9214 Switches Security Target 18 The following product functionality is not included in the CC evaluation: • Use of telnet, since it violates the Trusted Path requirement set • Use of FTP, since it violates the Trusted Path requirement set • Use of SNMP, since it violates the Trusted Path requirement set • Use of SSL, including management via J-Web, JUNOScript and JUNOScope, since it violates the Trusted Path requirement set • Use of CLI account super-user and linux root account. HPE Juniper Networking, Junos 24.4R2 for MX240/480/960 Routers and EX9204/9208/9214 Switches Security Target 19 2. CONFORMANCE CLAIMS This section identifies the TOE conformance claims, conformance rationale, and relevant Technical Decisions (TDs). 2.1 CC CONFORMANCE CLAIMS The TOE is conformant to the following: • Common Criteria for Information Technology Security Evaluations Part 1, Version 3.1, Revision 5, April 2017 • Common Criteria for Information Technology Security Evaluations Part 2, Version 3.1, Revision 5, April 2017 (Extended) • Common Criteria for Information Technology Security Evaluations Part 3, Version 3.1, Revision 5, April 2017 (Conformant) 2.2 PROTECTION PROFILE CONFORMANCE This ST claims exact conformance to the following: • PP-Configuration for Network Devices and MACsec Ethernet Encryption, Version 2.0 (CFG_NDcPP- MACsec_V2.0) This PP-Configuration includes the following: • Collaborative Protection Profile for Network Devices, Version 3.0e (CPP_ND_V3.0E) • PP-Module for MACsec Ethernet Encryption, Version 1.0 (MOD_MACsec_V1.0) This ST also claims exact conformance to the following package: • Functional Package for SSH Version 1.0 [PKG_SSH_V1.0] 2.3 CONFORMANCE RATIONALE This ST provides exact conformance to the items listed in the previous section. The security problem definition, security objectives, and security requirements in this ST are all taken from the Protection Profile (PP), MACsec module and Functional Package for SSH, performing only the operations defined there. 2.3.1 TECHNICAL DECISIONS All NIAP TDs issued to date and applicable to NDcPP_v3.0e, PKG_SSH_v1.0 and MOD_MACsec_v1.0 have been considered. Table 5 identifies all applicable TDs. Table 5 – Relevant Technical Decisions Technical Decision Applicable (Y/N) Applicable cPP/MOD/PKG Exclusion Rationale (if applicable) TD1033 - Sunset Dates for NDcPP Configurations Y NDcPP_v3.0e N/A HPE Juniper Networking, Junos 24.4R2 for MX240/480/960 Routers and EX9204/9208/9214 Switches Security Target 20 Technical Decision Applicable (Y/N) Applicable cPP/MOD/PKG Exclusion Rationale (if applicable) TD0990 – NIT Technical Decision: CTR_DRBG in FCS_RBG_EXT.1.2 Y NDcPP_v3.0e N/A TD0973 – NIT Technical Decision: FCS_(D)TLSS_EXT.1.3 Test 2 DHE Ciphersuite Conditionality N NDcPP_v3.0e (D)TLS is not claimed by the ST. TD0923 - NIT Technical Decision: Auditable event for FAU_STG_EXT.1 in FAU_GEN.1.2 Y NDcPP_v3.0e N/A TD0921 - NIT Technical Decision: Addition of FIPS PUB 186-5 and Correction of Assignment Y NDcPP_v3.0e N/A TD0900 - NIT Technical Decision: Clarification to Local Administrator Access in FIA_UIA_EXT.1.3 Y NDcPP_v3.0e N/A TD0899 - NIT Technical Decision: Correction of Renegotiation Test for TLS 1.2 N NDcPP_v3.0e TLS is not claimed by the TOE for this evaluation. TD0886 - Clarification to FAU_STG_EXT.1 Test 6 Y NDcPP_v3.0e N/A TD0880 - NIT Decision: Removal of Duplicate Selection in FMT_SMF.1.1 Y NDcPP_v3.0e N/A TD0879 - NIT Decision: Correction of Chapter Headings in CPP_ND_V3.0E Y NDcPP_v3.0e N/A TD0868 - NIT Technical Decision: Clarification of time frames in FCS_IPSEC_EXT.1.7 and FCS_IPSEC_EXT.1.8 N NDcPP_v3.0e IPSec is not claimed by the TOE for this evaluation. TD0836 - NIT Technical Decision: Redundant Requirements in FPT_TST_EXT.1 Y NDcPP_v3.0e N/A TD1030 - Correction to FCS_MAC_EXT.2 TSS Activity When FPT_RPL_EXT.1 is Claimed Y MOD_MACsec_v1.0 N/A TD0939 - Updated Conformance Claims for MOD_MACSEC Y MOD_MACsec_v1.0 N/A TD0891 - Correlation of Implicitly Satisfied Requirements when CPP_ND_V3.0E is the Base-PP Y MOD_MACsec_v1.0 N/A HPE Juniper Networking, Junos 24.4R2 for MX240/480/960 Routers and EX9204/9208/9214 Switches Security Target 21 Technical Decision Applicable (Y/N) Applicable cPP/MOD/PKG Exclusion Rationale (if applicable) TD0889 - Correction For Tests Incorrectly Requiring Group MACsec Y MOD_MACsec_v1.0 N/A TD0884 - Expansion of Permitted EtherTypes in FCS_MACSEC_EXT.1.4 Y MOD_MACsec_v1.0 N/A TD0882 - MACsec Data Delay Protection, Key Agreement, and Conditional Support for Group CAK Y MOD_MACsec_v1.0 N/A TD0881 - Correction to MN Usage for FPT_RPL.1 Test Y MOD_MACsec_v1.0 N/A TD0870 - Security Objectives Rationale for MOD_MACSEC_V1.0 Y MOD_MACsec_v1.0 N/A TD0840 - Alignment of Test 22.1 to FMT_SMF.1/MACSEC Y MOD_MACsec_v1.0 N/A TD0826 - Aligning MOD_MACSEC_V1.0 with CPP_ND_V3.0E Y MOD_MACsec_v1.0 N/A TD0825 - Correction to IEEE 802.1X Reference Y MOD_MACsec_v1.0 N/A TD0816 - Clarity for MACsec Self- Test Failure Response Y MOD_MACsec_v1.0 N/A TD0803 - Clarification for Configurable MACsec CKN Length Y MOD_MACsec_v1.0 N/A TD0746 - Correction to FPT_RPL.1 Test 25 Y MOD_MACsec_v1.0 N/A TD0728 - Corrections to MACSec PP-Module SD Y MOD_MACsec_v1.0 N/A TD1023 - Clarifications to FCS_SSH_EXT.1.5 When aes256- gcm@openssh.com Is Selected Y PKG_SSH_v1.0 N/A TD1015 - Addition of ECD to PKG_SSH_V1.0 Y PKG_SSH_v1.0 N/A TD0967 - Allowance of Kex-strict in PKG_SSH_V1.0 Y PKG_SSH_v1.0 N/A TD0909 - Updates to FCS_SSH_EXT.1.1 App Note in SSH FP 1.0 Y PKG_SSH_v1.0 N/A HPE Juniper Networking, Junos 24.4R2 for MX240/480/960 Routers and EX9204/9208/9214 Switches Security Target 22 Technical Decision Applicable (Y/N) Applicable cPP/MOD/PKG Exclusion Rationale (if applicable) TD0777 - Clarification to Selections for Auditable Events for FCS_SSH_EXT.1 Y PKG_SSH_v1.0 N/A TD0732 - FCS_SSHS_EXT.1.3 Test 2 Update Y PKG_SSH_v1.0 N/A TD0695 - Choice of 128- or 256-bit size in AES-CTR in SSH Functional Package. Y PKG_SSH_v1.0 N/A TD0682 - Addressing Ambiguity in FCS_SSHS_EXT.1 Tests Y PKG_SSH_v1.0 N/A HPE Juniper Networking, Junos 24.4R2 for MX240/480/960 Routers and EX9204/9208/9214 Switches Security Target 23 3. SECURITY PROBLEM DEFINITION The security problem definition has been taken directly from the claimed PP and any relevant EPs/Modules/Packages specified in Section 2.2 and is reproduced here for the convenience of the reader. The security problem is described in terms of the threats that the TOE is expected to address, assumptions about the operational environment, and any Organizational Security Policies (OSPs) that the TOE is expected to enforce. 3.1 THREATS The threats included in Table 6 are drawn directly from the PP and any EPs/Modules/Packages specified in Section 2.2. Table 6 – Threats ID Threat T.UNAUTHORIZED_ADMINISTRATOR_ACCESS Threat agents may attempt to gain Administrator access to the Network Device by nefarious means such as masquerading as an Administrator to the device, masquerading as the device to an Administrator, replaying an administrative session (in its entirety, or selected portions), or performing man- in-the-middle attacks, which would provide access to the administrative session, or sessions between Network Devices. Successfully gaining Administrator access allows malicious actions that compromise the security functionality of the device and the network on which it resides. T.WEAK_CRYPTOGRAPHY Threat agents may exploit weak cryptographic algorithms or perform a cryptographic exhaust against the key space. Poorly chosen encryption algorithms, modes, and key sizes will allow attackers to compromise the algorithms, or brute force exhaust the key space and give them unauthorized access allowing them to read, manipulate and/or control the traffic with minimal effort. T.UNTRUSTED_COMMUNICATION_CHANNELS Threat agents may attempt to target Network Devices that do not use standardized secure tunnelling protocols to protect the critical network traffic. Attackers may take advantage of poorly designed protocols or poor key management to successfully perform man-in-the-middle attacks, replay attacks, etc. Successful attacks will result in loss of confidentiality and integrity of the critical network traffic and potentially could lead to a compromise of the Network Device itself. T.WEAK_AUTHENTICATION_ENDPOINTS Threat agents may take advantage of secure protocols that use weak methods to authenticate the HPE Juniper Networking, Junos 24.4R2 for MX240/480/960 Routers and EX9204/9208/9214 Switches Security Target 24 ID Threat endpoints, e.g. a shared password that is guessable or transported as plaintext. The consequences are the same as a poorly designed protocol, the attacker could masquerade as the Administrator or another device, and the attacker could insert themselves into the network stream and perform a man-in-the- middle attack. The result is the critical network traffic is exposed and there could be a loss of confidentiality and integrity, and potentially the Network Device itself could be compromised. T.UPDATE_COMPROMISE Threat agents may attempt to provide a compromised update of the software or firmware which undermines the security functionality of the device. Non-validated updates or updates validated using non-secure or weak cryptography leave the update firmware vulnerable to surreptitious alteration. T.UNDETECTED_ACTIVITY Threat agents may attempt to access, change, and/or modify the security functionality of the Network Device without Administrator awareness. This could result in the attacker finding an avenue (e.g., misconfiguration, flaw in the product) to compromise the device and the Administrator would have no knowledge that the device has been compromised. T.SECURITY_FUNCTIONALITY_COMPROMISE Threat agents may compromise credentials and device data enabling continued access to the Network Device and its critical data. The compromise of credentials includes replacing existing credentials with an attacker’s credentials, modifying existing credentials, or obtaining the Administrator or device credentials for use by the attacker. Threat agents may also be able to take advantage of weak administrative passwords to gain privileged access to the device. T.SECURITY_FUNCTIONALITY_FAILURE An external, unauthorized entity could make use of failed or compromised security functionality and might therefore subsequently use or abuse security functions without prior authentication to access, change or modify device data, critical network traffic or security functionality of the device. T.DATA_INTEGRITY (MOD_MACSEC_V1.0) An attacker may modify data transmitted over the layer 2 link in a way that is not detected by the recipient. Devices on a network may be exposed to attacks that attempt to corrupt or modify data in transit without authorization. If malicious devices are able to modify and replay data that is transmitted HPE Juniper Networking, Junos 24.4R2 for MX240/480/960 Routers and EX9204/9208/9214 Switches Security Target 25 ID Threat over a layer 2 link, then the data contained within the communications may be susceptible to a loss of integrity. T.NETWORK_ACCESS (PKG_SSH_v1.0) An attacker may send traffic through the TOE that enables them to access devices in the TOE’s operational environment without authorization. A MACsec device may sit on the periphery of a network, which means that it may have an externally facing interface to a public network. Devices located in the public network may attempt to exercise services located on the internal network that are intended to be accessed only from within the internal network or externally accessible only from specifically authorized devices. If the MACsec device allows unauthorized external devices access to the internal network, these devices on the internal network may be subject to compromise. Similarly, if two MACsec devices are deployed to facilitate end-to-end encryption of traffic that is contained within a single network, an attacker could use an insecure MACsec device as a method to access devices on a specific segment of that network such as an individual LAN. T.UNTRUSTED_MACSEC_COMMUNICATION_CHANNELS (MOD_MACSEC_v1.0) An attacker may acquire sensitive TOE or user data that is transmitted to or from the TOE because an untrusted communication channel causes a disclosure of data in transit. A generic network device may be threatened by the use of insecure communications channels to transmit sensitive data. The attack surface of a MACsec device also includes the MACsec trusted channels. Inability to secure communications channels, or failure to do so correctly, would expose user data that is assumed to be secure to the threat of unauthorized disclosure. 3.2 ASSUMPTIONS The assumptions included in Table 7 are drawn directly from PP and any relevant EPs/Modules/Packages. HPE Juniper Networking, Junos 24.4R2 for MX240/480/960 Routers and EX9204/9208/9214 Switches Security Target 26 Table 7 – Assumptions ID Assumption A.PHYSICAL_PROTECTION The Network Device is assumed to be physically protected in its operational environment and not subject to physical attacks that compromise the security or interfere with the device’s physical interconnections and correct operation. This protection is assumed to be sufficient to protect the device and the data it contains. As a result, the cPP does not include any requirements on physical tamper protection or other physical attack mitigations. The cPP does not expect the product to defend against physical access to the device that allows unauthorized entities to extract data, bypass other controls, or otherwise manipulate the device. For vNDs, this assumption applies to the physical platform on which the VM runs. A.LIMITED_FUNCTIONALITY The device is assumed to provide networking functionality as its core function and not provide functionality/services that could be deemed as general purpose computing. For example, the device should not provide a computing platform for general purpose applications (unrelated to networking functionality). A.NO_THRU_TRAFFIC_PROTECTION A standard/generic Network Device does not provide any assurance regarding the protection of traffic that traverses it. The intent is for the Network Device to protect data that originates on or is destined to the device itself, to include administrative data and audit data. Traffic that is traversing the Network Device, destined for another network entity, is not covered by the ND cPP. It is assumed that this protection will be covered by cPPs and PP-Modules for particular types of Network Devices (e.g., firewall). A.TRUSTED_ADMINISTRATOR The Security Administrator(s) for the Network Device are assumed to be trusted and to act in the best interest of security for the organization. This includes appropriately trained, following policy, and adhering to guidance documentation. Administrators are trusted to ensure passwords/credentials have sufficient strength and entropy and to lack malicious intent when administering the device. The Network Device is not expected to be capable of defending against a malicious Administrator that actively works to bypass or compromise the security of the device. A.REGULAR_UPDATES The Network Device firmware and software is assumed to be updated by an Administrator on a regular basis in response to the release of product updates due to known vulnerabilities. A.ADMIN_CREDENTIALS_SECURE The Administrator’s credentials (private key) used to access the Network Device are protected by the platform on which they reside. A.RESIDUAL_INFORMATION The Administrator must ensure that there is no unauthorized access possible for sensitive residual information (e.g. cryptographic keys, keying material, PINs, passwords etc.) on networking equipment when the equipment is discarded or removed from its operational environment. HPE Juniper Networking, Junos 24.4R2 for MX240/480/960 Routers and EX9204/9208/9214 Switches Security Target 27 3.3 ORGANIZATIONAL SECURITY POLICIES The OSPs included in Table 8 are drawn directly from the PP and any relevant EPs/Modules/Packages. Table 8 – OSPs ID OSP 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. HPE Juniper Networking, Junos 24.4R2 for MX240/480/960 Routers and EX9204/9208/9214 Switches Security Target 28 4. SECURITY OBJECTIVES The security objectives have been taken directly from the claimed PP and any relevant EPs/Modules/Packages and are reproduced here for the convenience of the reader. 4.1 SECURITY OBJECTIVES FOR THE TOE The security objectives in the following table apply to the TOE. These are augmented by the statement of security objectives for the TOE in relation to the MACsec capabilities as detailed in MOD_MACsec_v1.0. Table 9 – Security Objectives ID Security Objectives O.AUTHENTICATION_MACSEC [TD0870] To further address the issues associated with unauthorized disclosure of information, a compliant TOE’s authentication ability (MKA) will allow a MACsec peer to establish connectivity associations (CAs) with another MACsec peer. MACsec endpoints authenticate each other to ensure they are communicating with an authorized MAC Security Entity (SecY) entity. The TOE further mitigates this threat originally defined in the Base- PP by defining additional authentication requirements that establish connectivity between authenticated MACsec peers. Addressed by: FCS_MACSEC_EXT.4, FCS_MKA_EXT.1, FIA_PSK_EXT.1, FCS_DEVID_EXT.1 (selection-based), FCS_EAP- TLS_EXT.1 (selection-based). O.AUTHORIZED_ADMINISTRATION All network devices are expected to provide services that allow the security functionality of the device to be managed. The MACsec device, as a specific type of network device, has a refined set of management functions to address its specialized behavior. In order to further mitigate the threat of a compromise of its security functionality, the MACsec device prescribes the ability to limit brute-force authentication attempts by enforcing lockout of accounts that experience excessive failures and by limiting access to security-relevant data that administrators do not need to view O.CRYPTOGRAPHIC_FUNCTIONS_MACSEC To address the issues associated with unauthorized modification and disclosure of information, compliant TOEs will implement cryptographic capabilities. These capabilities are intended to maintain confidentiality and allow for detection and modification of data that is transmitted outside of the TOE. O.PORT_FILTERING_MACSEC To further address the issues associated with unauthorized network access, a compliant TOE’s port filtering capability will restrict the flow of network traffic through the TOE based on layer 2 frame characteristics and whether or not the traffic represents valid MACsec frames and MACsec Key Agreement Protocol Data Units (MKPDUs). HPE Juniper Networking, Junos 24.4R2 for MX240/480/960 Routers and EX9204/9208/9214 Switches Security Target 29 ID Security Objectives O.REPLAY_DETECTION A MACsec device is expected to help mitigate the threat of MACsec data integrity violations by providing a mechanism to detect and discard replayed traffic for MPDUs. O.SYSTEM_MONITORING_MACSEC To address the issues of administrators being able to monitor the operations of the MACsec device, compliant TOEs will implement the ability to log the flow of Ethernet traffic. Specifically, the TOE will provide the means for administrators to configure rules to ‘log’ when Ethernet traffic grants or restricts access. As a result, the ‘log’ will result in informative event logs whenever a match occurs. In addition, the establishment of security CAs is auditable, not only between MACsec devices, but also with MAC Security Key Agreement Entities (KaYs). O.TSF_INTEGRITY [TD0870] To mitigate the security risk that the MACsec device may fail during startup, it is required to fail-secure if any self-test failures occur during startup. This ensures that the device will only operate when it is in a known state. The TOE further mitigates this threat originally defined in the Base- PP by implementing measures to fail securely if any self-test failures occur during startup, ensuring the device only operates when in a known state. Addressed by: FPT_FLS.1 4.2 SECURITY OBJECTIVES FOR THE OPERATIONAL ENVIRONMENT Security objectives for the operational environment assist the TOE in correctly providing its security functionality. These objectives, which are found in the table below, track with the assumptions about the TOE operational environment. Table 10 – Security Objectives for the Operational Environment ID Objectives for the Operational Environment OE.PHYSICAL Physical security, commensurate with the value of the TOE and the data it contains, is provided by the environment. OE.NO_GENERAL_PURPOSE There are no general-purpose computing capabilities (e.g., compilers or user applications) available on the TOE, other than those services necessary for the operation, administration and support of the TOE. Note: For vNDs the TOE includes only the contents of the its own VM, and does not include other VMs or the VS. OE.NO_THRU_TRAFFIC_PROTECTION The TOE does not provide any protection of traffic that traverses it. It is assumed that protection of this traffic will be covered by other security and assurance measures in the operational environment. HPE Juniper Networking, Junos 24.4R2 for MX240/480/960 Routers and EX9204/9208/9214 Switches Security Target 30 ID Objectives for the Operational Environment OE.TRUSTED_ADMIN Security Administrators are trusted to follow and apply all guidance documentation in a trusted manner. For vNDs, this includes the VS Administrator responsible for configuring the VMs that implement ND functionality. For TOEs supporting X.509v3 certificate-based authentication, the Security Administrator(s) are assumed to monitor the revocation status of all certificates in the TOE’s trust store and to remove any certificate from the TOE’s trust store in case such certificate can no longer be trusted. OE.UPDATES The TOE firmware and software is updated by an Administrator on a regular basis in response to the release of product updates due to known vulnerabilities. OE.ADMIN_CREDENTIALS_SECURE The Administrator’s credentials (private key) used to access the TOE must be protected on any other platform on which they reside. OE.RESIDUAL_INFORMATION The Security Administrator ensures that there is no unauthorized access possible for sensitive residual information (e.g. cryptographic keys, keying material, PINs, passwords etc.) on networking equipment when the equipment is discarded or removed from its operational environment. For vNDs, this applies when the physical platform on which the VM runs is removed from its operational environment. HPE Juniper Networking, Junos 24.4R2 for MX240/480/960 Routers and EX9204/9208/9214 Switches Security Target 31 5. SECURITY REQUIREMENTS This section identifies the Security Functional Requirements (SFRs) for the TOE. The SFRs included in this section are derived from Part 2 of the Common Criteria for Information Technology Security Evaluation, Version 3.1, Revisions 5, April 2017, and all international interpretations. Table 11 – SFRs Requirement Description FAU_GEN.1 Audit Data Generation FAU_GEN.1/MACSEC Audit Data Generation (MACsec) FAU_GEN.2 User Identity Association FAU_STG_EXT.1 Protected Audit Event Storage FCS_CKM.1 Cryptographic Key Generation FCS_CKM.2 Cryptographic Key Establishment FCS_CKM.4 Cryptographic Key Destruction FCS_COP.1/DataEncryption Cryptographic Operation (AES Data Encryption/Decryption) FCS_COP.1/SigGen Cryptographic Operation (Signature Generation and Verification) FCS_COP.1/Hash Cryptographic Operation (Hash Algorithm) FCS_COP.1/KeyedHash Cryptographic Operation (Keyed Hash Algorithm) FCS_COP.1/CMAC Cryptographic Operation (AES-CMAC Keyed Hash Algorithm) FCS_COP.1/MACSEC Cryptographic Operation (MACsec AES Data Encryption and Decryption) FCS_RBG_EXT.1 Random Bit Generation FCS_SSH_EXT.1 SSH Protocol FCS_SSHS_EXT.1 SSH Protocol - Server FCS_MACSEC_EXT.1 MACsec FCS_MACSEC_EXT.2 MACsec Integrity and Confidentiality FCS_MACSEC_EXT.3 MACsec Randomness FCS_MACSEC_EXT.4 MACsec Key Usage FCS_MKA_EXT.1 MACsec Key Agreement FCS_NTP_EXT.1 NTP Protocol FIA_AFL.1 Authentication Failure Handling (Refinement) FIA_PMG_EXT.1 Password Management FIA_UIA_EXT.1 User Identification and Authentication FIA_UAU.7 Protected Authentication Feedback (Refinement) FIA_PSK_EXT.1 Pre-Shared Key Composition FMT_MOF.1/ManualUpdate Management of Security Functions Behaviour FMT_MOF.1/Functions Management of Security Functions Behaviour FMT_MOF.1/Services Management of Security Functions Behaviour HPE Juniper Networking, Junos 24.4R2 for MX240/480/960 Routers and EX9204/9208/9214 Switches Security Target 32 Requirement Description FMT_MTD.1/CoreData Management of TSF Data FMT_MTD.1/CryptoKeys Management of TSF Data FMT_SMF.1 Specification of Management Functions FMT_SMF.1/MACSEC Specification of Management Functions (MACsec) FMT_SMR.2 Restrictions on Security Roles FPT_SKP_EXT.1 Protection of TSF Data (for reading of all symmetric keys) FPT_APW_EXT.1 Protection of Administrator Passwords FPT_TST_EXT.1 TSF Testing (Extended) FPT_TUD_EXT.1 Trusted Update FPT_STM_EXT.1 Reliable Time Stamps FPT_CAK_EXT.1 Protection of CAK Data FPT_FLS.1 Failure with Preservation of Secure State FPT_RPL.1 Replay Detection FTA_SSL.3 TSF-initiated Termination FTA_SSL.4 User-initiated Termination FTA_SSL_EXT.1 TSF-initiated Session Locking FTA_TAB.1 Default TOE Access Banners (Refinement) FTP_ITC.1 Inter-TSF Trusted Channel (Refinement) FTP_TRP.1/Admin Trusted Path (Refinement) FTP_ITC.1/MACSEC Inter-TSF Trusted Channel (MACsec Communications) 5.1 CONVENTIONS The CC allows the following types of operations to be performed on the functional requirements: assignments, selections, refinements, and iterations. The following font conventions are used within this document to identify operations defined by CC: • Assignment: Indicated with italicized text; • Refinement: Indicated with bold text; • Selection: Indicated with underlined text; • Iteration: Indicated by appending the iteration identifier after a slash, e.g., /SigGen. • Where operations were completed in the cPP and relevant EPs/Modules/Packages/TDs, the formatting used in the source document has been retained except for text within brackets. If the text within brackets is completing an operation by the ST author, the conventions from the first three bullets apply. Otherwise, the text is presented in plaintext. • Extended SFRs are identified by the addition of “EXT” after the requirement name. 5.2 SECURITY FUNCTIONAL REQUIREMENTS This section includes the security functional requirements for this ST. HPE Juniper Networking, Junos 24.4R2 for MX240/480/960 Routers and EX9204/9208/9214 Switches Security Target 33 5.2.1 SECURITY AUDIT (FAU) 5.2.1.1 FAU_GEN.1 AUDIT DATA GENERATION FAU_GEN.1.1 The TSF shall be able to generate an audit record of the following auditable events: a) Start-up and 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). • [Resetting passwords (name of related Administrator account shall be logged)]; d) Specifically defined auditable events listed in Table 12. FAU_GEN.1.2 [TD0777] The TSF shall record within each audit record at least the following information: a) Date and time of the event, type of event, subject identity (if applicable), and the outcome (success or failure) of the event; and b) For each audit event type, based on the auditable event definitions of the functional components included in the cPP/ST, information specified in column three of Table 12. Table 12 – Security Functional Requirements and Auditable Events Requirement Auditable Events Additional Audit Record Contents FAU_GEN.1 None None FAU_GEN.2 None None FAU_STG_EXT.1 Configuration of local audit settings. Identity of account making changes to the audit configuration. FCS_CKM.1 None None FCS_CKM.2 None None FCS_CKM.4 None None FCS_COP.1/DataEncryption None None FCS_COP.1/SigGen None None FCS_COP.1/Hash None None FCS_COP.1/KeyedHash None None FCS_RBG_EXT.1 None None FCS_SSH_EXT.1 [TD0777] [Failure to establish SSH connection] [Reason for failure and Non-TOE endpoint of attempted connection (IP Address)] HPE Juniper Networking, Junos 24.4R2 for MX240/480/960 Routers and EX9204/9208/9214 Switches Security Target 34 Requirement Auditable Events Additional Audit Record Contents [Establishment of SSH connection] [Non-TOE endpoint of attempted connection (IP Address)] [Termination of SSH connection session] [Non-TOE endpoint of attempted connection (IP Address)] [Dropping of packet(s) outside defined size limits] [Packet Size] FCS_SSHS_EXT.1 No events specified FCS_NTP_EXT.1 • Configuration of a new time server • Removal of configured time server Identity of new/removed time server FIA_UIA_EXT.1 All use of identification and authentication mechanism Origin of the attempt (e.g., IP address) 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_UAU.7 None None FMT_MOF.1/ManualUpdate Any attempt to initiate a manual update None FMT_MOF.1/Functions None None FMT_MOF.1/Services None None FMT_MTD.1/CoreData None None FMT_MTD.1/CryptoKeys None None FMT_SMF.1 All management activities of TSF data. None FMT_SMR.2 None None FPT_SKP_EXT.1 None None FPT_APW_EXT.1 None None FPT_TST_EXT.1 None None FPT_TUD_EXT.1 Initiation of update; result of the update attempt (success or failure) None FPT_STM_EXT.1 Discontinuous changes to time - either Administrator actuated or changed via an automated process For discontinuous changes to time: The old and new values for the time. Origin of the attempt to change time for success and failure (e.g., IP address). FTA_SSL.3 The termination of a remote session by the session locking mechanism None FTA_SSL.4 The termination of an interactive session None HPE Juniper Networking, Junos 24.4R2 for MX240/480/960 Routers and EX9204/9208/9214 Switches Security Target 35 Requirement Auditable Events Additional Audit Record Contents FTA_SSL_EXT.1 (if “terminate the session” is selected) The termination of a local session by the session locking mechanism 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 • None • None • Reason for failure FTP_TRP.1/Admin • Initiation of the trusted path • Termination of the trusted path. • Failure of the trusted path functions. • None • None • Reason for failure Application Note: This SFR has been updated as per TD0777. 5.2.1.2 FAU_GEN.1/MACSEC AUDIT DATA GENERATION (MACSEC) FAU_GEN.1.1/MACSEC 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; c. All administrative actions; d. [Specifically defined auditable events listed in the Auditable Events table (Table 13)] Table 13 – Security Functional Requirements and Auditable Events/MACsec Requirement Auditable Events Additional Audit Record Contents FCS_MACSEC_EXT.1 Session establishment Secure Channel Identifier (SCI) FCS_MACSEC_EXT.3 Creation and update of SAK Creation and update times FCS_MACSEC_EXT.4 Creation of CA Connectivity Association Key Names (CKNs) FPT_RPL.1 Detected replay attempt None FAU_GEN.1.2/MACSEC The TSF shall record within each audit record at least the following information: a. Date and time of the event, type of event, subject identity (if applicable), and the outcome (success or failure) of the event; and b. For each audit event type, based on the auditable event definitions of the functional components included in the PP-Module/ST, [information specified in column three of the Auditable Events table (Table 13)]. 5.2.1.3 FAU_GEN.2 USER IDENTITY ASSOCIATION HPE Juniper Networking, Junos 24.4R2 for MX240/480/960 Routers and EX9204/9208/9214 Switches Security Target 36 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. 5.2.1.4 FAU_STG_EXT.1 PROTECTED AUDIT EVENT STORAGE FAU_STG_EXT.1.1 The TSF shall be able to transmit the generated audit data to an external IT entity using a trusted channel according to FTP_ITC.1. FAU_STG_EXT.1.2 The TSF shall be able to store generated audit data on the TOE itself. In addition [ • The TOE shall consist of a single standalone component that stores audit data locally ]. FAU_STG_EXT.1.3 The TSF shall maintain a [log file] of audit records in the event that an interruption of communication with the remote audit server occurs. FAU_STG_EXT.1.4 The TSF shall be able to store [persistent] audit records locally with a minimum storage size of [1 MB]. FAU_STG_EXT.1.5 The TSF shall [overwrite previous audit records according to the following rule: [oldest log file is overwritten]] 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 [manual export, ability to view locally]. 5.2.2 CRYPTOGRAPHIC SUPPORT (FCS) 5.2.2.1 FCS_CKM.1 CRYPTOGRAPHIC KEY GENERATION FCS_CKM.1.1[TD0921] The TSF shall generate asymmetric cryptographic keys in accordance with a specified cryptographic key generation algorithm: [ • RSA schemes using cryptographic key sizes of [2048, 3072 and 4096 bits] that meet the following: FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Appendix B.3 or FIPS PUB 186-5, "Digital Signature Standard (DSS)", A.1; • ECC schemes using ‘NIST curves’ [P-256, P-384, P-521] that meet the following: FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Appendix B.4 or FIPS PUB 186-5, “Digital Signature Standard (DSS)”, Appendix A.2, or ISO/IEC 14888-3, “IT Security techniques - Digital signatures with appendix - Part 3: Discrete logarithm based mechanisms”, Section 6.6.; HPE Juniper Networking, Junos 24.4R2 for MX240/480/960 Routers and EX9204/9208/9214 Switches Security Target 37 ] and specified cryptographic key sizes [assignment: cryptographic key sizes] that meet the following: [assignment: list of standards]. Note: TD0921 has been applied. 5.2.2.2 FCS_CKM.2 CRYPTOGRAPHIC KEY ESTABLISHMENT FCS_CKM.2.1 The TSF shall perform cryptographic key establishment in accordance with a specified cryptographic key establishment method: [ • Elliptic curve-based key establishment schemes that meet the following: NIST Special Publication 800-56A Revision 3, “Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography”; ] that meets the following: [assignment: list of standards]. 5.2.2.3 FCS_CKM.4 CRYPTOGRAPHIC KEY DESTRUCTION FCS_CKM.4.1 The TSF shall destroy cryptographic keys in accordance with a specified cryptographic key destruction method • For plaintext keys in volatile storage, the destruction shall be executed by a [single overwrite consisting of [zeroes], destruction of reference to the key directly followed by a request for garbage collection]; • For plaintext keys in non-volatile storage, the destruction shall be executed by the invocation of an interface provided by a part of the TSF that [ o logically addresses the storage location of the key and performs a [single] overwrite consisting of [zeroes]]; that meets the following: No Standard. 5.2.2.4 FCS_COP.1/CMAC CRYPTOGRAPHIC OPERATION (AES-CMAC KEYED HASH ALGORITHM) FCS_COP.1.1/CMAC The TSF shall perform [keyed-hash message authentication] in accordance with a specified cryptographic algorithm [AES-CMAC] and cryptographic key sizes [128, 256] bits and message digest size of 128 bits that meets the following: [NIST SP 800-38B]. 5.2.2.5 FCS_COP.1/DATAENCRYPTION CRYPTOGRAPHIC OPERATIONS (AES DATA ENCRYPTION/DECRYPTION) FCS_COP.1.1/DataEncryption The TSF shall perform encryption/decryption in accordance with a specified cryptographic algorithm AES used in [CBC, CTR, GCM] mode and cryptographic key sizes [128 bits, 256 bits] that meet the following: AES as specified in ISO 18033-3, [CBC as specified in ISO 10116, CTR as specified in ISO 10116, GCM as specified in ISO 19772]. 5.2.2.6 FCS_COP.1/HASH CRYPTOGRAPHIC OPERATIONS (HASH ALGORITHM) HPE Juniper Networking, Junos 24.4R2 for MX240/480/960 Routers and EX9204/9208/9214 Switches Security Target 38 FCS_COP.1.1/Hash The TSF shall perform cryptographic hashing services in accordance with a specified cryptographic algorithm [SHA- 1, SHA-256, SHA-384, SHA-512] and cryptographic key sizes [assignment: cryptographic key sizes] and message digest sizes [160, 256, 384, 512] bits that meet the following: ISO/IEC 10118-3:2004. 5.2.2.7 FCS_COP.1/KEYEDHASH CRYPTOGRAPHIC OPERATION (KEYED HASH ALGORITHM) FCS_COP.1.1/KeyedHash The TSF shall perform keyed-hash message authentication in accordance with a specified cryptographic algorithm [HMAC-SHA-256, HMAC-SHA-512] and cryptographic key sizes [256 and 512 bits] and message digest sizes [256, 512] bits that meet the following: ISO/IEC 9797-2:2011, Section 7 “MAC Algorithm 2”. 5.2.2.8 FCS_COP.1/MACSEC CRYPTOGRAPHIC OPERATION (MACSEC AES DATA ENCRYPTION AND DECRYPTION) FCS_COP.1.1/MACSEC The TSF shall perform [encryption and decryption] in accordance with a specified cryptographic algorithm [AES used in AES Key Wrap, GCM] and cryptographic key sizes [128, 256] bits that meets the following: [AES as specified in ISO 18033-3, AES Key Wrap as specified in NIST SP 800- 38F, GCM as specified in ISO 19772]. 5.2.2.9 FCS_COP.1/SIGGEN CRYPTOGRAPHIC OPERATION (SIGNATURE GENERATION AND VERIFICATION) FCS_COP.1.1/SigGen [TD0921] The TSF shall perform cryptographic signature services (generation and verification) in accordance with a specified cryptographic algorithm [ • RSA Digital Signature Algorithm, • Elliptic Curve Digital Signature Algorithm ] and cryptographic key sizes [ • For RSA: [modulus 2048, 3072 and 4096 bits], • For ECDSA: [256 bits, 384 and 521 bits] ] that meet the following: [ • For RSA schemes: FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Section 5.5, using PKCS #1 v2.1 or FIPS PUB 186-5, "Digital Signature Standard (DSS)", Section 5.4 using PKCS #1 v2.2 Signature Schemes RSASSA-PSS and/or RSASSA-PKCS1v1_5; ISO/IEC 9796-2, Digital signature scheme 2 or Digital Signature scheme 3, • For ECDSA schemes implementing [P-256, P-384, P-521] curves that meet the following: FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Section 6 and Appendix D, Implementing “NIST Recommended” curves ; or FIPS PUB 186-5, "Digital Signature Standard (DSS)", Section 6 and NIST SP 800-186 Section 3.2.1, Implementing Weierstrass curves; or ISO/IEC 14888-3, "IT Security techniques - Digital signatures with appendix - Part 3: Discrete logarithm based mechanisms", Section 6.6, ]. HPE Juniper Networking, Junos 24.4R2 for MX240/480/960 Routers and EX9204/9208/9214 Switches Security Target 39 Note: TD0921 has been applied. 5.2.2.10 FCS_MACSEC_EXT.1 MACSEC FCS_MACSEC_EXT.1.1 The TSF shall implement MACsec in accordance with IEEE Standard 802.1AE-2018. FCS_MACSEC_EXT.1.2 The TSF shall derive a Secure Channel Identifier (SCI) from a peer’s MAC address and port to uniquely identify the originator of an MPDU. FCS_MACSEC_EXT.1.3 The TSF shall reject any MPDUs during a given session that contain an SCI other than the one used to establish that session. FCS_MACSEC_EXT.1.4 [TD0884] The TSF shall permit only EAPOL (Port Access Entity (PAE) EtherType 88-8E), MACsec frames (EtherType 88-E5), and [MAC control frames (EtherType is 88- 08)] and shall discard others. Note: TD0884 has been applied. 5.2.2.11 FCS_MACSEC_EXT.2 MACSEC INTEGRITY AND CONFIDENTIALITY FCS_MACSEC_EXT.2.1 The TOE shall implement MACsec with support for integrity protection with a confidentiality offset of [0, 30, 50]. FCS_MACSEC_EXT.2.2 The TSF shall provide assurance of the integrity of protocol data units (MPDUs) using an Integrity Check Value (ICV) derived with the SAK. FCS_MACSEC_EXT.2.3 The TSF shall provide the ability to derive an Integrity Check Value Key (ICK) from a Connectivity Association Key (CAK) using a KDF. 5.2.2.12 FCS_MACSEC_EXT.3 MACSEC RANDOMNESS FCS_MACSEC_EXT.3.1 [TD0825] The TSF shall generate unique Secure Association Keys (SAKs) using [key derivation from Connectivity Association Key (CAK) per section 9.8.1 of IEEE 802.1X-2020] such that the likelihood of a repeating SAK is no less than 1 in 2 to the power of the size of the generated key. Note: TD0825 has been applied. FCS_MACSEC_EXT.3.2 The TSF shall generate unique nonces for the derivation of SAKs using the TOE’s random bit generator as specified by FCS_RBG_EXT.1. HPE Juniper Networking, Junos 24.4R2 for MX240/480/960 Routers and EX9204/9208/9214 Switches Security Target 40 5.2.2.13 FCS_MACSEC_EXT.4 MACSEC KEY USAGE FCS_MACSEC_EXT.4.1 [TD0825] The TSF shall support peer authentication using pre-shared keys (PSKs) [no other method]. Note: TD0825 has been applied. FCS_MACSEC_EXT.4.2 The TSF shall distribute SAKs between MACsec peers using AES key wrap as specified in FCS_COP.1/MACSEC. FCS_MACSEC_EXT.4.3 The TSF shall support specifying a lifetime for CAKs. FCS_MACSEC_EXT.4.4 [TD0825] The TSF shall associate Connectivity Association Key Names (CKNs) with SAKs that are defined by the KDF using the CAK as input data (per IEEE 802.1X-2020, Section 9.8.1). Note: TD0825 has been applied. FCS_MACSEC_EXT.4.5 The TSF shall associate CKNs with CAKs. The length of the CKN shall be an integer number of octets, between 1 and 32 (inclusive). 5.2.2.14 FCS_MKA_EXT.1 MACSEC KEY AGREEMENT FCS_MKA_EXT.1.1 [TD0825] The TSF shall implement Key Agreement Protocol (MKA) in accordance with IEEE 802.1X-2020 and 802.1Xbx-2014. Note: TD0825 has been applied. FCS_MKA_EXT.1.2 The TSF shall provide assurance of the integrity of MKA protocol data units (MKPDUs) using an Integrity Check Value (ICV) derived from an Integrity Check Value Key (ICK). FCS_MKA_EXT.1.3 The TSF shall provide the ability to derive an Integrity Check Value Key (ICK) from a CAK using a KDF. FCS_MKA_EXT.1.4 [TD0882] The TSF shall enforce an MKA Lifetime Timeout limit of 6.0 seconds and [MKA Hello Time limit of 2 seconds]. Note: TD0882 has been applied. FCS_MKA_EXT.1.5 The key server shall refresh a SAK when it expires. The key server shall distribute a SAK by [ • pairwise CAKs that are PSKs ]. HPE Juniper Networking, Junos 24.4R2 for MX240/480/960 Routers and EX9204/9208/9214 Switches Security Target 41 FCS_MKA_EXT.1.6 The key server shall distribute a fresh SAK whenever a member is added to or removed from the live membership of the CA. FCS_MKA_EXT.1.7 [TD0825] The TSF shall validate MKPDUs according to IEEE 802.1X-2020 Section 11.11.2. In particular, the TSF shall discard without further processing any MKPDUs to which any of the following conditions apply: a. The destination address of the MKPDU was an individual address. b. The MKPDU is less than 32 octets long. c. The MKPDU comprises fewer octets than indicated by the Basic Parameter Set body length, as encoded in bits 4 through 1 of octet 3 and bits 8 through 1 of octet 4, plus 16 octets of ICV. d. The CAK Name is not recognized. If an MKPDU passes these tests, then the TSF will begin processing it as follows: a. If the Algorithm Agility parameter identifies an algorithm that has been implemented by the receiver, the ICV shall be verified as specified in IEEE 802.1X-2020 Section 9.4.1. b. If the Algorithm Agility parameter is unrecognized or not implemented by the receiver, its value can be recorded for diagnosis but the received MKPDU shall be discarded without further processing. Each received MKPDU that is validated as specified in this clause and verified as specified in IEEE 802.1X-2020 Section 9.4.1 shall be decoded as specified in IEEE 802.1X-2020 Section 11.11.4. Note: TD0825 has been applied. 5.2.2.15 FCS_NTP_EXT PROTOCOL FCS_NTP_EXT.1.1 The TSF shall use only the following NTP version(s) [NTP v4 (RFC 5905)]. FCS_NTP_EXT.1.2 The TSF shall update its system time using [ • Authentication using [SHA1, SHA256] as the message digest algorithm(s); ] 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. HPE Juniper Networking, Junos 24.4R2 for MX240/480/960 Routers and EX9204/9208/9214 Switches Security Target 42 5.2.2.16 FCS_RBG_EXT.1 RANDOM BIT GENERATION FCS_RBG_EXT.1.1 The TSF shall perform all deterministic random bit generation services in accordance with ISO/IEC 18031:2011 using [HMAC_DRBG [SHA-512]]. FCS_RBG_EXT.1.2 [TD0990] The deterministic RBG shall be seeded by at least one entropy source that accumulates entropy from [[1] software- based noise source] with a minimum of [256 bits] of entropy at least equal to [the greatest security strength, according to ISO/IEC 18031:2011 Table C.1 “Security Strength Table for Hash Functions”,]. Note: TD0990 has been applied. 5.2.2.16.1 FCS_SSH_EXT.1 SSH PROTOCOL FCS_SSH_EXT.1.1 [TD0909] The TOE shall implement SSH acting as a [server] in accordance with that complies with RFCs 4251, 4252, 4253, 4254, [4256, 4344, 5647, 5656, 6668, 8308, 8332] and [no other standard]. Note: TD0909 has been applied. FCS_SSH_EXT.1.2 The TSF shall ensure that the SSH protocol implementation supports the following authentication methods: [ • “password” (RFC 4252), • “keyboard-interactive” (RFC 4256), • “publickey” (RFC 4252): [ o ssh-rsa (RFC 4253), o rsa-sha2-256 (RFC 8332), o rsa-sha2-512 (RFC 8332), o ecdsa-sha2-nistp256 (RFC 5656), o ecdsa-sha2-nistp384 (RFC 5656), o ecdsa-sha2-nistp521 (RFC 5656), ] ] and no other methods. FCS_SSH_EXT.1.3 The TSF shall ensure that, as described in RFC 4253, packets greater than [256K bytes] in an SSH transport connection are dropped. FCS_SSH_EXT.1.4 The TSF shall protect data in transit from unauthorised disclosure using the following mechanisms: [ • aes128-ctr (RFC 4344), • aes256-ctr (RFC 4344), • aes128-cbc (RFC 4253), • aes256-cbc (RFC 4253) HPE Juniper Networking, Junos 24.4R2 for MX240/480/960 Routers and EX9204/9208/9214 Switches Security Target 43 • aes128-gcm@openssh.com (RFC 5647), • aes256-gcm@openssh.com (RFC 5647)] and no other mechanisms. FCS_SSH_EXT.1.5 The TSF shall protect data in transit from modification, deletion, and insertion using: [ • hmac-sha2-256 (RFC 6668), • hmac-sha2-512 (RFC 6668) • implicit] and no other mechanisms. FCS_SSH_EXT.1.6 [TD0967] The TSF shall establish a shared secret with its peer using: [ • ecdh-sha2-nistp256 (RFC 5656), • ecdh-sha2-nistp384 (RFC 5656), • ecdh-sha2-nistp521 (RFC 5656)] and no other mechanisms. Note: TD0967 has been applied. FCS_SSH_EXT.1.7 The TSF shall 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 The TSF shall ensure that [ • 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. 5.2.2.17 FCS_SSHS_EXT.1 SSH PROTOCOL – SERVER FCS_SSHS_EXT.1.1 The TSF shall authenticate itself to its peer (SSH Client) using: [ • ssh-rsa (RFC 4253), • rsa-sha2-256 (RFC 8332), • rsa-sha2-512 (RFC 8332), • ecdsa-sha2-nistp256 (RFC 5656), • ecdsa-sha2-nistp384 (RFC 5656), HPE Juniper Networking, Junos 24.4R2 for MX240/480/960 Routers and EX9204/9208/9214 Switches Security Target 44 • ecdsa-sha2-nistp521 (RFC 5656), ]. 5.2.3 IDENTIFICATION AND AUTHENTICATION (FIA) 5.2.3.1 FIA_AFL.1 AUTHENTICATION FAILURE HANDLING FIA_AFL.1.1 The TSF shall detect when an Administrator configurable positive integer within [1 to 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 [prevent the offending Administrator from successfully establishing a remote session using any authentication method that involves a password until [manual unlock] is taken by an Administrator, prevent the offending Administrator from successfully establishing a remote session using any authentication method that involves a password until an Administrator defined time period has elapsed]. 5.2.3.2 FIA_PMG_EXT.1 PASSWORD MANAGEMENT FIA_PMG_EXT.1.1 The TSF shall provide the following password management capabilities 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: [“!”, “@”, “#”, “$”, “%”, “^”, “&”, “*”, “(“, “)”,[“?”, “~”, “,”, “.”, “/”, “:”, “;”, “_”, “+”, “-“, “=”, “{“, “}”, “[“, “]”, “|”, “<”, “>”, “ ” ”, “ ‘ ”, “ \ “, “ ` “]]; b) Minimum password length shall be configurable to between [06] and [20] characters. 5.2.3.3 FIA_PSK_EXT.1 PRE-SHARED KEY COMPOSITION FIA_PSK_EXT.1.1 [TD0825] The TSF shall use PSKs for MKA as defined by IEEE 802.1X-2020, [no other protocols]. Note: TD0825 has been applied. FIA_PSK_EXT.1.2 The TSF shall be able to [accept] bit-based PSKs. 5.2.3.4 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; HPE Juniper Networking, Junos 24.4R2 for MX240/480/960 Routers and EX9204/9208/9214 Switches Security Target 45 • [[Responding to ICMP Echo Requests]]. 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 [TD0900] The TSF shall provide the following remote authentication mechanisms [SSH password, SSH public key] and [ no other mechanism]. The TSF shall provide the following local authentication mechanisms [password-based]. Note: TD0900 has been applied. 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. 5.2.3.5 FIA_UAU.7 PROTECTED AUTHENTICATION FEEDBACK (REFINEMENT) 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. 5.2.4 SECURITY MANAGEMENT (FMT) 5.2.4.1 FMT_MOF.1/MANUALUPDATE MANAGEMENT OF SECURITY FUNCTIONS BEHAVIOR FMT_MOF.1.1/ManualUpdate The TSF shall restrict the ability to enable the functions to perform manual updates to Security Administrators. 5.2.4.2 FMT_MOF.1/FUNCTIONS MANAGEMENT OF SECURITY FUNCTIONS BEHAVIOUR FMT_MOF.1.1/Functions The TSF shall restrict the ability to [modify the behaviour of] the functions [transmission of audit data to an external IT entity, handling of audit data] to Security Administrators. 5.2.4.3 FMT_MOF.1/SERVICES MANAGEMENT OF SECURITY FUNCTIONS BEHAVIOUR FMT_MOF.1.1/Services The TSF shall restrict the ability to start and stop the functions services to Security Administrators. 5.2.4.4 FMT_MTD.1/COREDATA MANAGEMENT OF TSF DATA FMT_MTD.1.1/CoreData The TSF shall restrict the ability to manage the TSF data to Security Administrators. HPE Juniper Networking, Junos 24.4R2 for MX240/480/960 Routers and EX9204/9208/9214 Switches Security Target 46 5.2.4.5 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. 5.2.4.6 FMT_SMF.1 SPECIFICATION OF MANAGEMENT FUNCTIONS FMT_SMF.1.1 [TD0880] The TSF shall be capable of performing the following management functions: • Ability to administer the TOE remotely; • Ability to configure the access banner; • Ability to configure the remote session inactivity time before session termination; • Ability to update the TOE, and to verify the updates using digital signature capability prior to installing those updates; • [ o Ability to start and stop services; 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 modify the behaviour of the transmission of audit data to an external IT entity; 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 re-enable an Administrator account; 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 set the time which is used for time-stamps; o Ability to configure NTP; o Ability to administer the TOE locally; o Ability to manage the trusted public keys database;] Note: TD0880 has been applied. 5.2.4.7 FMT_SMF.1/MACSEC SPECIFICATION OF MANAGEMENT FUNCTIONS (MACSEC) FMT_SMF.1.1/MACSEC [TD0825] The TSF shall be capable of performing the following management functions related to MACsec functionality: [Ability of a Security Administrator to: • Manage a PSK-based CAK and install it in the device • Manage the key server to create, delete, and activate MKA participants [[Command Line Interface commands]] • Specify the lifetime of a CAK • Enable, disable, or delete a PSK-based CAK using [[Command Line Interface commands]] [ HPE Juniper Networking, Junos 24.4R2 for MX240/480/960 Routers and EX9204/9208/9214 Switches Security Target 47 • No other MACsec management functions ] ]. Note: TD0825 has been applied. 5.2.4.8 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. 5.2.5 PROTECTION OF THE TSF (FPT) 5.2.5.1 FPT_APW_EXT.1 PROTECTION OF ADMINISTRATOR PASSWORDS FPT_APW_EXT.1.1 The TSF shall store administrative passwords in non-plaintext form. FPT_APW_EXT.1.2 The TSF shall prevent the reading of plaintext administrative passwords. 5.2.5.2 FPT_CAK_EXT.1 PROTECTION OF CAK DATA FPT_CAK_EXT.1.1 The TSF shall prevent reading of CAK values by administrators. 5.2.5.3 FPT_FLS.1 FAILURE WITH PRESERVATION OF SECURE STATE FPT_FLS.1.1 [TD0816] The TSF shall fail-secure when any of the following types of failures occur: [failure of the power-on self-tests, failure of integrity check of the TSF executable image, failure of noise source health tests]. Note: TD0816 has been applied. HPE Juniper Networking, Junos 24.4R2 for MX240/480/960 Routers and EX9204/9208/9214 Switches Security Target 48 5.2.5.4 FPT_RPL.1 REPLAY DETECTION FPT_RPL.1.1 The TSF shall detect replay for the following entities: [MPDUs, MKA frames]. FPT_RPL.1.2 [TD0881] The TSF shall perform [discarding of the replayed data, logging of the detected replay attempt] when replay is detected. Note: TD0881 has been applied. 5.2.5.5 FPT_SKP_EXT.1 PROTECTION OF TSF DATA (FOR READING OF ALL SYMMETRIC KEYS) FPT_SKP_EXT.1.1 The TSF shall prevent reading of all pre-shared keys, symmetric keys, and private keys. 5.2.5.6 FPT_STM_EXT.1 RELIABLE TIME STAMPS FPT_STM_EXT.1.1 The TSF shall be able to provide reliable time stamps for its own use. FPT_STM_EXT.1.2 The TSF shall [synchronise time with an NTP server, allow the Security Administrator to set the time]. 5.2.5.7 FPT_TST_EXT.1 TSF TESTING FPT_TST_EXT.1.1 [TD0836] The TSF shall run a suite of the following self-tests: [ • During initial start-up (on power on) to verify the integrity of the TOE firmware and software; • Prior to providing any cryptographic service and [on-demand] to verify correct operation of cryptographic implementation necessary to fulfil the TSF; • [no other] self-tests. to demonstrate the correct operation of the TSF. Note: TD0836 has been applied. FPT_TST_EXT.1.2 The TSF shall respond to [all failures] by [rebooting]. 5.2.5.8 FPT_TUD_EXT.1 TRUSTED UPDATE FPT_TUD_EXT.1.1 The TSF shall provide Security Administrators the ability to query the currently executing version of the TOE firmware/software and [no other TOE firmware/software version]. HPE Juniper Networking, Junos 24.4R2 for MX240/480/960 Routers and EX9204/9208/9214 Switches Security Target 49 FPT_TUD_EXT.1.2 The TSF shall provide Security Administrators the ability to manually initiate updates to TOE firmware/software and [no other update mechanism]. FPT_TUD_EXT.1.3 The TSF shall provide means to authenticate firmware/software updates to the TOE using a [digital signature] prior to installing those updates. 5.2.6 TOE ACCESS (FTA) 5.2.6.1 FTA_SSL.3 TSF-INITIATED TERMINATION FTA_SSL.3.1 The TSF shall terminate a remote interactive session after a Security Administrator-configurable time interval of session inactivity. 5.2.6.2 FTA_SSL.4 USER-INITIATED TERMINATION FTA_SSL.4.1 The TSF shall allow user Administrator-initiated termination of the user’s Administrator’s own interactive session. 5.2.6.3 FTA_SSL_EXT.1 TSF-INITIATED SESSION LOCKING FTA_SSL_EXT.1.1 The TSF shall, for local interactive sessions, [ • terminate the session] after a Security Administrator-specified time period of inactivity. 5.2.6.4 FTA_TAB.1 DEFAULT TOE ACCESS BANNERS FTA_TAB.1.1 Before establishing a an administrative user session the TSF shall display a Security Administrator-specified advisory notice and consent warning message regarding unauthorised use of the TOE. 5.2.7 TRUSTED PATH/CHANNELS (FTP) 5.2.7.1 FTP_ITC.1 INTER-TSF TRUSTED CHANNEL FTP_ITC.1.1 The TSF shall be capable of using [SSH] to provide a trusted communication channel between itself and another trusted IT product authorized IT entities supporting the following capabilities: audit server, [no other capabilities] that is logically distinct from other communication channels and provides assured identification of its HPE Juniper Networking, Junos 24.4R2 for MX240/480/960 Routers and EX9204/9208/9214 Switches Security Target 50 end points and protection of the channel data from modification or disclosure and detection of modification of the channel data. FTP_ITC.1.2 The TSF shall permit [the authorized IT entities] to initiate communication via the trusted channel. FTP_ITC.1.3 The TSF shall initiate communication via the trusted channel for [no services]. 5.2.7.2 FTP_ITC.1/MACSEC INTER-TSF TRUSTED CHANNEL (MACSEC COMMUNICATIONS) FTP_ITC.1.1/MACSEC The TSF shall provide a communication channel between itself and a MACsec peer that is logically distinct from other communication channels and provides assured identification of its end points and protection of the channel data from modification or disclosure. FTP_ITC.1.2/MACSEC The TSF shall permit [the TSF, another trusted IT product] to initiate communication via the trusted channel. FTP_ITC.1.3/MACSEC The TSF shall initiate communication via the trusted channel for [communications with MACsec peers that require the use of MACsec]. 5.2.7.3 FTP_TRP.1/ADMIN TRUSTED PATH FTP_TRP.1.1/Admin The TSF shall be capable of using [SSH] to provide a communication path between itself and authorized remote Administrators users that is logically distinct from other communication paths and provides assured identification of its end points and protection of the communicated data from disclosure and provides detection of modification of the channel data. FTP_TRP.1.2/Admin The TSF shall permit remote Administrators users to initiate communication via the trusted path. FTP_TRP.1.3/Admin The TSF shall require the use of the trusted path for initial Administrator authentication and all remote administration actions. 5.3 TOE SFR DEPENDENCIES RATIONALE FOR SFRS The PP and any relevant EPs/Modules/Packages contain(s) all the requirements claimed in this ST. As such, the dependencies are not applicable since the PP has been approved. 5.4 SECURITY ASSURANCE REQUIREMENTS HPE Juniper Networking, Junos 24.4R2 for MX240/480/960 Routers and EX9204/9208/9214 Switches Security Target 51 The TOE assurance requirements for this ST are taken directly from the PP and any relevant EPs/Modules/Packages, which is/are derived from Common Criteria Version 3.1, Revision 5. The assurance requirements are summarized in Table 14. Table 14 – Security Assurance Requirements Assurance Class Assurance Components Component Description Security Target ASE_CCL.1 Conformance claims ASE_ECD.1 Extended components definition ASE_INT.1 ST introduction ASE_OBJ.1 Security objectives for the operational environment ASE_REQ.1 Stated security requirements ASE_SPD.1 Security problem definition ASE_TSS.1 TOE summary specification Development ADV_FSP.1 Basic functional specification Guidance Documents AGD_OPE.1 Operational user guidance AGD_PRE.1 Preparative procedures Life Cycle Support ALC_CMC.1 Labelling of the TOE ALC_CMS.1 TOE CM coverage Flaw Remediation ALC_FLR.1 Basic flaw remediation ALC_FLR.2 Flaw reporting procedures ALC_FLR.3 Systematic flaw remediation Tests ATE_IND.1 Independent testing – conformance Vulnerability Assessment AVA_VAN.1 Vulnerability survey 5.5 ASSURANCE MEASURES The TOE satisfied the identified assurance requirements. This section identifies the Assurance Measures applied by HPE Juniper Networking to satisfy the assurance requirements. The following table lists the details. Table 15 – TOE Security Assurance Measures SAR Component How the SAR will be met ASE_TSS.1.1C Refinement Vendor will provide information on how the TOE meets each claimed SFR. This information has been documented in detail in the subsequent section. ADV_FSP.1 The functional specification describes the external interfaces of the TOE; such as the means for a user to invoke a service and the corresponding response of those services. The description includes the interface(s) that enforces a security functional requirement, the interface(s) that supports the enforcement of a security functional requirement, and the interface(s) that does not enforce any security functional requirements. The interfaces are described in terms of their purpose (general goal of the interface), method of use (how the interface is to be used), parameters (explicit inputs to and outputs from an interface that control the behavior of that interface), parameter descriptions (tells what the parameter is in some meaningful way), and error HPE Juniper Networking, Junos 24.4R2 for MX240/480/960 Routers and EX9204/9208/9214 Switches Security Target 52 SAR Component How the SAR will be met messages (identifies the condition that generated it, what the message is, and the meaning of any error codes). AGD_OPE.1 The Administrative Guide provides descriptions of the processes and procedures on how the administrative users of the TOE can securely administer the TOE using the interfaces that provide the features and functions detailed in the guidance. AGD_PRE.1 The Installation Guide describes the installation, generation, and startup procedures so that the users of the TOE can put the components of the TOE in the evaluated configuration. ALC_CMC.1 The Configuration Management (CM) documents describe how the consumer identifies the evaluated TOE. The CM documents identify the configuration items, how those configuration items are uniquely identified, and the adequacy of the procedures that are used to control and track changes that are made to the TOE. This includes details on what changes are tracked and how potential changes are incorporated. ALC_CMS.1 ALC_FLR.1 Vendor will provide remediation procedures. ALC_FLR.2 Vendor will provide reports of security flaws and remediation procedures for them. ALC_FLR.3 Vendor will provide flaw remediation guidance for reporting security flaws. ATE_IND.1 Vendor will provide the TOE for testing. AVA_VAN.1 Vendor will provide the TOE for testing. Vendor will provide a document identifying the list of software and hardware components. HPE Juniper Networking, Junos 24.4R2 for MX240/480/960 Routers and EX9204/9208/9214 Switches Security Target 53 6. TOE SUMMARY SPECIFICATION This chapter identifies and describes how the Security Functional Requirements identified above are met by the TOE. Table 16 – TOE Summary Specification SFR Description Requirement TSS Description FAU_GEN.1 The TOE generates and stores a comprehensive set of audit logs that identify specific TOE operation whenever an auditable event occurs. Local auditing is implemented using the syslog utility. The Auditable events are specified in Table 12 – Security Functional Requirements and Auditable Events and Table 13 – Security Functional Requirements and Auditable Events/MACsec. The TOE records the following with each log entry: • date and time of the event and/or reaction • type of event and/or reaction • subject identity (where applicable) • the outcome (success or failure) of the event (where applicable). In order to identify the key being operated on, the following details are recorded for all administrative actions relating to cryptographic keys (generating, importing, changing and deleting keys): • CAK – MACsec CA name is recorded in syslog • SAK – TOE interface associated with the SAK is recorded in syslog • KEK, SAK, ICV – key references provided by process id • Username and key type - The key type (rsa/ecdsa) and the username of the associated user will be recorded when importing an SSH user public key • SSH key configured for SSH public key authentication –the hash of the public key that is to be used for authentication is recorded in syslog FAU_GEN.1/MACSEC FAU_GEN.2 The TOE ensures that each auditable event is associated with the identity of the user that triggered the event. Both the user role and username are logged. FAU_STG_EXT.1 The TOE stores audit logs locally in an audit file. Additionally, syslog can be configured to transmit audit data securely via Netconf over an SSH tunnel where the TOE is the SSH server. Audit data is transmitted to the configured syslog server in real time. The TOE is standalone. The logs are of persistent nature and these local audit logs are stored in /var/log/ in the underlying filesystem. These audit logs are automatically overwritten by newer logs as per the administrative configurable limits on storage volume. Only authorized Security Administrators are allowed to read or delete log files. These log files can be accessed using command-line interface (CLI) or via direct filesystem access, but only after successfully authentication as a Security Administrator. HPE Juniper Networking, Junos 24.4R2 for MX240/480/960 Routers and EX9204/9208/9214 Switches Security Target 54 Requirement TSS Description The TOE uses an active log file and archive files whose sizes are configurable from 64kB to 1GB, default being 1MB. When the active log file reaches its maximum size, it's compressed and archived (logfile.0.gz), and a new active log file is created thereby overwriting the old logs. Subsequent full active log files shift the archive file numbering (logfile.0.gz becomes logfile.1.gz, etc.). Upon reaching the maximum archive file limit, the oldest archive log file is purged to accommodate the newly archived log file. FCS_CKM.1 The TOE uses several cryptographic key generation schemes with different key sizes for each specific operation. The table below details the same: Key Generation Scheme SFR Key Size(s) Algorithm Usage SSH Key Generation (RSA) FCS_CKM.1, FCS_SSHS_EXT.1 FCS_SSH_EXT.1 2048-bit, 3072-bit, 4096-bit RSA Asymmetric key generation with respective hashing algorithms and curves. SSH Key Generation (ECDSA) FCS_CKM.1, FCS_SSHS_EXT.1 FCS_SSH_EXT.1 P-256, P- 384, P- 521 ECDSA FCS_CKM.2 The TOE supports one key establishment and two key generation schemes. The table below details the same: Scheme SFR(s) Usage/Service SSH EC Key Agreement FCS_CKM.2 SSH key exchange FCS_CKM.4 The TOE stores plaintext keys in volatile and non-volatile storage. Encrypted keys are stored on disk. The TOE satisfies all requirements for destruction of CSPs, plaintext secret and private cryptographic keys as specified in Table 18 – Zeroization of Keys and CSP. All descriptions of keys found in the table are consistent with the functions carried out by the TOE. There are no configurations or circumstances that may not conform to the key destruction requirements. FCS_COP.1/DataEncryption The TOE supports AES encryption and decryption used in CBC, CTR and GCM modes as specified in ISO 18033-3, ISO 10116, and ISO 19772 respectively. The AES key sizes supported are 128 and 256 bits. AES is implemented in the following protocols: SSH, MACsec. Please refer to Table 17 – CAVP Algorithm Certificate References for NIST CAVP certificate numbers for AES. FCS_COP.1/SigGen The TOE provides cryptographic signature generation and verification services in accordance with the following cryptographic algorithms: HPE Juniper Networking, Junos 24.4R2 for MX240/480/960 Routers and EX9204/9208/9214 Switches Security Target 55 Requirement TSS Description • RSA: Key sizes of 2048, 3072, or 4096 bits • ECDSA: Key sizes of 256, 384 or 521 bits FCS_COP.1/Hash The TOE supports cryptographic hashing services in accordance with SHA-1, SHA2-256, SHA2- 384 and SHA2-512 for SSHv2 protocol with message digest size of 160, 256, 384, 512. Additionally, the TOE also performs hashing while performing image integrity check during update, running self-tests and storing password. Trusted Update signature verification uses ECDSA on P-256 w/SHA-256 . Cryptographic hashing for password conditioning, password hashing, and self-testing (verifying integrity of system files) is performed using SHA256 and SHA512. FCS_COP.1/KeyedHash The TOE supports keyed-hash message authentication in accordance with HMAC-SHA-256, HMAC-SHA-512 with key sizes 256 and 512 bits and message digest sizes 256, 512 bits. The key length, hash function used, block size, and output MAC lengths are identified in the table below. Algorithm Key Length Hash function Block Size Output MAC length HMAC-SHA- 256 256 bits SHA-256 512 bits 256 bits HMAC-SHA- 512 512 bits SHA-512 1024 bits 512 bits FCS_COP.1/CMAC The TOE performs keyed-hash message authentication in accordance with AES-CMAC. The cryptographic key sizes are 128 and 256 bits. The hash function used is AES. The block size is 128 bits. The message digest size (output MAC length) is 128 bits for MACsec cryptographic operations. FCS_COP.1/MACSEC The TOE performs key wrap encryption and decryption in accordance with the AES Key Wrap mechanism specified in NIST SP 800-38F, using AES with key sizes of 128 and 256 bits. The TOE also performs data encryption and decryption using AES in Galois/Counter Mode (GCM) as specified in ISO 19772, with key sizes of 128 and 256 bits. FCS_RBG_EXT.1 All random number generation by the TOE is performed in accordance with NIST Special Publications SP 800-90A, SP 800-90B and ISO/IEC 18031:2011 using HMAC_DRBG (using HMAC-SHA-512) implemented in the OpenSSL library and kernel library. The HMAC_DRBG is seeded using a software-based entropy source (bits 2-9 of the timestamp of the software interrupts associated with the clock0 (RANDOM_SWI_CLOCK0) as the primary entropy source) implemented in accordance with NIST Special Publication SP 800- 90B producing 448 bits of calculated min-entropy. Additionally, SHA-256 and SHA-512 are implemented in the LibMD library and used for password hashing by Junos’ MGD daemon. The appliance is to be operated with FIPS mode enabled. HPE Juniper Networking, Junos 24.4R2 for MX240/480/960 Routers and EX9204/9208/9214 Switches Security Target 56 Requirement TSS Description FCS_SSH_EXT.1 The TOE implements SSH server for remote administration that complies with RFCs 4251, 4252, 4253, 4254, 4344, 5647, 5656, 6668, 8308, and 8332. The TOE can be configured to accept public-key based authentication, keyboard-interactive or password-based authentication. In accordance with RFC 4252, the TOE supports password-based authentication. The TSF prompts the user for a case-sensitive password. The input is masked during entry and compared against the stored credentials using a secure hash-based comparison. The TOE supports public key authentication as defined in RFC 4252. The TSF verifies the digital signature provided by the SSH client against the authorized public keys stored on the TOE. The following public key algorithms are supported: • RSA: ssh-rsa (RFC 4253), rsa-sha2-256, and rsa-sha2-512 (RFC 8332). • ECDSA: ecdsa-sha2-nistp256, ecdsa-sha2-nistp384, and ecdsa-sha2- nistp521 (RFC 5656). The TOE supports the Keyboard-interactive authentication method by default and requires no configuration to be enabled. Since AAA server that would be required to facilitate multifactor authentication for this method is not in scope, this method is functionally similar to password-based authentication, and hence only requires a password to be configured for the user. The TOE does not require multiple authentication mechanisms for users. “Large packets” are defined as the packets that are greater than 256K bytes in an SSH transport connection. SSH packets greater than 256k bytes, when detected by the TOE are dropped and the connection is terminated. The TOE supports the following algorithms for its SSH implementations: • AES-CBC, AES-GCM@openssh.com and AES-CTR encryption algorithms with key sizes of 128 bits and 256 bits. The TOE does not support the “none” cipher. • SHA1, SHA2-256, SHA2-384, and SHA2-512 algorithms for hashing. • HMAC-SHA-256, HMAC-SHA-512 and AES_GCM (implicit) for keyed- hashing. The TOE supports keys generated in accordance with “ssh-rsa”, “rsa-sha2- 256”, “rsa-sha2-512”, “ecdsa-sha2-nistp256”, “ecdsa-sha2-nistp384” or “ecdsa-sha2-nistp521”. Key exchange is performed only using one of the supported key exchange algorithms, which are ordered as follows: ecdh-sha2-nistp256, ecdh-sha2- nistp384, ecdh-sha2-nistp521 (all specified in RFC 5656). HPE Juniper Networking, Junos 24.4R2 for MX240/480/960 Routers and EX9204/9208/9214 Switches Security Target 57 Requirement TSS Description The TSF uses the SSH KDF, as specified in RFC 5656 (Section 4), to derive the session keys from the shared secret value (K) established during the Key Exchange (KEX) process. SSH rekeying is triggered by exceeding either time or data thresholds. Administrators can configure the specific threshold that initiates rekeying. The time limit for rekeying can be set from 1 to 1440 minutes (24 hours). The data limit for rekeying can be set from 51200 to 4294967295 bytes (0.5MB to 4GB). FCS_MACSEC_EXT.1 The TOE's MACsec functionality is implemented in full accordance with the IEEE 802.1AE-2018 standard, encompassing all mandatory and recommended requirements. Secure channel is identified by Secure Channel Identifier (SCI) that is comprised of a globally unique peer MAC address and its 16-bit Port Identifier, unique within the system that has been allocated that address. SCI (8 octets) is appended to every MKPDU packet and the TOE can be configured to enforce SCI tagging such that packets are rejected if they do not have a valid SCI. The TSF enforces a strict filter on all interfaces where MACsec is enabled. The TSF is configured to permit only the following three EtherTypes: 1. EAPOL (0x888E): The TSF permits EAPOL frames to facilitate the MKA protocol. These frames are used for peer discovery, authentication, and the distribution of SAKs. 2. MACsec (0x88E5): The TSF permits MACsec frames, which represent the encrypted and integrity-protected data traffic between authorized peers. 3. MAC Control (0x8808): the TSF permits MAC control frames to allow essential link-layer functions such as Ethernet Flow Control. These frames are processed by the MAC layer to ensure link stability. The TSF evaluates the EtherType field of every incoming frame at the ingress port. If a frame’s EtherType does not match one of the three permitted values listed above, the TSF identifies the frame as unauthorized and immediately discards it. Also, a filter in PFE traps the packets to RE with ether type 88-8E. FCS_MACSEC_EXT.2 Each MACsec Key Agreement protocol data unit (MKPDU) transmitted is integrity protected by a 128-bit Integrity Check value (ICV), generated by AES- CMAC using the Integrity Check value Key (ICK). The ICV Key (ICK) is derived from CAK (using AES_CMAC). The Integrity Check Value (ICV) of MACsec protocol data units (MPDUs) is calculated using the SAK over the destination address, source address, SecTAG, and user data (after encryption, if applicable) and is encoded in the last eight to sixteen octets of the MPDU. The length of the ICV is between 8 and 16 octets, depending on the Cipher Suite. The 64 most significant bits of HPE Juniper Networking, Junos 24.4R2 for MX240/480/960 Routers and EX9204/9208/9214 Switches Security Target 58 Requirement TSS Description the 96-bit IV used in generating the ICV are the octets of the SCI, and the 32 least significant bits of the 96-bit IV are the octets of the PN. MACsec allows IPv4/v6 and TCP/UDP headers to be unencrypted while the rest of the frame is encrypted. The offset value for MACsec protected frames are: Offset 0 – Default; Encrypts the entire MPDU payload in the frame Offset 30 – IPv4 & TCP/UDP headers are unencrypted, and rest of the payload is encrypted Offset 50 – IPv6 & TCP/UDP headers are unencrypted, and rest of the payload is encrypted FCS_MACSEC_EXT.3 SAK is generated using KDF function AES-CMAC-128 or AES-CMAC-256 based on the cipher suite configured using the following transform function: SAK = KDF (Key, Label, KS-nonce | MI-value list | KN, SAKlength) where, • Key= CAK • Label= “IEEE8021 SAK” • KS-nonce = a nonce of the same size as the required SAK, obtained from an RNG each time an SAK is generated. • MI-valuelist = a concatenation of MI values from all live participants • KN = four octets, the Key Number assigned by the Key Server as part of the KI • SAKlength = two octets representing an integer value (128 for a 128 bit SAK, 256 for a 256 bit SAK) with the most significant octet first. The strength of the session protected by the CAK is determined by the strength of the underlying AES algorithm and its standard key length. Using AES-128 means a 128-bit CAK and a 2128 key space. Using AES-256 means a 256-bit CAK and a 2256 key space. The KDF function for generation of SAK is in compliance with IEEE 802.1X- 2020 (Section 9.8.1). For CAK length and strength, it is based on the cipher suite configured on the TOE (AES_GCM 128/256). RNG is used for nonces on the TOE. FCS_MACSEC_EXT.4 SAK distribution is managed via the MKA protocol. The TSF, acting as a Key Server, generates a 128-bit or 256-bit SAK for the Secure Association. Before this key is sent to the peer, the TSF protects the SAK's by applying the AES Key Wrap function as specified in FCS_COP.1/MACSEC. The encryption key for this wrap operation is a KEK derived from the CAK (which is associated with a specific CKN). FCS_MKA_EXT.1 Each MACsec Key Agreement (MKA) protocol data unit (MKPDU) transmitted is integrity protected by a 128 bit Integrity Check value (ICV), generated by AES- CMAC using the Integrity Check value Key (ICK). The ICV Key (ICK) is derived from CAK (using AES_CMAC). The TOE is in compliance with IEEE 802.1X-2020 and 802.1Xbx2014 for MKA, including the values for MKA and Hello timeout limits and support for data delay protection. The TOE has a mka-hello-timeout of 2 seconds. The TOE HPE Juniper Networking, Junos 24.4R2 for MX240/480/960 Routers and EX9204/9208/9214 Switches Security Target 59 Requirement TSS Description has a MKA lifetime of 6 seconds. The TOE has a sak-rekey-interval between 60 and 86400 seconds. Group CAK is not supported. Pairwise CAKs which are PSKs are supported by the TOE. The TSF actively manages membership changes within the Pairwise CA. The TSF monitors the "Live" status of its peer using two primary timers: MKA Hello and MKA Lifetime. If the TSF detects a membership change the elected Key Server automatically distributes a fresh SAK. This ensures that the data-plane encryption is refreshed immediately upon any change to the secure session's participants. For MKPDU’s to be valid, they must meet the following criteria: • Must be from a recognized peer • Must match current CAK/CKN • Must pass integrity check (ICV) • Must not be replayed (sequence number check) Invalid MKPDU’s can be any of the following: • Come from unknown/untrusted peers • Have bad syntax • Have expired lifetimes or fail ICV check • Are duplicate or replayed packets FCS_NTP_EXT.1 The TOE uses NTP v4 and uses SHA1 and SHA256 for authenticating time stamps received. The NTP sources are defined by the Security Administrator. Up to three sources can be configured. NTPv4 is implemented on the TOE using the libntp and libntpopts libraries. Time updates from a broadcast and multicast address are not supported by the TOE. The TOE uses the combination of the configured IP address alongside the SHA1/SHA256 hash algorithm to properly authenticate the NTP server. If either of these values are not correct, the NTP server will not synchronize with the TOE until the proper authentication configuration is set. FIA_AFL.1 The TOE supports SSH for remote administrative actions. Each unsuccessful authentication attempt is detected and tracked by the TOE. SSH login retries are enabled after the first failed authentication attempt for a username. The maximum number of authentication attempts permitted before SSH connection termination and lockout enforcement is configurable via tries- before-disconnect parameter. This parameter supports a range of 1 to 10, as defined in the CLI. Exceeding this threshold results in user account lockout, preventing further SSH login attempts until a TOE’s administrator unlocks it or the administrator-configured “lockout-period” (1 to 43,200 minutes) expires. Even when an account is locked for remote access to the TOE, an administrator is always able to login locally through the serial console. FIA_PMG_EXT.1 The TOE supports password management capabilities for administrative passwords. Passwords may be composed of any combination of upper and lower-case letters, numbers, specific special characters which include: [ “!”, “@”, “#”, “$”, “%”, “^”, “&”, “*”, “(“, “)”,“?”, “~”, “,”, “.”, “/”, “:”, “;”, “_”, HPE Juniper Networking, Junos 24.4R2 for MX240/480/960 Routers and EX9204/9208/9214 Switches Security Target 60 Requirement TSS Description “+”, “-“, “=”, “{“, “}”, “[“, “]”, “|”, “<”, “>”, “ ” ”, “ ‘ ”, “ \ “, “ ` “]. The minimum password length is configurable by the Administrator. with a range of 06 to 20 characters and a default value of 10. FIA_UIA_EXT.1 The TOE requires all users to be successfully identified and authenticated as an administrator before allowing any TSF mediated actions to be performed. Access to the TOE is facilitated through directly connecting to the TOE through serial console or remotely connecting to the TOE through SSHv2. Every user that attempts to authenticate is first provided with non- administrative access with limited viewing functionalities. The user may then authenticate as an administrator with the right credentials to gain access to security functions. Regardless of the interface at which the administrator interacts, the TOE prompts the user for a credential. Only after the administrative user presents the correct authentication credentials will they be granted access to the TOE administrative functionality. No TOE administrative access is permitted until an administrator is successfully identified and authenticated. For remote administration, the TOE supports public key authentication and password-based authentication over SSHv2. This login process identifies and authenticates the user using PAM operations. The login process does two things; it first establishes that the requesting user is whom they claim to be and second provides them with an interactive Junos Command interactive command line interface (CLI). If the remote user uses public key-based authentication, the SSH daemon would look up for the user’s public key in the authorized keys file located in the directory ‘.ssh’ in the user’s home directory (i.e. ‘~/.ssh/’) and this authentication method will be attempted before any other if the user has a key available. If the key is found in the authorized keys file, the user is granted access to the TOE. If the user uses password-based authentication and they provide valid username and password, then user is granted access to the TOE. If the user enters invalid user credentials, they will not be granted access. For local TOE administration through console, administrators are presented with password-based authentication and are only granted access to TOE after entering correct user credentials. The only available actions before remote administrator authentication is displaying the warning banner in accordance with FTA_TAB.1 and responding to ICMP echo requests. The only available action before local administrator’s action is to display the warning banner. FIA_UAU.7 None. FIA_PSK_EXT.1 To enable MACsec encryption using bit-based Pre-Shared Keys, administrators must configure each device on a point-to-point link with a unique identifier called the 'Connectivity Association Key Name' (CKN) and a secret key known as the 'Connectivity Association Key' (CAK). This same CKN and CAK pair must be manually entered on both ends of the link. The HPE Juniper Networking, Junos 24.4R2 for MX240/480/960 Routers and EX9204/9208/9214 Switches Security Target 61 Requirement TSS Description devices (TOE and its peer device) then use this shared secret (the CAK, identified by the CKN) to verify each other's identity and establish a secure MACsec connection. The TSF accepts bit-based pre-shared keys entered as a string of up to 64 hexadecimal characters. FMT_MOF.1/ManualUpdate Performing firmware updates on the TOE is restricted to authorized Security Administrators only. FMT_MOF.1/Functions The syslog server can be configured by the administrator on the TOE to transmit audit logs securely in real time via Netconf over SSH. Local audit logs reside in /var/log on the filesystem. Log file access, deletion, and archiving are restricted to authenticated Security Administrators via the CLI or direct filesystem access. The TOE manages audit data through an automated rotation system that archives the active log once it reaches a configurable size (up to 1 GB). The system maintains a set number of compressed archives (1–1000), systematically renaming older files and deleting the oldest once the storage limit is reached. To prevent data loss, the TSF monitors storage capacity, alerting administrators at 92% occupancy while utilizing reserved blocks to continue logging. If storage is completely exhausted, the system logs a final "No space left on device" entry and terminates the logging service, though the device itself remains operational. Administrators can configure these storage limits on the TOE. The TOE allows administrators to modify the behaviour of the following administrative functions using CLI commands: • transmission of audit data to an external IT entity – using the ‘system services netconf’ configuration hierarchy. • handling of local audit data– using the ‘system syslog’ configuration hierarchy. FMT_MOF.1/Services The Security Administrator has the capability to: • Start/stop and modify the behaviour of the trusted communication channel to external syslog server using the ‘system services netconf’ hierarchy command. • Start/stop and modify the behaviour of the trusted communication path for remote administrative sessions (SSH) using the ‘system services ssh’ hierarchy command. • Start/Stop and modify the behaviour of the trusted communication channel with MACsec peers using the ‘security macsec’ hierarchy commands. FMT_MTD.1/CoreData The TOE restricts the ability to manage the TOE to Security Administrators. Administrative users are required to login before being provided with access to any administrative functions. Non-security administrators are not allowed to modify any TOE functions. No interface is available to an unauthenticated user except the login prompt. Any commands used to modify TOE functions are not made available to non-administrative users and its attempt to use them will result in an invalid action error. HPE Juniper Networking, Junos 24.4R2 for MX240/480/960 Routers and EX9204/9208/9214 Switches Security Target 62 Requirement TSS Description FMT_MTD.1/CryptoKeys The Security Administrator can manage the following keys, with the specified operations available: • SSH Keys (ECDSA, RSA): Import, modification, and deletion. These SSH Key operations are performed using the system services ssh and system login user authentication hierarchies. • Pre-shared CAKs: Configuration (which includes configuration, modification, and deletion). These Pre-Shared CAK operations are performed using the security macsec connectivity-association pre-shared-key cak hierarchy. FMT_SMF.1 The available management functions are listed below and these can be accessed via the SSH remotely or locally via console: • 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 • Ability to start and stop services • Ability to configure local audit behaviour • Ability to modify the behaviour of the transmission of audit data to an external IT entity • Ability to manage the cryptographic keys • Ability to configure the cryptographic functionality • Ability to configure thresholds for SSH rekeying • Ability to re-enable an Administrator account • Ability to configure the local session inactivity time before session termination or locking • Ability to configure the authentication failure parameters for FIA_AFL.1 • Ability to set the time which is used for timestamps • Ability to configure NTP • Ability to administer the TOE locally • Ability to manage the trusted public keys database The local interface of the TOE can be accessed directly through a serial port connection. The presence of a system variable called "SSH_CONNECTION" is used to determine whether the connection to the TOE is local (via serial) or remote (via SSH). This variable is present during SSH connections and absent during console access. The TOE logs all events and stores them in a local file using syslog configuration. For more details about the TOE’s logging system (refer to TSS subsection: FAU_STG_EXT.1). FMT_SMF.1/MACSEC The available management functions are listed below, and these can be accessed via the SSH remotely or locally via console: HPE Juniper Networking, Junos 24.4R2 for MX240/480/960 Routers and EX9204/9208/9214 Switches Security Target 63 Requirement TSS Description • Ability to generate a PSK and install it in the device • Ability to manage the Key Server to create, delete, and activate MKA participants using the CLI commands • Ability to specify the lifetime of a CAK • Ability to enable, disable, or delete a PSK-based CAK using CLI commands FMT_SMR.2 The TOE supports a Security Administrator role, administrable locally or remotely, responsible for provisioning user accounts. The TOE also supports a self-explanatory ‘ready-only’ role, which only has view permissions for the TOE configuration and operational state (show commands). Only Security Administrator accounts, associated with the "security-admin" login class and its requisite permissions, can manage the TOE. User accounts comprise a username, password, and role (privilege). System access via the console or SSHv2 is granted to the administrator only after successful identification and authentication. Administrators can manually create other custom login classes and allocate admin privileges to it. FPT_SKP_EXT.1 The TOE does not provide a CLI interface to permit the viewing of keys. Cryptographic keys are protected through the enforcement of kernel-level file access rights, limiting access to the contents of cryptographic key containers to processes with cryptographic rights or shell users with root permission. Table 18 includes additional information on key storage and protection of non- plaintext keys. FPT_APW_EXT.1 The TOE stores all password authentication data in a secure directory that is not accessible to any TOE’s user. Passwords are obscured from the user on both local and remote CLI interfaces. The TSF protects administrative passwords by ensuring they are never stored in plaintext. When a password is created or updated, the TSF processes it using a Modular Crypt Format (MCF), which incorporates a unique salt and a SHA256 or SHA512 hash algorithms. FPT_TST_EXT.1, FPT_FLS.1 The TOE runs the following set of self-tests during power on to check the correct operation of the Junos OS firmware: • Power on test – determines the boot-device responds, and performs a memory size check to confirm the amount of available memory. • File integrity test – verifies the integrity of all mounted signed packages, ensuring that system files have not been tampered with. To test the integrity of the firmware, the SHA‑256 fingerprints of executables and other immutable files are recalculated and verified using the ECDSA P‑256 digital signature against the signed fingerprints contained in the manifest file. • Crypto integrity test – checks integrity of major CSPs, such as SSH hostkeys, passwords, and various keys. The test can be run on demand. This test calculates the SHA-256 hash of files in the TOE directory and compares each of them against a stored value in a file with the same file name and the changed extension. If any of the calculated hashes does not match, the test fails. This behaviour is the same across all platforms. HPE Juniper Networking, Junos 24.4R2 for MX240/480/960 Routers and EX9204/9208/9214 Switches Security Target 64 Requirement TSS Description • Simulated veriexec error – verifies that the veriexec file integrity enforcement framework is enabled and operates as expected using /opt/sbin/kats/cannot-exec.real, which triggers an intentional failure and verifies that it gets detected. • Crypto self-tests (Kernel, libmd, OpenSSL and MACsec libraries) for SSH and MACsec – verifies correct output from known answer tests for all cryptographic algorithms. • Noise Source Health Test - Noise source health tests - verify the correct operation of the noise source. Tests include a repetitive count test and an adaptive proportion test. Self-tests demonstrating the correct operation of the TSF on the TOE are performed during initial start-up (power-on) to verify the integrity of the TOE firmware and software. Self-tests are also performed prior to providing any cryptographic service to verify the correct operation of cryptographic implementations necessary to fulfill the TSF. These NIST-approved self-tests cover all cryptographic primitives and security-critical TSF components and are executed before any security function is used, they provide a complete and reliable demonstration that the TSF is operating correctly. If one of the self-tests fail, the device panics and reboots continuously. The TOE’s administrator can recover the device by performing a fresh installation of Junos using a bootable USB drive created from a USB-compatible Junos image. FPT_TUD_EXT.1 Security Administrators are able to query the current version of the TOE firmware using the CLI command “show version”. The TOE does not support delayed activation or partial updates for the TOE. If a new version of the TOE firmware is available an update of the TOE firmware can be initiated. Updates are downloaded and applied manually. The installable firmware package containing the TOE firmware has a digital signature that is checked when the Security Administrator attempts to install the package. The TOE uses Juniper “Veriexec” to verify the package integrity. The hash signature is verified using public key during package installation. If the image fails the signature check, then the image is deleted from the device and no upgrade occurs, with the appropriate error visible on the CLI. Successful update is only initiated when the signature verification of the TOE passes. Logs are generated in both cases. The TOE does not support automatic updates. FPT_STM_EXT.1 All the audit events recorded by TOE are timestamped. The clock function of the TOE provides a source of date and time information for the appliance, used in audit timestamps, which is maintained using the hardware Time Stamp Counter as the clock source. Time on the TOE can be configured manually by the security administrator along with support for synchronization to NTP servers. Timestamps are also used for security relevant items such as rekey thresholds, inactivity timeouts and account lockouts. FPT_CAK_EXT.1 The TOE protects each CAK by wrapping it with AES‑256 in GCM mode using a System Master Key derived from the System Master Password. The TOE HPE Juniper Networking, Junos 24.4R2 for MX240/480/960 Routers and EX9204/9208/9214 Switches Security Target 65 Requirement TSS Description stores all this information in a secure directory (config file) that is not accessible to administrators or other non-admin roles. Cryptographic keys are protected through the enforcement of kernel-level file access rights, limiting access to the contents of cryptographic key containers to processes with cryptographic rights or shell users with root permission. FPT_RPL.1 To protect against replay (within the Control Plane) each participant in the protocol chooses a random 96-bit member identifier (MI) when MKA begins, and this MI is used, together with a 32-bit message number (MN) initialized to 1 and incremented with each MKPDU transmitted. To prevent replay attacks, the TOE verifies that each incoming MKPDU contains a unique and incremented MN. Any MKPDU featuring a duplicate or outdated MN is discarded and an error message is logged immediately by the TSF. The Data Plane replay functionality ensures that a man-in-the middle cannot replay a snooped packets or reuse packet numbers. As bounded receive delay functionality is not supported, it is necessary to configure replay protection in the evaluated configuration using replay-protect. The replay- window-size specifies the number of packets which can be replayed. If set to zero this means no replays are permitted (and should not be used when out of ordering is expected). FTA_SSL.3, FTA_SSL.4, FTA_SSL_EXT.1 User sessions, both remote and local, with the TOE can be terminated by users. The administrative user can logout from the TOE using CLI by typing “exit” in operational mode to terminate the session. The TOE makes the current contents unreadable after the admin initiates termination. No user activity can take place until the user re-identifies and authenticates. User sessions, both remote and local, with the TOE can also be terminated due to inactivity (time threshold). Security Administrators can configure this inactivity timer on user sessions. This setting is controlled by the idle- timeout parameter, which ranges from 0 to 4,294,967,295 minutes. Administrators can configure this inactivity timer via the CLI. Once the set inactivity period is crossed the user would be logged out from the TOE and the session would be terminated. For each user session, the TOE maintains a count of clock cycles (provided by the system clock) since the last user activity. The count is reset each time the user performs any activity within the session. When the counter reaches the number of clock cycles equating to the configured period of inactivity, the user session is terminated. FTA_TAB.1 The TOE can be accessed for administrative purposes either locally via console (CLI) or remotely using SSH (CLI). For both local and remote methods of access, the TOE provides an access banner prior to login, with the authentication prompt. The banner can be configured by the security administrator for both local and remote login methods. The banner can provide warnings against unauthorized access to the secure TOE as well as any other information that the Security Administrator wishes to communicate. HPE Juniper Networking, Junos 24.4R2 for MX240/480/960 Routers and EX9204/9208/9214 Switches Security Target 66 Requirement TSS Description FTP_ITC.1, FTP_ITC.1/MACSEC The TOE supports SSHv2 via public key authentication for trusted channel implementation to syslog server. Additionally, the TOE implements the MACsec protocol for the protection of layer 2 communications between itself and authenticated MACsec peers. The TOE provides trusted channels using SSHv2 protocol which ensures the confidentiality and integrity of communication with the remote audit server (syslog server). The TOE acts as an SSH server when connecting with the configured syslog server. Export of audit information to a secure, remote server is achieved by setting up an event trace monitor that sends event log messages by using NETCONF over SSH to the remote system event logging server. The SSHv2 protocol ensures that the data transmitted over a SSH session cannot be disclosed or altered by using the encryption and integrity mechanisms of the protocol with the FIPS cryptographic module. FTP_TRP.1/Admin The TOE supports remote administration using SSH. A trusted path is provided by the TOE using SSHv2 protocol between itself and remote administrators so that the contents of administrative sessions are protected against unauthorized disclosure or modification. Remote administrators can initiate communication to the TOE’s CLI through the SSH tunnel created by the SSH session. Assured identification is guaranteed by using password or public key-based authentication mechanisms. The SSHv2 protocol ensures that the data transmitted over a SSH session cannot be disclosed or altered by using the encryption and integrity mechanisms of the protocol with the FIPS cryptographic module. 6.1 CAVP ALGORITHM CERTIFICATE DETAILS Each of these cryptographic algorithms have been validated as identified in the table below. Table 17 – CAVP Algorithm Certificate References SFR Algorithm Description Implementation name CAVP Alg. CAVP Cert # FCS_CKM.1 RSA schemes using cryptographic key sizes of [2048, 3072, and 4096 bits] that meet the following: FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Appendix B.3 or FIPS PUB 186-5, "Digital Signature Standard (DSS)", A.1; Junos 24.4R1 OpenSSL RSA KeyGen (FIPS186-5) Modulo: 2048, 3072, 4096 A6978 ECC schemes using ‘NIST curves’ [selection: P-256, P- 384, P-521] that meet the Junos 24.4R1 OpenSSL ECDSA KeyGen (FIPS186-5) A6978 HPE Juniper Networking, Junos 24.4R2 for MX240/480/960 Routers and EX9204/9208/9214 Switches Security Target 67 following: FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Appendix B.4, or FIPS PUB 186-5, “Digital Signature Standard (DSS)”, Appendix A.2, or ISO/IEC 14888-3, “IT Security techniques - Digital signatures with appendix - Part 3: Discrete logarithm based mechanisms”, Section 6.6.; Curves: P-256, P- 384, P-521 ECDSA KeyVer (FIPS186-5) Curves: P-256, P- 384, P-521 FCS_CKM.2 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” Junos 24.4R1 OpenSSL KAS-ECC-SSC Sp800-56Ar3 Domain Parameter Generation Methods: P-256, P- 384, P-512 A6978 FCS_COP.1/ DataEncryp tion AES used in [CBC, CTR, GCM] mode and cryptographic key sizes [128 bits, 256 bits] [CBC as specified in ISO 10116, CTR as specified in ISO 10116, GCM as specified in ISO 19772]. Junos 24.4R1 OpenSSL AES-CBC Key Length: 128, 256 AES-CTR Key Length: 128, 256 AES-GCM Key Length: 128, 256 A6978 Juniper Penta Silicon AES-GCM Key Length: 128, 256 A4708 AES ECB 128bit & 256bit Encryption/Decrypti on Engine AES 4550 FCS_COP.1/ SigGen For RSA schemes: FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Section 5.5, using PKCS #1 v2.1 or FIPS PUB 186-5, "Digital Signature Standard (DSS)", Section 5.4 using PKCS #1 Junos 24.4R1 OpenSSL RSA SigGen (FIPS186-5) Modulo: 2048, 3072, 4096 RSA SigVer (FIPS186-5) A6978 HPE Juniper Networking, Junos 24.4R2 for MX240/480/960 Routers and EX9204/9208/9214 Switches Security Target 68 v2.2 Signature Schemes RSASSA-PSS and/or RSASSA- PKCS1v1_5; ISO/IEC 9796-2, Digital signature scheme 2 or Digital Signature scheme 3, Modulo: 2048, 3072, 4096 For ECDSA schemes implementing [selection: P- 256, P-384, P-521] curves that meet the following: FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Section 6 and Appendix D, Implementing “NIST Recommended" curves”; or FIPS PUB 186-5, "Digital Signature Standard (DSS)", Section 6 and NIST SP 800- 186 Section 3.2.1, Implementing Weierstrass curves; or ISO/IEC 14888-3, "IT Security techniques - Digital signatures with appendix - Part 3: Discrete logarithm based mechanisms", Section 6.6. Junos 24.4R1 OpenSSL ECDSA SigGen (FIPS186-5) Curves: P-256, P- 384, P-521 ECDSA SigVer (FIPS186-5) Curves: P-256, P- 384, P-521 A6978 FCS_COP.1/ Hash [SHA-1, SHA-256, SHA-384, SHA-512] and message digest sizes [160, 256, 384, 512] bits that meet the following: ISO/IEC 10118- 3:2004. Junos 24.4R1 OpenSSL SHA-1, SHA2-256, SHA2-384, SHA2- 512 A6978 Junos 24.4R1 LibMD SHA2-256, SHA2- 512 A6975 FCS_COP.1/ KeyedHash [HMAC-SHA- 256, HMAC- SHA-512] and cryptographic key sizes [256 and 512 bits] and message digest sizes [256, 512] bits that meet the following: ISO/IEC 9797- 2:2011, Section 7 “MAC Algorithm 2”. Junos 24.4R1 OpenSSL HMAC-SHA2- 256, HMAC-SHA2-512 A6978 FCS_RBG_E XT.1 HMAC_DRBG [SHA-512] in accordance with ISO/IEC 18031:2011 MX and EX Junos 24.4R1 Kernel HMAC DRBG Mode: SHA2-512 A7045 HPE Juniper Networking, Junos 24.4R2 for MX240/480/960 Routers and EX9204/9208/9214 Switches Security Target 69 FCS_COP.1. 1/CMAC cryptographic algorithm [AES-CMAC] and cryptographic key sizes [128, 256 ] bits and message digest size of 128 bits that meets the following: [NIST SP 800-38B] Junos 24.4R1 Macsec AES-CMAC Key Length: 128, 256 A6976 FCS_COP.1. 1/MACSEC cryptographic algorithm [AES used in AES Key Wrap, GCM] and cryptographic key sizes [128, 256 ] bits that meets the following: [AES as specified in ISO 18033-3, AES Key Wrap as specified in NIST SP 800- 38F, GCM as specified in ISO 19772]. Junos 24.4R1 Macsec AES-KW Key Length: 128, 256 A6976 AES ECB 128bit & 256bit Encryption/Decrypti on Engine AES-GCM Key Length: 128, 256 AES 4550 Juniper Penta Silicon A4708 6.2 CRYPTOGRAPHIC KEY DESTRUCTION The table below describes the key zeroization provided by the TOE and as referenced in FCS_CKM.4. Table 18 – Zeroization of Keys and CSP Keys/CSPs Purpose Method of storage Storage Location Method of Zeroization SSH Private Host Key The first time SSH is configured, the key is generated. Used to identify the host. Plaintext File format on SDD single overwrite consisting of zeroes using the CLI command: “request vmhost zeroize no- forwarding” Loaded into memory to complete session establishment Plaintext Memory Memory free() operation is performed by Junos upon session termination SSH Session Key Session keys used with SSH, AES 128, 256, hmac-sha2- 256 or hmac-sha2- 512 key (256 or 512), DH Private Plaintext Memory Memory free() operation is performed by Junos upon session termination HPE Juniper Networking, Junos 24.4R2 for MX240/480/960 Routers and EX9204/9208/9214 Switches Security Target 70 Keys/CSPs Purpose Method of storage Storage Location Method of Zeroization Key (Elliptic curve 256/384/521-bits). Derived dynamically during each SSH session via SSH KDF. User Password Plaintext value as entered by user Plaintext as entered Processed in Memory Memory free() operation is performed by Junos upon completion of authentication Hashed when stored (SHA256 and SHA512) Stored on disk single overwrite consisting of zeroes using the CLI command: “request vmhost zeroize no- forwarding” RNG State Internal state and seed key of RNG. Originates during instantiation when the DRBG initializes its internal state variables using seed material harvested from the noise source. Plaintext Memory Handled by kernel, overwritten with zero’s at reboot. MACsec CAK Pre-shared, static Connectivity Association Key. Defined statically through manual administrative configuration as a PSK. Encrypted using GCM-AES-256 using System Master Password Stored in config file single overwrite consisting of zeroes using the CLI command: “request vmhost zeroize no- forwarding” MACsec SAK Security Association Key. Generated using AES-CMAC-128 or AES-CMAC-256 KDF function based on the configured cipher suite during Plaintext Memory Memory free() operation is performed by Junos upon session termination HPE Juniper Networking, Junos 24.4R2 for MX240/480/960 Routers and EX9204/9208/9214 Switches Security Target 71 Keys/CSPs Purpose Method of storage Storage Location Method of Zeroization MKA session initialization. MACsec KEK Key Encryption Key. Derived from the CAK during the MKA session initialization. Plaintext Memory Memory free() operation is performed by Junos upon session termination MACsec ICK Integrity Check Key. Derived from CAK using AES_CMAC KDF during MKA session initialization. Plaintext Memory Memory free() operation is performed by Junos upon session termination System Master Password Password used to derive encryption key used for protecting MACsec CAK. Originates during initial system provisioning. Plaintext disk single overwrite consisting of zeroes using the CLI command: “request vmhost zeroize no- forwarding” HPE Juniper Networking, Junos 24.4R2 for MX240/480/960 Routers and EX9204/9208/9214 Switches Security Target 72 7. ACRONYM TABLE Acronyms should be included as an Appendix in each document. Table 19 – Acronyms Acronym Definition AES Advanced Encryption Standard CC Common Criteria CRL Certificate Revocation List DTLS Datagram Transport Layer Security EP Extended Package GUI Graphical User Interface IP Internet Protocol NDcPP Network Device Collaborative Protection Profile NIAP Nation Information Assurance Partnership NTP Network Time Protocol OCSP Online Certificate Status Protocol PP Protection Profile RSA Rivest, Shamir & Adleman SFR Security Functional Requirement SSH Secure Shell ST Security Target TOE Target of Evaluation TLS Transport Layer Security TSS TOE Summary Specification ICV Integrity Check Value MKPDU MACsec Key Protocol Data Unit TSF TOE Security Functions IEEE Institute of Electrical and Electronics Engineers CAK Connectivity Association Key MKA MACsec Key Agreement PSK Pre-Shared Key SAK Secure Association Key ICK Integrity Check Key KDF Key Derivation Function MAC Media Access Control CKN Connectivity Association Key Name NIST National Institute of Standards and Technology HPE Juniper Networking, Junos 24.4R2 for MX240/480/960 Routers and EX9204/9208/9214 Switches Security Target 73 Acronym Definition CAVP Cryptographic Algorithm Validation Program VLAN Virtual Local Area Network MPD MACsec Protocol Data MPDU MACsec Protocol Data Unit SCI Secure Channel Identifier EAPOL Extensible Authentication Protocol over LAN GCM Galois/Counter Mode ISO International Organization for Standardization PFE Packet Forwarding Engine RE Routing Engine PoE Power over Ethernet LLDP Link Layer Discovery Protocol DHCP Dynamic Host Configuration Protocol ARP Address Resolution Protocol STP Spanning Tree Protocol EAP Extensible Authentication Protocol LAN Local Area Network SA Security Association Tx Transmit Rx Receive