Juniper Networks EX4100

Certificate

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

flowchart LR
  %% Deterministic review-risk graph for Juniper Networks EX4100
  %% Review prompts and evidence gaps, NOT vulnerability findings.
  subgraph CMVP["CMVP-disclosed clues"]
    C2["[low] Firmware update / recovery<br/>/ rollback (referenced in<br/>text)<br/><i>Firmware load<br/>Recovery</i>"]
    C3["[low] Self-test / status surface<br/>(referenced in text)<br/><i>Self-Test<br/>UnAuth<br/>Unauthenticated</i>"]
    C5["[low] Protocol / secure-channel<br/>references (may be KDF<br/>names, not a live channel)<br/><i>SSH<br/>HTTPS<br/>library named: openssl</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["Possible only, trusted<br/>code is reachable through<br/>update and recovery paths."]
    I3["Possible only, some<br/>services may process input<br/>before, or without,<br/>operator authentication."]
    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?"]
    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["confirm the disclosure<br/>itself (keyword hit,<br/>context unverified) ·<br/>update image format ·<br/>signature-before-parse<br/>proof · anti-rollback /<br/>downgrade policy"]
    E3["confirm the disclosure<br/>itself (keyword hit,<br/>context unverified) ·<br/>pre-auth reachability<br/>matrix · rate limits and<br/>output redaction ·<br/>abuse-case tests"]
    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
  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,C5,C6 clue;
  class I2,I3,I5,I6 infer;
  class R2,R3,R5,R6 risk;
  class E2,E3,E5,E6 evidence;

flowchart LR
  %% Deterministic clue tier for Juniper Networks EX4100
  %% confidence: high = structured record field; medium = structured but soft; low (dashed) = bare keyword hit, context unverified
  subgraph CMVP["CMVP-disclosed clues (deterministic)"]
    C2["[low] Firmware update / recovery / rollback (referenced in text)<br/><i>Firmware load<br/>Recovery</i><br/>src: text:keyword"]
    C3["[low] Self-test / status surface (referenced in text)<br/><i>Self-Test<br/>UnAuth<br/>Unauthenticated</i><br/>src: text:keyword"]
    C5["[low] Protocol / secure-channel references (may be KDF names, not a live channel)<br/><i>SSH<br/>HTTPS<br/>library named: openssl</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,C5,C6 clueLow;

Security Policy, page by page

Juniper Networks, Inc. Juniper Networks EX4100 Version: Junos OS 22.4R2 Prepared for: Juniper Networks, Inc.

www.juniper.net Prepared by: www.teronlabs.com

This is a non-proprietary Cryptographic Module Security Policy for the Juniper Networks EX4100-F48P, EX4100-F-48T, EX4100-F-24P, EX4100-F-24T Ethernet Switches, hereafter referred to as the

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. Table 1: Security Levels

Purpose and Use: The Juniper Networks EX4100 line of Ethernet Switches offers a secure, cloud-ready portfolio of access switches ideal for enterprise branch, campus, and data center networks. This FIPS 140-3 validation comprises the following EX series switch models EX4100-F-48P, EX4100-F48T, EX4100-F-24P, and EX4100-F-24T. 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, and security platforms. 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.4R2 firmware on any of the identified Juniper Networks devices. Module Characteristics: There are no additional characteristics relevant to this module. Cryptographic Boundary: The Tested Operational Environment Physical Perimeter (TOEPP) is defined as the outer edge of the chassis. The chassis is a rigid sheet-metal structure that houses all components of the device. The cryptographic boundary encompasses the entire TOEPP. The cryptographic module is FIPS-compliant when installed and configured with Junos OS 22.4R2 validated firmware as specified in section 11.1. The physical form of the module is depicted in Figures 1 to 8. Figure 1

• EX4100-F-48P Ethernet Switch (front) Figure 2
• EX4100-F-48P Ethernet Switch (rear) Figure 3
• EX4100-F-48T Ethernet Switch (front) Figure 4
• EX4100-F-48T Ethernet Switch (rear)

Figure 5

• EX4100-F-24P Ethernet Switch (front) Figure 6
• EX4100-F-24P Ethernet Switch (rear) Figure 7
• EX4100-F-24T Ethernet Switch (front) Figure 8
• EX4100-F-24T Ethernet Switch (rear)

Tested Module Identification

• Hardware: The following models of the module were tested. 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. N/A for this module. Tested Module Identification – Hybrid Disjoint Hardware: N/A The module is not classified as hybrid disjoint hardware; thus, this section is not applicable. N/A for this module. Tested Operational Environments - Software, Firmware, Hybrid: N/A The module is not classified as software, firmware, or hybrid; thus, this section is not applicable. N/A for this module. Vendor-Affirmed Operational Environments - Software, Firmware, Hybrid: N/A There are no vendor-affirmed operational environments claimed. N/A for this module.

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 4) Table 4: Approved Algorithms - OpenSSL 1.0.2 OpenSSL 1.1.1 Table 5: Approved Algorithms - OpenSSL 1.1.1

Kernel Table 6: Approved Algorithms - Kernel LibMD Table 7: Approved Algorithms - LibMD Vendor-Affirmed Algorithms: 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.

The module implements the security functions listed in the following table.

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 Table 11: Entropy Sources The entropy source is used to seed the module’s HMAC DRBG with the minimum required 256-bits 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

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. Table 12: Ports and Interfaces

The module implements two forms of role-based authentication methods, as described in the following table.

Table 14: Roles The module supports two roles: Cryptographic Officer (CO) and User. 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 operator authentication methods in Section 4.1. 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

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

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.

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. 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.

Table 18: SSP Input-Output Methods The table below describes the SSP zeroization methods employed by the module. Table 19: SSP Zeroization Methods The completion of zeroization is indicated implicitly. If the zeroization is initiated using a zeroization command or explicit delete command, completion of the command indicates that 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

Name

Description Juniper Image at software load and also at runtime for integrity.

Size - Strength

Type - Category

Generated By

Established By

Used By

The following transitions apply to algorithms used by this module: SHA-1: The SHA-1 hash algorithm will be non-Approved for cryptographic protection 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 utilized in the pre-operational Firmware integrity check are performed prior to the Firmware integrity check.

Table 22: Pre-Operational Self-Tests

Table 23: Conditional Self-Tests

The module does not implement periodic self-testing. Table 24: Pre-Operational Periodic Information

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 selftests to be repeated and pass successfully before the corresponding algorithms are usable.

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

The module must be correctly installed and configured to enter a FIPS compliant state and operate in the Approved mode. The required procedures are as follows:

1. Install the Junos OS firmware image - the procedure is detailed in section 11.2.1
2. Configure device for the Approved mode - the procedure is section 11.2.2. To continue using the module in a FIPS compliant way, the Module Operation Rules in section 11.4.2 must be followed.

1. Download the validated firmware image from https://www.juniper.net/support/downloads/junos.html. Log in to the Juniper Networks authentication system using the username (generally your e-mail address) and password supplied by Juniper Networks representatives. Select the validated firmware image. Download the firmware image to a local host or to an internal software distribution site. The cryptographic module devices use the following firmware image: junos-install-ex-arm-64-22.4R2.8.tgz
2. Connect to the console port on the device from your management device, and log in to the Junos OS CLI.

user@host> request system software add <package>

user@host> request system reboot

user@host> request vmhost reboot

root@host# request system zeroize

root@host# set system root-authentication plain-text-password

crypto-officer@host# set system fips level 1

crypto-officer@host# commit

crypto-officer@host# run request system reboot

crypto-officer@host# request system zeroize

3. Install the new package on the device (package may be a local file copied to the device, or a file on a remote server):
4. Reboot the device to load the installation:
5. After the reboot has completed, log in and use the show version command to verify that the new version of the software is successfully installed.

To configure the device for the Approved mode:

1. Zeroize the device to delete all CSPs before entering the Approved mode.
2. After the device comes up, login using username “root” and password blank.
3. Configure root authentication with password at least 10 characters or more.
4. Load configuration onto device and commit new configuration. NOTE: SSH key-exchange configuration must not include ‘dh-group14-sha1’. It is not approved for this module.
5. Configure crypto-officer and login with crypto-officer credentials.
6. Commit and reboot the device.

CAUTION: Perform system zeroization with care. After the zeroization process is complete, no data is left on the device. The device is returned to the factory default state, equivalent to a fresh installation of the firmware, without any configured users or configuration files. 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). NOTE: The Crypto-Officer must retain control of the module while zeroization is in progress. To zeroize the device: 1. Login to the device as Crypto Officer and from CLI, enter

warning: System will be rebooted and may not boot without configuration

Erase all data, including configuration and log files? [yes, no] (no)

Erase all data, including configuration and log files? [yes, no] (no)

yes

2. To initiate the zeroization process, type yes at the prompt:

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 11.2.3.
4. The password minimum-length must be configured to be at least 10.
5. Virtual Chassis features must not be configured.
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 11.2.3.

The module does not implement mechanisms to mitigate other attacks beyond what is described in this security policy.