Juniper Networks MX Series 3D Universal Edge Routers

Certificate

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

flowchart LR
  %% Deterministic review-risk graph for Juniper Networks MX Series 3D Universal Edge Routers
  %% 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>TLS<br/>SSH<br/>IPSEC</i>"]
    C6["[low] Operating system / runtime<br/>referenced (boundary<br/>membership not asserted)<br/><i>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 MX Series 3D Universal Edge Routers
  %% 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>TLS<br/>SSH<br/>IPSEC</i><br/>src: text:keyword"]
    C6["[low] Operating system / runtime referenced (boundary membership not asserted)<br/><i>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 MX Series 3D Universal Edge Routers Version: Junos OS 22.2R3-S1 Juniper Networks, Inc.

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

This is a non-proprietary Cryptographic Module Security Policy for the Juniper Networks MX Series 3D Universal Edge Routers, consisting of the MX240, MX480 and MX960 models, with MX-SPC3 Services Processing Card, running Junos OS 22.2R3-S1.

The cryptographic module meets requirements applicable to Level 1 of FIPS 140-3. The following table lists the security levels claimed by the cryptographic module for each security requirements area of the FIPS 140-3 standard. Table 1: Security Levels

Purpose and Use: The MX series universal routing modular platforms MX240, MX480 and MX960 provide dedicated high-performance processing for flows and sessions and integrates advanced security capabilities that protect the network infrastructure as well as user data. The MX-SPC3 services card provides security services such as carrier-grade NAT (CGNAT), IPsec, stateful firewall, deep packet inspection, IDS, traffic load balancing, Web filtering, and DNS sinkhole. Module Type: Hardware Module Embodiment: MultiChipStand Module Characteristics: Cryptographic Boundary: This Security Policy covers the following models:

• MX240,
• MX480, and
• MX960. All models run Juniper’s JUNOS firmware. The JUNOS firmware is FIPS-compliant when configured in the Approved mode called JUNOS-FIPS-MODE, version 22.2R3-S1. The firmware CLI command show version identifies itself as “Junos 22.2R3-S1.9”. The physical form of the module is depicted in Figure 1 and Figure 2 below. The cryptographic boundary encompasses the entire Tested Operational Environment Physical Perimeter (TOEPP), which is defined as follows:
• the outer edge of the chassis and including the Routing Engine (RE), the MS-MPC, Router Control Board/Router Fabric Board (SCB)/(SFB) and slot covers in the following configurations:
• For MX240 (2 available RE slots, 2 additional slots): 1 SCB, 1 RE, at 1 SPC. All empty module bays must have a slot cover installed for proper cooling air circulation.
• For MX480 (2 available RE slots, 6 additional slots): 1 SCB, 1 RE, at least 1 SPC. All empty module bays must have a slot cover installed for proper cooling air circulation.
• For MX960 (2 available RE slots, 12 additional slots): 1 SCB, 1 RE, at least 1 SPC. All empty module bays must have a slot cover installed for proper cooling air circulation.
• includes the inverse three-dimensional space where non-crypto-relevant line cards fit, with the backplane port serving as the physical interface.

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 module are considered plaintext for this FIPS 140-3 validation. The module does not rely on external devices for input and output of security sensitive parameters (SSPs). Figure 1 Physical Cryptographic Boundary (Left to Right: MX240, MX480, MX960)

Tested Module Identification – Hardware:

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 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. CMVP makes no statement as to the correct operation of the module or the security strengths of the generated keys when so ported if the specific operational environment is not listed on the validation certificate.

No components are excluded from the requirements of FIPS 140-3.

Modes List and Description:

Table 3: Modes List and Description Once the module has been securely initialized following the instructions provided in Section 11.1, the module is in approved mode of operation. Failure to follow the secure initialization instructions results in the module being in a non-compliant state which is out of scope of the validation.

Approved Algorithms: Although the module may have been tested for additional algorithms or modes, only those listed below are utilized by the module. OpenSSL Approved Cryptographic Functions

Table 4: Approved Algorithms - OpenSSL Approved Cryptographic Functions Kernel Approved Cryptographic Functions Table 5: Approved Algorithms - Kernel Approved Cryptographic Functions OpenSSH Approved Cryptographic Functions

Table 6: Approved Algorithms - OpenSSH Approved Cryptographic Functions Vendor-Affirmed Algorithms: Table 7: 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 8: Security Function Implementations

The module includes RSA and 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-SSC per SP 800-56A Rev. 3 (FIPS 140-3 IG D.F Scenario 2, path 1). 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 module includes approved KDF algorithms for the SSH protocol. No parts of the protocol, other than the approved cryptographic algorithms and the KDFs, have been tested by the CAVP and CMVP.

Table 9: Entropy Certificates Table 10: Entropy Sources 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 to the ESV Public Use document of the

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

Table 12: Authentication Methods The module enforces the separation of roles using either password-based authentication or

Table 13: Roles based 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. connection. As root or super-user, the Cryptographic Officer has permission to view and edit secrets within the module and establish VPN tunnels.

The User role monitors the router via the console or SSH. The user role cannot change the

The module includes a firmware load service to support necessary updates. Only the CO can install the new image using the CLI 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 an approved firmware integrity self-test that uses ECDSA P-256 with SHA2-256 to ensure the integrity of all Junos OS firmware components. The selftest is automatically run on power-up. It can also be run on demand by the module’s operator by power cycling the module. When the integrity check fails, the module enters an error state (kernel panic) which can only be exited by power-cycling the module.

The self-test is automatically run on power-up. It can also be run on demand by the module’s operator by power cycling the module.

Type of Operational Environment: Non-Modifiable How Requirements are Satisfied: 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.

Table 15: Mechanisms and Actions Required The module’s physical embodiment is that of a multi-chip standalone device that meets Level 1 Physical Security requirements. The module consists of production-grade components with

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

Table 17: SSP Input-Output Methods

Table 18: SSP Zeroization Methods The CO can run the following commands to zeroize the approved mode SSPs: user@host> request vmhost zeroize 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 module automatically zeroizes all SSPs when no longer required by calling explicit delete 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 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 is indicated in the log.

Name HMAC DRBG V value HMAC DRBG Key value HMAC DRBG

Input - Output

Storage RAM:Plaintext RAM:Plaintext RAM:Plaintext

Storage Duration Until updated by HMAC_DRBG_Update() Until updated by HMAC_DRBG_Update() Until HMAC_Instantiate_Update() or HMAC_DRBG_Reseed() complete

Zeroization Reset Reset Reset Explicit

Related SSPs

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 algorithms utilized in the

Table 21: Pre-Operational Self-Tests

Table 22: Conditional Self-Tests

Table 23: Pre-Operational Periodic Information

Table 24: Conditional Periodic Information

Table 25: 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.

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

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-filename for the validated firmware is as follows: • junos-vmhost-install-srx-x86-64-22.2R3-S1.9.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 of operation, establishes keys and passwords for other users and software modules, and initializes the device before network connection. The

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 corresponds to the security rules below. The term must in this context specifically refers to a requirement for correct usage of the module in the approved mode; all other statements indicate a security rule implemented by the module.

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.
9. The cryptographic officer must invoke the zeroize command (as per Section 9.3) before using the firmware load service to install a new firmware image.
10. The cryptographic officer must determine whether firmware being loaded is a legacy use of the firmware load service.
11. The cryptographic officer must retain control of the module while zeroization is in process.
12. IKE/IPsec and TLS features must not be enabled.

No special maintenance requirements and required.

When disposing of the cryptographic module, the CO shall perform the zeroize command described in Section 9.3.

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