Juniper Networks EX, QFX and ACX Series

Certificate

Approved Algorithms (22)

Security Levels (Table 1)

Derived Review-Risk Graph (review prompts, not findings)

flowchart LR
  %% Deterministic review-risk graph for Juniper Networks EX, QFX and ACX Series
  %% Review prompts and evidence gaps, NOT vulnerability findings.
  subgraph CMVP["CMVP-disclosed clues"]
    C2["[high] Firmware update / recovery<br/>/ rollback services<br/><i>Soft Error State</i>"]
    C3["[high] Unauthenticated /<br/>self-test / status service<br/>surface<br/><i>Enc/Dec (SSH)<br/>Show status<br/>Local reset</i>"]
    C4["[high] Physical/logical<br/>interfaces (some 'blocked<br/>in firmware')<br/><i>Serial<br/>USB</i>"]
    C5["[low] Protocol / secure-channel<br/>references (may be KDF<br/>names, not a live channel)<br/><i>TLS<br/>SSH<br/>IPSEC</i>"]
    C6["[low] Operating system / runtime<br/>referenced (boundary<br/>membership not asserted)<br/><i>operating system<br/>kernel</i>"]
  end
  subgraph Inference["Derived inference"]
    I2["Trusted code is reachable<br/>through update and<br/>recovery paths."]
    I3["Some services may process<br/>input before, or without,<br/>operator authentication."]
    I4["Interface reachability may<br/>vary by boot stage and<br/>lifecycle state."]
    I5["Possible only, a protocol<br/>is referenced, but whether<br/>it is a live channel or<br/>only a KDF/algorithm name<br/>is unconfirmed."]
    I6["Possible only, a<br/>runtime/OS is referenced,<br/>but its membership in the<br/>cryptographic boundary is<br/>not established."]
  end
  subgraph Risk["Reviewer question"]
    R2["Are update images<br/>authenticated before<br/>parsing, and are<br/>downgrade/rollback paths<br/>constrained?"]
    R3["Can unauthenticated<br/>services leak state,<br/>consume resources, or<br/>transition security state?"]
    R4["Are interfaces blocked<br/>before the bootloader<br/>runs, or only after<br/>approved mode starts?"]
    R5["If a live TLS/SSH/IKE<br/>channel exists, could<br/>library CVEs apply, or is<br/>this only a<br/>KDF/documentation name?"]
    R6["If the OS/runtime is<br/>in-boundary, could its<br/>CVEs be hidden by<br/>firmware-only versioning?"]
  end
  subgraph Evidence["Evidence needed to close"]
    E2["update image format ·<br/>signature-before-parse<br/>proof · anti-rollback /<br/>downgrade policy"]
    E3["pre-auth reachability<br/>matrix · rate limits and<br/>output redaction ·<br/>abuse-case tests"]
    E4["lifecycle reachability<br/>matrix · boot-stage<br/>interface timing ·<br/>factory/recovery/error-state<br/>access controls"]
    E5["confirm the disclosure<br/>itself (keyword hit,<br/>context unverified) ·<br/>library identity and<br/>version ·<br/>certificate-validation<br/>behaviour · protocol-CVE<br/>disposition"]
    E6["confirm the disclosure<br/>itself (keyword hit,<br/>context unverified) ·<br/>runtime identity and<br/>config · kernel/runtime<br/>hardening profile ·<br/>patch/backport manifest"]
  end
  C2 --> I2 --> R2 --> E2
  C3 --> I3 --> R3 --> E3
  C4 --> I4 --> R4 --> E4
  C5 --> I5 --> R5 --> E5
  C6 --> I6 --> R6 --> E6
  classDef clue fill:#eef3f9,stroke:#6f7f91,color:#1f3a5f;
  classDef infer fill:#fff7e6,stroke:#b98500,color:#6b4e00;
  classDef risk fill:#fbe9e9,stroke:#b02a2a,color:#7a1f1f;
  classDef evidence fill:#e6f4ea,stroke:#1e7d34,color:#14532d;
  class C2,C3,C4,C5,C6 clue;
  class I2,I3,I4,I5,I6 infer;
  class R2,R3,R4,R5,R6 risk;
  class E2,E3,E4,E5,E6 evidence;

flowchart LR
  %% Deterministic clue tier for Juniper Networks EX, QFX and ACX Series
  %% confidence: high = structured record field; medium = structured but soft; low (dashed) = bare keyword hit, context unverified
  subgraph CMVP["CMVP-disclosed clues (deterministic)"]
    C2["[high] Firmware update / recovery / rollback services<br/><i>Soft Error State</i><br/>src: securityPolicy.services"]
    C3["[high] Unauthenticated / self-test / status service surface<br/><i>Enc/Dec (SSH)<br/>Show status<br/>Local reset</i><br/>src: securityPolicy.services"]
    C4["[high] Physical/logical interfaces (some 'blocked in firmware')<br/><i>Serial<br/>USB</i><br/>src: securityPolicy.portsAndInterfaces"]
    C5["[low] Protocol / secure-channel references (may be KDF names, not a live channel)<br/><i>TLS<br/>SSH<br/>IPSEC</i><br/>src: text:keyword"]
    C6["[low] Operating system / runtime referenced (boundary membership not asserted)<br/><i>operating system<br/>kernel</i><br/>src: text:keyword"]
  end
  classDef clueHigh fill:#eef3f9,stroke:#2f6fb0,stroke-width:2px,color:#1f3a5f;
  classDef clueMedium fill:#eef3f9,stroke:#6f7f91,color:#1f3a5f;
  classDef clueLow fill:#f7f7f7,stroke:#999,stroke-dasharray:4 4,color:#444;
  class C2,C3,C4 clueHigh;
  class C5,C6 clueLow;

Security Policy, page by page

Juniper Networks Juniper Networks EX, QFX and ACX Series Version: Junos OS 22.3R2-S1 Prepared for: Juniper Networks, Inc.

www.juniper.net Prepared by: www.teronlabs.com Juniper Networks Non-Proprietary FIPS 140-3 Security Policy

Juniper Networks Non-Proprietary FIPS 140-3 Security Policy

This is a non-proprietary Cryptographic Module Security Policy for the Juniper Networks EX, QFX and ACX series network devices running Junos OS 22.3R2-S1.

The cryptographic module is designed to meet FIPS 140-3 Level 1 overall. The table below shows the security levels claimed for each section of the security requirements. N/A N/A Table 1: Security Levels

Purpose and Use: The following models are included in this validation and provide network switching and routing functionality:

• EX4650-48Y
• QFX5120-48T
• QFX5120-48Y
• QFX5200-32C
• MX204
• ACX5448 The cryptographic module runs Junos OS, Juniper’s reliable, high-performance, modular network operating system that is supported across all of Juniper’s physical and virtual routing, switching, Juniper Networks Non-Proprietary FIPS 140-3 Security Policy

The cryptographic module provides for an encrypted connection, using SSH, between the management station and the module. All other data input or output from the modules are considered plaintext for this FIPS 140-3 validation. Module Type: The cryptographic module is a Hardware cryptographic module. Module Embodiment: The cryptographic module is defined as a MultiChipStand module that executes Junos OS 22.3R2-S1 firmware on any of the identified Juniper Networks devices. Module Characteristics: There are no additional characteristics relevant to this module. Cryptographic Boundary: The cryptographic boundary encompasses the entire Tested Operational Environment Physical Perimeter (TOEPP), which is defined as the outer edge of the chassis. The chassis is a rigid sheetmetal structure that houses all components of the device. The cryptographic module is FIPS-compliant when installed and configured with Junos OS 22.3R2-S1 validated firmware as specified in section 11.1. The physical form of the module is depicted in Figure 1 to Figure 12 Figure 1 EX4650-48Y switch (front) Figure 2 EX4650-48Y switch (rear) Juniper Networks Non-Proprietary FIPS 140-3 Security Policy

Figure 3 QFX5120-48T switch (front) Figure 4 QFX5120-48T switch (rear) Figure 5 QFX5120-48Y switch (front) Figure 6 QFX5120-48Y switch (rear) Figure 7 QFX5200-32C switch (front) Figure 8 QFX5200-32C switch (rear) Figure 9

• MX204 router (front) Figure 10
• MX204 router (rear) Juniper Networks Non-Proprietary FIPS 140-3 Security Policy

Figure 11 ACX5448 Router (front) Figure 12 ACX5448 Router (Rear)

Tested Module Identification

• Hardware: The following models of the module were tested. QFX512048T QFX512048Y QFX512032C QFX512048T QFX512048Y QFX512032C Table 2: Tested Module Identification
• Hardware Tested Module Identification
• Software, Firmware, Hybrid (Executable Code Sets): N/A The module is not classified as software, firmware, or hybrid; thus, this section is not applicable. Tested Module Identification
• Hybrid Disjoint Hardware: N/A The module is not classified as hybrid disjoint hardware; thus, this section is not applicable. Tested Operational Environments - Software, Firmware, Hybrid: N/A Juniper Networks Non-Proprietary FIPS 140-3 Security Policy

The module is not classified as software, firmware, or hybrid; thus, this section is not applicable. Vendor-Affirmed Operational Environments - Software, Firmware, Hybrid: N/A There are no vendor-affirmed operational environments claimed.

No components are excluded from the requirements of FIPS PUB 140-3. The module supports an Approved mode only. The module enters Approved mode as a result of successful installation, initialization and configuration steps described in section 11. Until these procedures have been followed, the module is non-compliant. Table 3: Modes List and Description

Approved Algorithms: Although the module may have been tested for additional algorithms or modes, only those listed below are utilized by the module. OpenSSL 1.0.2 Juniper Networks Non-Proprietary FIPS 140-3 Security Policy

Table 4: Approved Algorithms - OpenSSL 1.0.2 OpenSSL 1.1.1 Table 5: Approved Algorithms - OpenSSL 1.1.1 Juniper Networks Non-Proprietary FIPS 140-3 Security Policy

Kernel HMAC-SHA2256 Table 6: Approved Algorithms - Kernel LibMD HMAC-SHA2256 Table 7: Approved Algorithms - LibMD Vendor-Affirmed Algorithms: 1.0.2 Table 8: Vendor-Affirmed Algorithms Non-Approved, Allowed Algorithms: N/A for this module. Non-Approved, Allowed Algorithms with No Security Claimed: N/A for this module. Non-Approved, Not Allowed Algorithms: N/A for this module. Juniper Networks Non-Proprietary FIPS 140-3 Security Policy

The module implements the security functions listed in the following table. AsymKeyPairKeyGen Juniper Networks Non-Proprietary FIPS 140-3 Security Policy

Juniper Networks Non-Proprietary FIPS 140-3 Security Policy

Table 9: Security Function Implementations

The module includes ECDSA algorithms that have been validated using FIPS 186-4 CAVP tests, which are mathematically identical to FIPS 186-5 CAVP tests. Per IG C.K, all RSA and ECDSA algorithms implemented by the module are claimed compliant with FIPS 186-5. The module complies with IG C.F. RSA Key Generation, Signature Generation and Signature Verification have been tested and validated using CAVP testing for all implemented modulus lengths (2048, 3072 and 4096 bits). The number of Miller-Rabin tests used for primality testing as part of RSA Key Generation is consistent with Table C.3. The module implements the following Approved key agreement methods which have been CAVP tested and validated: ⦁ KAS-ECC per SP 800-56A Rev. 3 (FIPS 140-3 IG D.F Scenario 2, path 2). The module obtains the FIPS 140-3 IG D.F required key agreement assurances in accordance with Section 5.6.2 of SP800-56A Rev. 3. All the key agreement protocols implemented by the module are Diffie-Hellman based.

The tables below indicate the entropy source used by the module and their associated certificates. Table 10: Entropy Certificates NonPhysical NonPhysical NonPhysical NonPhysical A3498 (SHA2512) A3330 (SHA2512) A3329 (SHA2512) A3498 (SHA2512) Table 11: Entropy Sources Non-Proprietary FIPS 140-3 Security Policy

The entropy source is used to seed the module’s HMAC DRBG with the minimum required 256bits of entropy. Each 512-bit block of conditioned output from the entropy source contains 448 bits of entropy. The HMAC DRBG is used for all random data required by the module, including key generation. There are no initialization procedures required by the users of the module to operate the entropy source in a compliant manner. The module complies with the ESV Public Use document of the validated entropy source (Cert. E89).

The cryptographic module implements the key generation methods listed above in the Security Functions implementation table.

The cryptographic module implements the key establishment methods listed above in the Security Functions implementation table.

The cryptographic module supports the protocols listed below. No part of these protocols, other than the approved cryptographic algorithms and the KDFs, have been tested by the CAVP and CMVP. The SSH algorithms allow independent selection of key exchange, authentication, cipher, and integrity. In reference to the supported protocols table below, each column of options for a given protocol is independent and may be used in any viable combination.

The following table maps each physical interface to one or more logical interface types defined in the FIPS 140-3 standard. The module does not have a Control Output Interface. Juniper Networks Non-Proprietary FIPS 140-3 Security Policy

Table 12: Ports and Interfaces

The module implements two forms of role-based authentication methods, as described in the following table. Table 13: Authentication Methods Juniper Networks Non-Proprietary FIPS 140-3 Security Policy

Table 14: Roles The module supports two roles: Cryptographic Officer (CO) and User. The module supports rolebased operator authentication for assuming these roles, using methods specified in Section 4.1. The module supports concurrent operators but does not support a maintenance role and/or bypass capability. The module enforces the separation of roles using either of the role-based The Cryptographic Officer role configures and monitors the module via a console or SSH connection. As root or super-user, the Cryptographic Officer has permission to view and edit secrets within the module. The User role monitors the module via the console or SSH. The user role cannot change the

G,R,W G,R,W Juniper Networks Non-Proprietary FIPS 140-3 Security Policy

Juniper Networks Non-Proprietary FIPS 140-3 Security Policy Z G,E G,E

algorithm selftests Table 15: Approved Services Juniper Networks Non-Proprietary FIPS 140-3 Security Policy

The module does not offer any non-approved services. N/A for this module.

The module includes a firmware load service that is used to install the Junos OS firmware image as part of installation of the module, as described in Section 11.1. The loaded firmware is a complete image replacement and constitutes an entirely new module and version of Junos OS which would require a separate FIPS 140-3 validation.

The cryptographic module implements a firmware integrity self-test that uses ECDSA P-256 with SHA2-256 to ensure the integrity of all Junos OS firmware components. The self-test is automatically run on power-up.

The firmware integrity test can be run on demand by the module’s operator by power cycling the module.

Type of Operational Environment: Non-Modifiable The module consists of hardware containing a non-modifiable operational environment as per the FIPS 140-3 definitions. It includes a firmware load service to support necessary updates. The loaded firmware is a complete image replacement and constitutes an entirely new module and version of Junos OS which would require a separate FIPS 140-3 validation.

There are no security rules, settings, or restrictions to the configuration of the operational environment beyond the initialization instructions to set the module in Approved mode. Juniper Networks Non-Proprietary FIPS 140-3 Security Policy

The module’s physical embodiment meets Level 1 Physical Security requirements. The module is completely enclosed in a rectangular nickel or clear zinc coated, cold rolled steel, plated steel and brushed aluminum enclosure. There are no ventilation holes, gaps, slits, cracks, slots, or crevices that would allow for any sort of observation of any component contained within the cryptographic boundary. n/a n/a Table 16: Mechanisms and Actions Required

This section is not applicable, as there are currently no approved non-invasive mitigation techniques specified in ISO/IEC 19790:2012.

The table below lists the areas within the module’s cryptographic boundary where SSPs can be stored. Table 17: Storage Areas

The table below lists the method used by the module for the input and output of SSPs. Juniper Networks Non-Proprietary FIPS 140-3 Security Policy

Table 18: SSP Input-Output Methods The table below describes the SSP zeroization methods employed by the module. Table 19: SSP Zeroization Methods The CO can run the following commands to zeroize the approved mode SSPs: This command wipes clean all the SSPs/configs as well as the disk and install a factory default firmware image. After zeroizing the system, the module is no longer in a FIPS compliant state. Installation and configuration as per section 11.1 is required to enter the FIPS compliant state and enable the Approved mode of operation. The Cryptographic Officer must retain control of the module while zeroization is in process. Zeroization commands, as described above, and power cycling are initiated by the operator. The commands. Session termination is initiated by the operator or by environmental errors. The completion of zeroization is indicated implicitly. If the zeroization is initiated using a zeroization has successfully completed. If the zeroization is initiated by power cycling the module, then successful reboot of the module indicates that zeroization has completed successfully. In the case of zeroization initiated by session termination, SSPs are zeroized when the session terminates, and session termination is indicated in the log. Juniper Networks Non-Proprietary FIPS 140-3 Security Policy

Juniper Networks Non-Proprietary FIPS 140-3 Security Policy

PackageCA Table 20: SSP Table 1 Juniper Networks Non-Proprietary FIPS 140-3 Security Policy

Juniper Networks Non-Proprietary FIPS 140-3 Security Policy

Preloaded Preloaded Table 21: SSP Table 2

The following transitions apply to algorithms used by this module: SHA-1: The SHA-1 hash algorithm will be non-Approved for all cryptographic purposes after December 31, 2030.

On power up or reset, the module performs the pre-operational self-tests and the indicated conditional cryptographic algorithm self-tests described below. All KATs must be completed successfully prior to any other use of cryptography by the module. The CASTs for algorithms

Table 22: Pre-Operational Self-Tests

Juniper Networks Non-Proprietary FIPS 140-3 Security Policy

Juniper Networks Non-Proprietary FIPS 140-3 Security Policy

n/a n/a n/a n/a n/a n/a n/a n/a n/a n/a Table 23: Conditional Self-Tests Juniper Networks Non-Proprietary FIPS 140-3 Security Policy

The module does not implement periodic self-testing. Table 24: Pre-Operational Periodic Information Juniper Networks Non-Proprietary FIPS 140-3 Security Policy

Table 25: Conditional Periodic Information

Table 26: Error States execution to halt. The only way to exit from this state is to reboot the module, which causes the self-tests to be repeated and pass successfully before the corresponding algorithms are usable.

Juniper Networks Non-Proprietary FIPS 140-3 Security Policy

Self–tests that are performed at power-up are available on demand by power cycling the module.

Before installation of module firmware, CO must first zeroize any module SSPs by following the instructions in Section 9.3. Once zeroization is complete, the CO must install the JUNOS firmware image on the device using the following CLI command: CO@host> request system software add /<image-path>/<image-filename> no-copy no-validate reboot. The image-filenames for the validated firmware are as follows: • EX series: jinstall-host-ex-4e-x86-64-22.3R2-S1.7-secure-signed.tgz • QFX series: jinstall-host-qfx-5e-x86-64-22.3R2-S1.7-secure-signed.tgz • MX series: junos-vmhost-install-mx-x86-64-22.3R2-S1.7.tgz • ACX series: junos-vmhost-install-acx-x86-64-22.3R2-S1.7.tgz Next, the CO shall proceed as follows:

1. Enable the approved mode on the device. CO@host> set system fips chassis level 1
2. Set the root password. user@host# set system root-authentication plain-text-password New password: <type password here>
3. Commit and reboot the device. CO@host# commit Once the module is rebooted and the integrity and self-tests have run successfully on initial power-on in, the module is operating in the approved mode of operation. The CO must create a backup image of the firmware to ensure it is also an approved mode Junos OS image by issuing the request system snapshot command. The show version command will display the version of the Junos OS on the device so that the CO can confirm it is the FIPS validated version. The CO should also verify the presence of the suffix string “:fips” in the cli prompt, indicating the module is operating in approved mode. TLS and IKE/IPsec are not enabled by default and must not be enabled for FIPS compliant usage of the module.

The Cryptographic Officer is the person responsible for enabling, configuring, monitoring, and maintaining the module in approved mode. The Cryptographic Officer securely installs Junos OS on the device, enables the approved mode of operation, establishes keys and passwords for other users and software modules, and initializes the device before network connection. The Juniper Networks Non-Proprietary FIPS 140-3 Security Policy

Cryptographic Officer can configure and monitor the module through a console or SSH connection.

No specific non-administrator guidance is required to operate the module.

The module design implements the following security rules:

1. The module clears previous authentications on power cycle.
2. Power up self-tests do not require any operator action.
3. Data output is inhibited during key generation, self-tests, zeroization, and error states.
4. Status information does not contain CSPs or sensitive data that if misused could lead to a compromise of the module.
5. There are no restrictions on which SSPs are zeroized by the zeroization service.
6. The module does not support a maintenance interface or role.
7. The module does not output intermediate key values.
8. The module requires two independent internal actions to be performed prior to outputting plaintext CSPs.

The following are requirements for compliant usage of the module:

1. The cryptographic officer must retain control of the module while zeroization is in process.
2. The cryptographic officer shall verify that the firmware image to be loaded on the module is a FIPS validated image.
3. Before pushing the factory reset button on the device, the cryptographic officer shall perform the zeroize command as described in section 9.3
4. The password minimum-length must be configured to be at least 10.
5. The module shall not be configured to use a radius server and the radius server capability shall be disabled.
6. SSH key-exchange must not be configured to include ‘dh-group14-sha1’.

No special maintenance requirements are required.

When disposing of the cryptographic module, the cryptographic officer shall perform the zeroize command as described in Section 9.3. Juniper Networks Non-Proprietary FIPS 140-3 Security Policy

The module does not implement mechanisms to mitigate other attacks beyond what is described in this security policy. Juniper Networks Non-Proprietary FIPS 140-3 Security Policy

Referenced URLs

• www.juniper.net
• www.teronlabs.com