Juniper Networks PTX1000 Packet Transport Router

Certificate

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

flowchart LR
  %% Deterministic review-risk graph for Juniper Networks PTX1000 Packet Transport Router
  %% 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</i>"]
    C3["[low] Self-test / status surface<br/>(referenced in text)<br/><i>self-test<br/>Status output<br/>Show status</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 PTX1000 Packet Transport Router
  %% 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</i><br/>src: text:keyword"]
    C3["[low] Self-test / status surface (referenced in text)<br/><i>self-test<br/>Status output<br/>Show status</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 PTX1000 Packet Transport Router Firmware: Junos OS 22.4R2.8 Document Version: 1.0 Date: December 28, 2023 Prepared by: www.acumensecurity.net Public Material – May be reproduced only in its original entirety (without revision).

1. General Introduction Federal Information Processing Standards Publication 140-3

• Security Requirements for Cryptographic Modules specifies requirements for cryptographic modules to be deployed in a Sensitive but Unclassified environment. The National Institute of Standards and Technology (NIST) and Canadian Centre for Cyber Security (CCCS) Cryptographic Module Validation Program (CMVP) run the FIPS 140-3 program. The NVLAP accredits independent testing labs to perform FIPS 140-3 testing; the CMVP validates modules meeting FIPS 140-3 validation. Validated is the term given to a module that is documented and tested against the FIPS 140-3 criteria. More information is available on the CMVP website at: https://csrc.nist.gov/projects/cryptographic-module-validation-program. About this Document This non-proprietary Cryptographic Module Security Policy for the Juniper Networks, Inc. Juniper Networks PTX1000 Packet Transport Router provides an overview of the product and a high-level description of how it meets the overall Level 1 security requirements of FIPS 140-3. The Juniper Networks PTX1000 Packet Transport Router may also be referred to as the “module” in this document. Disclaimer The contents of this document are subject to revision without notice due to continued progress in methodology, design, and manufacturing. Juniper Networks shall have no liability for any error or damages of any kind resulting from the use of this document. Notices This document may be freely reproduced and distributed in its entirety without modification. Public Material
• May be reproduced only in its original entirety (without revision).

This document describes the cryptographic module security policy for the Juniper Networks, Inc. Juniper Networks PTX1000 Packet Transport Router (Hardware version: PTX1000) cryptographic module (also referred to as the “module” hereafter) with firmware version Junos OS 22.4R2.8 . The module has a multichip standalone embodiment. It contains specification of the security rules, under which the cryptographic module operates, including the security rules derived from the requirements of the FIPS 140-3 standard. The following table lists the level of validation for each area in FIPS 140-3: Table 1 - Security Levels The module claims an overall Security Level 1. Public Material – May be reproduced only in its original entirety (without revision).

2. Cryptographic Module Specification The versions of the module are as follows: Table 2

• Cryptographic Module Tested Configuration Module Usage and Cryptographic Boundary The cryptographic module provides for an encrypted connection, using SSH, between the management station and the module. The cryptographic module’s operational environment is a limited operational environment. The images below depict the cryptographic boundary of the hardware module (the entirety of the module/chassis). This includes the Routing Engine (RE). No components have been excluded from the cryptographic boundary of the module. Figure 1 –PTX1000 Public Material
• May be reproduced only in its original entirety (without revision).

Figure 2

• High-level PTX1000 Block Diagram The module claims an overall Security Level of 1 with all individual sections at a Security Level 1 with the exceptions of Roles, Services and Authentication (claimed at Security Level 3). The module does not implement any non-invasive security mitigations or mitigations of other attacks and thus the requirements per these sections are inapplicable. Modes Of Operation The module supports one Approved mode of operation and a non-Approved mode of operation. The module must always be zeroised when switching between the Approved mode of operation and the non-Approved mode of operation and vice versa. Approved Mode The hardware versions contained in Table 2, with Junos OS 22.4R2.8 installed, contain one Approved mode of operation and a non-Approved mode of operation. The Junos OS 22.4R2.8 firmware image must be installed on the module. The module is configured during initialization by the Crypto Officer to operate in the Approved mode or the non-Approved mode. The Crypto Officer can place the module in Public Material
• May be reproduced only in its original entirety (without revision).

the Approved mode of operation by following the instructions specified in Section 11 Life-Cyle Assurance in this document (Crypto Officer guidance). The Crypto Officer can verify that the cryptographic module is in the Approved mode by observing the console prompt and running the “show version” command. When operating in the Approved mode, the prompt will read “<operator>@<device name>:fips#” (e.g. crypto-officer@ptx1000fips#). The “show version” command will allow the Crypto Officer to verify that the validated firmware version is running on the module. The Crypto Officer can also use the “show system fips chassis level” command (returns “level 1”) to determine if the module is operating in the Approved mode. The Approved mode is entered when the module is configured for it and successfully passes all self-tests (both pre-operational and conditional cryptographic algorithm self-tests (CASTs)) . Non-Approved Mode The cryptographic module supports a non-Approved mode of operation. When operated in the nonApproved mode of operation, the module supports non-Approved algorithms identified below in this section as well as the algorithms supported in the Approved mode of operation. The Crypto Officer can place the module into the non-Approved mode of operation by following the instructions in the Section

Degraded Operation The module does not support a degraded mode of operation. Overall Security Rules of Operation The module design corresponds to the security rules below. The term shall 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. When the module has not been placed in a valid role, the operator does not have access to any cryptographic services.
3. Self-tests do not require any operator action.
4. Data output is inhibited during SSP generation, self-test execution, zeroisation, and error states.
5. Status information does not contain SSPs or sensitive data that if misused could lead to a compromise of the module.
6. There are no restrictions on which SSPs are zeroised by the zeroisation service.
7. The module does not support a maintenance interface or role. Public Material – May be reproduced only in its original entirety (without revision).

8. The module does not output intermediate key values.
9. The module does not output plaintext CSPs.
10. The Crypto officer shall verify that the firmware image to be loaded on the module is a FIPS 140-

3 validated image. If any non-validated firmware image is loaded the module will no longer be a

validated module.

11. The Crypto Officer shall retain control of the module while zeroisation is in process.
12. The virtual chassis feature is not supported in Approved mode and shall not be configured on the module.
13. The module shall not be configured to use a radius server and the radius server capability shall be disabled.
14. No parts of the SSH protocol, other than the approved cryptographic algorithms and the KDFs, have been tested by the CAVP and CMVP. There are algorithms, modes, and key/moduli sizes that have been CAVP-tested but are not used by any approved service of the module. Only the algorithms, modes/methods, and key lengths/curves/moduli shown in this table are used by an approved service of the module. Public Material – May be reproduced only in its original entirety (without revision).

Public Material – May be reproduced only in its original entirety (without revision).

Public Material – May be reproduced only in its original entirety (without revision).

Public Material – May be reproduced only in its original entirety (without revision).

Table 3

• Approved Algorithms The following protocol is supported by the module in the Approved mode:
• SSHv2 (EC Diffie-Hellman P-256, P-384, P-521; Diffie-Hellman MODP2048; RSA 2048, 4096; The SSH protocol allows independent selection of key exchange, authentication, cipher and integrity algorithms. Public Material
• May be reproduced only in its original entirety (without revision).

The module does not support any non-Approved algorithms in the Approved mode, i.e., it does not support Non-Approved Algorithms Allowed in the Approved Mode of Operation and Non-Approved Algorithms Allowed in the Approved Mode of Operation with No Security Claimed. In addition to all Approved algorithms supported in the Approved mode of operation, the following nonApproved Algorithms Not Allowed in the Approved Mode of Operation are supported only in the nonApproved mode: Table 4

• Non-Approved Algorithms Not Allowed in the Approved Mode of Operation Public Material
• May be reproduced only in its original entirety (without revision).

3. Cryptographic Module Interfaces Table 5 – Ports and Interfaces The module does not support control output. There are additional ethernet interfaces, 10 Hz pulses-per-second (PPS) Sub-Miniature B (SMB) connector and

10 MHz SMB timing connector (10MHz) which are reserved for future use (disabled).

Public Material – May be reproduced only in its original entirety (without revision).

4. Roles, Services, and Authentication The module supports two roles: Crypto 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 identity-based operator authentication. The module implements two forms of identity-based authentication, username, and password over the console and SSH connections, as well as username and an ECDSA or RSA public key-based authentication over SSH. The Crypto Officer role configures and monitors the module via a console or SSH connection. As root or super-user, the Crypto Officer has permission to view and configure passwords and public keys within the module. The User role monitors the module via the console or SSH. The User role does not have the permission to modify the configuration. ) Public Material – May be reproduced only in its original entirety (without revision).

Public Material – May be reproduced only in its original entirety (without revision).

Public Material – May be reproduced only in its original entirety (without revision).

Table 7

• Roles and Authentication Public Material
• May be reproduced only in its original entirety (without revision).

Public Material – May be reproduced only in its original entirety (without revision).

Public Material – May be reproduced only in its original entirety (without revision).

Public Material – May be reproduced only in its original entirety (without revision).

Public Material – May be reproduced only in its original entirety (without revision).

G = Generate: The module generates or derives the SSP. R = Read: The SSP is read from the module (e.g. the SSP is output). Public Material – May be reproduced only in its original entirety (without revision).

W = Write: The SSP is updated, imported, or written to the module. E = Execute: The module uses the SSP in performing a cryptographic operation. Z = Zeroise: The module zeroises the SSP. Public Material – May be reproduced only in its original entirety (without revision).

Public Material – May be reproduced only in its original entirety (without revision).

Table 9

• Non-Approved Services Public Material
• May be reproduced only in its original entirety (without revision).

5. Software/Firmware Security The module performs the firmware integrity check using ECDSA P-256 with SHA2-256. The operator can initiate the integrity test on demand by rebooting the module. The module firmware image is delivered in the form of a pre-compiled tarball (.tgz). The module supports loading of firmware from an external source and a firmware load test using ECDSA P-256 with SHA2-256 is performed in support of the load. Public Material – May be reproduced only in its original entirety (without revision).

6. Operational Environment The module contains a limited operational environment. The Junos OS 22.4R2.8 operating system is contained within the module, i.e., the tested configurations listed in Table 2 of this document. Security rules and restrictions for configuration of the operational environment have been specified in Section 2 (Overall Security Rules of Operation) and Section 11 (Installing The Firmware Image and Enabling the Approved Mode of Operation) of this document. Public Material – May be reproduced only in its original entirety (without revision).

7. Physical Security The module’s physical embodiment is that of a multi-chip standalone meeting 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. The module enclosure is made of production grade materials. 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. No actions are required by the operator to ensure that physical security is maintained. Public Material – May be reproduced only in its original entirety (without revision).

8. Non-invasive Security The module does not implement any non-invasive security mitigations and thus the requirements per this section do not apply to the module. Public Material – May be reproduced only in its original entirety (without revision).

9. Sensitive Security Parameter Management Public Material – May be reproduced only in its original entirety (without revision).

Public Material – May be reproduced only in its original entirety (without revision).

Public Material – May be reproduced only in its original entirety (without revision).

N/A N/A Public Material – May be reproduced only in its original entirety (without revision).

Public Material – May be reproduced only in its original entirety (without revision).

n ), Public Material – May be reproduced only in its original entirety (without revision).

n Public Material – May be reproduced only in its original entirety (without revision).

Public Material – May be reproduced only in its original entirety (without revision).

Public Material – May be reproduced only in its original entirety (without revision).

Public Material – May be reproduced only in its original entirety (without revision).

Key/SSP Name/ Type

Strength

Security Function and Cert. Number (HMAC- SHA2- 256, Cert. #A4301) HMAC (SHA2- 256, Cert. #A4301) SHA (SHA2- 256, SHA2- 512, Cert. #A4301), CKG

Gener- ation

Import /Export

Establish - ment

Storage

Zero- isation

Use & related keys

Table 10

• SSPs Table 11
• Non-Deterministic Random Number Generation Specification Public Material
• May be reproduced only in its original entirety (without revision).

10. Self-tests The module performs the following self-tests:

• Pre-operational Self-Tests:
• Firmware Integrity Test: using ECDSA P-256 with SHA2-256
• Conditional Self-Tests:
• Conditional Cryptographic Algorithm Self-tests (CAST):
• Kernel KATs (CAVP Cert. #A4303)
• HMAC-SHA2-256 DRBG KAT
• Generate, Instantiate and Reseed
• HMAC-SHA-1 KAT
• HMAC-SHA2-256 KAT
• SHA2-384 KAT
• SHA2-512 KAT
• OpenSSL KATs (CAVP Cert. #A4301)
• AES CBC 128 bits Encrypt KAT
• AES CBC 192 bits Encrypt KAT
• AES CBC 256 bits Encrypt KAT
• AES CBC 128 bits Decrypt KAT
• AES CBC 192 bits Decrypt KAT
• AES CBC 256 bits Decrypt KAT
• HMAC-SHA2-256 DRBG KAT
• Generate, Instantiate and Reseed
• HMAC-SHA-1 KAT
• HMAC-SHA2-256 KAT
• HMAC-SHA2-512 KAT
• KAS-ECC-SSC P-256 KAT
• KAS-ECC-SCC P-384 KAT
• KAS-FFC-SSC MODP-2048 KAT
• KDF SSH KAT
• RSA 2048 bits SHA2-256 Sign KAT
• RSA 2048 bits SHA2-256 Verify KAT
• ECDSA P-256 Sig Gen KAT
• ECDSA P-256 Sig Ver KAT
• ECDSA P-384 Sig Gen KAT
• ECDSA P-384 Sig Ver KAT
• SHA2-384 KAT
• LibMD KATs (CAVP Cert. #A4306)
• HMAC-SHA-1
• HMAC-SHA2-256
• SHA2-512 Public Material
• May be reproduced only in its original entirety (without revision).

• NIST SP 800-90B Repetitive Count Test (RCT)
• NIST SP 800-90B Adaptive Proportion Test (APT)
• Pairwise consistency test when generating ECDSA key pairs (for signature generation/verification and KAS-ECC SSP agreement)
• Pairwise consistency test when generating RSA key pairs (for signature generation/verification)
• Pairwise consistency test when generating DSA key pairs (for KAS-FFC SSP agreement)
• Firmware Load Test (ECDSA P-256 SHA2-256 signature verification) Each time the module is powered up it tests that all the cryptographic algorithms operate correctly, and that sensitive data have not been damaged. Pre-operational as well as Conditional Cryptographic Algorithm Self-tests (CAST) are performed on each power up/boot of the module and on demand by power cycling the module (Perform self-tests (remote reset) service). The module performs a CAST for ECDSA P-256 with SHA2-256 prior to executing the firmware integrity check on each boot. The pre-operational firmware integrity test as well as all CASTs must be completed successfully prior to any other use of cryptography by the module in the Approved mode of operation. These tests can also be performed periodically by rebooting the module. If the pre-operation firmware integrity test or if any of the CASTs fail, then the module returns the error indicator “FIPS error: self-test failure”, inhibits all data output and enters the hard error state. Conditional Self-Tests are performed by the module when the corresponding condition is met. The pairwise consistency tests are performed on key pair generation for use in signature generation/verification (ECDSA and/or RSA tests) and/or for use in KAS-ECC SSP agreement (ECDSA tests). The firmware load test is performed when a firmware image is loaded onto the module from an external source. If the conditional self-tests fail, the module enters the soft error state, i.e., it rejects the generated keypair/loaded image, returns an error indicator and resumes normal operation. The error indicator is the return code -1 in case of a pairwise consistency test failure and “ERROR: Failed signature check” for the firmware load test failure. Public Material
• May be reproduced only in its original entirety (without revision).

11. Life-cycle Assurance The Crypto Officer must follow the procedures defined below for secure installation, initialization, startup and operation of the module. Crypto Officer Guidance The Crypto Officer must check to verify the firmware image being loaded on the module is the FIPS 140-3 validated version/image. If the image is the FIPS 140-3 validated image, then proceed with installation of the image. Installing The Firmware Image 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. Connect to the console port on the device from your management device and log in to the Junos OS CLI. Copy the firmware package to the device to the /var/tmp/ directory. Install the new package on the device using the following command: operator@device> request vmhost software add /var/tmp/<package>.tgz. NOTE: If you need to terminate the installation, do not reboot your device; instead, finish the installation and then issue the request system software delete package.tgz command, where package.tgz is, for example, junos-vmhost-install-ptx-x86-64-22.4R2.8.tgz.This is your last chance to stop the installation. Reboot the device to complete the load and start the installation: operator@device> request vmhost reboot After the reboot has completed, log in and use the show version command to verify that the new version of the firmware is successfully installed. Also install the built-in fips-mode.tgz package needed for enabling the Approved-mode and the jpfe-fips package needed for execution of the CASTs. Please note that this is a one-time installation post which the module remains in the Approved mode once enabled and automatically executes the CASTs on each boot without requiring any operator or external intervention. The following are the commands used for installing these packages: operator@device >request system software add optional://fips-mode.tgz operator@device >request system software add optional://jpfe-fips.tgz Enabling Approved Mode of Operation Public Material – May be reproduced only in its original entirety (without revision).

The Crypto Officer is responsible for initializing the module in the Approved mode of operation. The Approved mode of operation is not automatically enabled. The Crypto Officer shall place the module in the Approved mode by first zeroising it to ensure no SSPs are present. Next, the cryptographic officer shall follow the steps found in the Junos OS FIPS Evaluated Configuration Guide for PTX1000, Release 22.4R2 document Chapter 2 to place the module into an Approved mode of operation. The steps from the aforementioned document have been reiterated below. To enable the Approved mode in Junos OS on the module:

1. Zeroise the module using the “request vmhost zeroize” command. Once the module comes up in the “amnesiac mode” post zeroisation, connect to it using the console port with username “root”, enter the configuration mode and configure the root-authentication password (i.e., Crypto Officer credentials) as follows: root@device> edit Entering configuration mode [edit] root@device# set system root-authentication plain-text-password New password: Retype new password: [edit] root@device# commit configuration check succeeds commit complete
2. Enable Approved mode on the device by setting the Approved level to 1, and verify the level: [edit] root@device# set system fips level 1 [edit] root@device# show system fips level level 1;
3. Commit the configuration Public Material – May be reproduced only in its original entirety (without revision).

[edit ] root@device# commit configuration check succeeds Generating RSA key /etc/ssh/fips_ssh_host_key Generating RSA2 key /etc/ssh/fips_ssh_host_rsa_key Generating ECDSA key /etc/ssh/fips_ssh_host_ecdsa_key 'system' reboot is required to transition to fips level 1 commit complete

5. Reboot the device: [edit] root@device# run request system reboot Reboot the system ? [yes,no] (no) yes During the reboot, the device runs the pre-operational firmware integrity test and all CASTs. It returns a login prompt as follows: root@device:fips>
6. After the reboot has completed, log in and use the show version command to verify the firmware version is the validated version: root@device:fips > show version Placing the Module in the Non-Approved Mode of Operation As Crypto Officer, the operator needs to disable the Approved mode of operation on the device to return it to the non-Approved mode of operation. To disable the Approved mode on the device, the module must be zeroised (step 1 defined above). No other maintenance requirements apply for operation of the module in the Approved/non-Approved modes as defined above. For further information and for the Administrator and non-Administrator guidance, please see the Junos OS FIPS Evaluated Configuration Guide for PTX1000, Release 22.4R2 document. Public Material – May be reproduced only in its original entirety (without revision).

12. Mitigation of Other Attacks The module does not implement any mitigation of other attacks and thus the requirements per this section do not apply to the module. Public Material – May be reproduced only in its original entirety (without revision).