Juniper Networks PTX10008 and PTX10016 Packet Transport Routers

Certificate

Approved Algorithms (25)

Security Levels (Table 1)

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

flowchart LR
  %% Deterministic review-risk graph for Juniper Networks PTX10008 and PTX10016 Packet Transport Routers
  %% 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>CASTs on boot<br/>Show status<br/>Show status (LED)</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>SSH<br/>HTTPS<br/>no library/version identified</i>"]
    C6["[low] Operating system / runtime<br/>referenced (boundary<br/>membership not asserted)<br/><i>operating system<br/>kernel<br/>application</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 PTX10008 and PTX10016 Packet Transport Routers
  %% 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>CASTs on boot<br/>Show status<br/>Show status (LED)</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>SSH<br/>HTTPS<br/>no library/version identified</i><br/>src: text:keyword"]
    C6["[low] Operating system / runtime referenced (boundary membership not asserted)<br/><i>operating system<br/>kernel<br/>application</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, Inc. Juniper Networks PTX10008 and PTX10016 Packet Transport Routers Document Version 1.0

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 PTX10008 and PTX10016 Packet Transport Routers with Routing Engine JNP10K-RE0 and MACsec Line Card LC1105-M 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 PTX series router models: the PTX10008 and PTX10016 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. This document describes the cryptographic module security policy for the Juniper Networks PTX series router models: the PTX10008 and PTX10016 cryptographic module (also referred to as the “module” hereafter) with firmware version Junos OS 22.4R2.8. The module has a multi-chip 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 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.

Purpose and Use: The cryptographic module provides for an encrypted connection, using SSH, between the management station and itself, i.e., the PTX series routers. The cryptographic module also provides for an encrypted connection, using MACsec, between itself and a peer. Module Type: Hardware Module Embodiment: MultiChipStand Cryptographic Boundary: The cryptographic module’s operational environment is a limited operational environment. The cryptographic boundary of the hardware module is the entirety of the module/chassis. This includes the Routing Engine (RE). No components have been excluded from the cryptographic boundary of the module. Tested Operational Environment’s Physical Perimeter (TOEPP): The Tested Operational Environment’s Physical Perimeter (TOEPP) is the entirety of the module chassis. The images below depict the physical boundary of the modules, including the Routing Engine, the PTX10KLC1105-M MACsec Line Card and SIB. The non-crypto-relevant line cards included in the figure are not inserted in the module/excluded from the boundary per the scope of this validation. Document Version 1.0

Figure 1: Physical Cryptographic Boundary [Left to Right: PTX10008 and PTX10016] Figure 2: Routing Engine [JNP10K-RE0] 1- RCB status LEDs 3- PTP-capable connections: SMB In, SMB Out, 10 MHz In, 10 MHz Out 5- USB 2.0 port 7- Reset (RESET) button 2- Console port (CON) 4- Management port (MGMT) 6- Secondary 50-GB SATA SSD slot 8- Four SFP+ ports (reserved for future use) Document Version 1.0

Figure 3: PTX10K-LC1105-M MACSec Line Card 1- Power LED (PWR), status LED (STS), and offline (OFF) button 2- Network ports. Figure 4: PTX10008 Chassis Rear 1- AC or DC power supplies numbered 0–5 (top to bottom) 2- Fan trays with redundant fans Document Version 1.0

Figure 5: PTX10016 Chassis Rear 1- Power supplies 2- Fan trays 3- ESD point 4- Protective earthing terminal Document Version 1.0

Figure 6: PTX10008 Block diagram Document Version 1.0

Figure 7: PTX10016 Block diagram The PTX10K-LC1105-M has thirty 28-Gbps QSFP+ (QSFP28) ports that are Media Access Control Security (MACsec) capable, each of which can be configured via the CLI to support speeds of 100 Gbps or 40 Gbps. Each of the 30 QSFP28 ports can operate as:

• 100-Gigabit Ethernet ports when using QSFP28 optical transceivers.
• 40-Gigabit Ethernet ports when using QSFP+ optical transceivers.

Tested Module Identification

• Hardware: Document Version 1.0

Table 2: Tested Module Identification

• Hardware

No components have been excluded from the cryptographic boundary of the module. Modes List and Description: NonApproved NonApproved Table 3: Modes List and Description The hardware versions contained in Table 2, with Junos OS 22.4R2.8 installed, contain one Document Version 1.0

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. When operated in the non-Approved mode of operation, the module supports non-Approved algorithms as well as the algorithms supported in the Approved mode of operation. The module is in a non-compliant state by default and the Crypto Officer can place the module into the nonApproved mode of operation by following the instructions in Section 11 Life-Cyle Assurance in this document. Mode Change Instructions and Status: The module must always be zeroised when switching between the Approved mode of operation and the non-Approved mode of operation and vice versa. Degraded Mode Description: The module does not support a degraded mode of operation.

Approved Algorithms: Document Version 1.0

Table 4: Approved Algorithms The following protocols are supported by the module in the Approved mode: SSHv2 (EC Diffie-Hellman P-256, P-384, P-521; Diffie-Hellman MODP2048; RSA 2048, 3072,

4096 bits; ECDSA P-256, P-384, P-521; AES CBC 128, 192, 256 bits; AES CTR 128, 192, 256

bits, HMAC-SHA-1, HMAC-SHA2-256, HMAC-SHA2-512) MACsec (MACsec Key Agreement (MKA); AES GCM, XPN 128 and 256 bits) The SSH protocol allows independent selection of key exchange, authentication, cipher and integrity algorithms. Please note that 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 the table above are used by an approved service of the module. Vendor-Affirmed Algorithms: 6.2.1 N/A N/A N/A Table 5: Vendor-Affirmed Algorithms Non-Approved, Allowed Algorithms: Document Version 1.0

N/A N/A N/A Table 6: Non-Approved, Allowed Algorithms 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. The module does not support any non-Approved algorithms in the Approved mode, i.e., it does Table 8: Non-Approved, Not Allowed Algorithms In addition to the above non-Approved Algorithms Not Allowed in the Approved Mode of Operation, all Approved algorithms supported in the Approved mode of operation are also Document Version 1.0

AsymKeyPairKeyVer SP 80056Arev3 SP80056Arev3 KAS-ECCSSC Sp80056Ar3 KAS-FFCSSC Sp80056Ar3 HMACSHA-1 HMACSHA2-256 HMACSHA2-512 Document Version 1.0

DigSigSigGen DigSigSigGen HMACSHA2-256 HMACSHA2-256 Document Version 1.0

DigSigSigGen 6.2.1 HMACSHA-1 HMACSHA2-256 HMACSHA2-512 KAS-ECCSSC Sp80056Ar3 KAS-FFCSSC Sp80056Ar3 Document Version 1.0

Table 9: Security Function Implementations HMACSHA2-256

The module only supports testable RSA moduli/key sizes (2048, 3072 and 4096 bits) and thus the requirements per FIPS 140-3 IG C.F do not apply.

Table 10: Entropy Certificates NonPhysical Table 11: Entropy Sources Document Version 1.0

The module implements two NIST SP 800-90Ar1 DRBGs and supports the following sections per NIST SP 800-133r2 (CKG): Sections 4, 5.1, 5.2 and 6.2.1.

Per IG D.F: The module implements full KAS (KAS-ECC-SSC, KAS-FFC-SSC per NIST SP 800-56Ar3 and KDF SSH per NIST SP 800-135r1; IG D.F Scenario 2 (path 2 option 2, separate testing of the SSC and SP800-135r1 KDF). The KAS1 and KAS2 in the SFI Table have been documented in accordance with this requirement: KAS1: KAS (KAS-ECC-SSC Cert.#A4301 and CVL Cert. #A4301; SSP establishment methodology provides between 128 and 256 bits of encryption strength) KAS2: KAS (KAS-FFC-SSC Cert.#A4301 and CVL Cert. #A4301; SSP establishment methodology provides 112 bits of encryption strength) The Approved Algorithm list includes the tested components (KAS-ECC-SSC, KAS-FFC-SSC and KDF SSH) as individual entries. Per IG D.G: The module supports the IETF SSH and MACsec protocols and thus implements key transport in the context of the protocols (per the KTS1 and KTS2 entries in the SFI table of the Security Policy). The module implements the following approved KTS using approved AES modes: AES CBC and CTR (KTS1): KTS (AES Cert. #A4301 and HMAC Cert. #A4301; SSP establishment methodology provides between 128 and 256 bits of encryption strength) AES KW (KTS2): KTS (AES Cert. #A4304; SSP establishment methodology provides between

No parts of the SSH and MACsec protocols, other than the KDF SSH and the NIST SP 800-108 KDF for MACsec, have been tested by the CAVP or CMVP.

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. Document Version 1.0

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.
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. MACsec protocol IV generation: • The AES GCM IV construction is performed internal to the module in compliance with IEEE 802.1AEand its amendments. The IV length is 96 bits (per SP 800-38D). The module ensures the IV is constructed deterministically per Section 8.2 in SP 800-38D and the MACsec standard IEEE 802.1AE as a result of concatenating the fixed field (SCI) and invocation field (PN). • The module can take on the role of Peer or Authenticator in reference to the MACsec protocol. • The module shall only be used with other FIPS 140-3 validated modules when supporting the MACsec protocol in the role of a Peer/Authenticator for providing the remaining functionalities. • Per FIPS 140-3 IG C.H Scenario 3, if the module loses power and then it is restored, then a new key shall be established for use with the AES GCM encryption/decryption processes. • The link between the Peer and Authenticator, used in the MACsec communication, shall be secure to prevent the possibility for an attacker to introduce foreign equipment into the local area network.
13. The module shall not be configured to use a radius server and the radius server capability shall be disabled.

Table 12: Ports and Interfaces The module does not support control output.

Table 13: Authentication Methods 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 keybased authentication over SSHv2.

Table 14: Roles The module supports two roles: Crypto Officer (CO) and User. Root and Super-user correspond to the Crypto Officer role whereas Operator, Read-Only and Unauthorised operator types correspond to the User role. The module supports concurrent operators but does not support a maintenance role and/or bypass capability. An operator assuming 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.

e (nonsecurity n r Nonsecurity W,E W,E E Document Version 1.0

n r N/A <cryptoofficer/user n plaintextpassword) G,E,Z G,E,Z G,E,Z G,E,Z E d Document Version 1.0

n d r n connectivityassociation connectivityassociationname; set connectivityassociation connectivityassociationname preshared key) Table 15: Approved Services E E

SigVer, noncompliant) HMACRIPEMD160 SigVer, noncompliant) HMACRIPEMD160 Document Version 1.0

Table 16: Non-Approved Services

The module supports loading of firmware from an external source (a complete image replacement) and a firmware load test using ECDSA P-256 with SHA2-256 (CAVP Cert. #A4301) is performed in support of the load.

The module supports self-initiated cryptographic output in the context of the MACsec protocol and three independent configurations are required serving as three independent internal actions (two actions required at minimum):

• set security macsec connectivity-association <name> cipher-suite set interfaces <name> connectivity-association <name> set interfaces <name> unit 0 family inet address <ip address> The following “show” commands indicate the status of the MACsec service:
• show security macsec connections
• show security mka sessions
• show security mka statistics

The module performs the firmware integrity check using ECDSA P-256 with SHA2-256 (CAVP Cert. #A4301). The ECDSA P-256 public key used for signature verification is a non-SSP and stored persistently across reboots in the module’s Non-Volatile RAM (NVRAM) and is exempt from zeroisation. Document Version 1.0

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

Type of Operational Environment: Limited How Requirements are Satisfied: The module contains a limited operational environment since it supports loading of firmware from an external source. The Junos OS 22.4R2.8 operating system is contained within the module, i.e., the tested configurations listed in the Tested Module Identification

• Hardware in this document.

Security rules and restrictions for configuration of the operational environment have been specified in Sections 2.12 and 11.1 of this document.

N/A N/A N/A Table 17: Mechanisms and Actions Required 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. Document Version 1.0

The module does not implement any non-invasive security mitigations and thus the requirements per this section do not apply to the module.

N/A N/A Table 19: SSP Input-Output Methods Document Version 1.0

The module is complaint with FIPS 140-3 IG 9.5.A MD/DE and AD/EE for SSPs entered via the module’s CLI via a direct connection to its serial/console port and for SSPs entered/output/established via SSH/MACsec respectively.

Table 20: SSP Zeroization Methods N/A h KASECCSSC P256, PDocument Version 1.0

h for KASFFCSSC Document Version 1.0

h KASECCSSC P256, P384, P512 128 bits, for KASECCSSC for KASFFCSSC n Document Version 1.0

Table 21: SSP Table 1 h n n KASECCSSC P256, P384, P512 128 bits, for KASECCSSC for KASFFCSSC Document Version 1.0

powercycle powercycle powercycle powercycle Document Version 1.0

Table 23: Pre-Operational Self-Tests Document Version 1.0

The module is complaint with FIPS 140-3 IG 10.2.A in that it performs a self-test, a Known Answer Test (KAT) for the ECDSA P-256 (with SHA2-256) algorithm used in the firmware integrity test on each boot prior to executing the firmware integrity test.

s Length: 0256 N/A N/A AESCBC AESCBC AESCBC HMACSHA2-256 HMACSHA2256 Document Version 1.0

AESCBC AESCBC AESCBC Length: 0256 , HMACSHA2256 HMACSHA2HMACSHA-1 HMACSHA-1 HMACSHA2-256 HMACSHA2-512 s N/A N/A N/A N/A Document Version 1.0

KASECCSSC Sp80056Ar3 Methods: P256 KASECCSSC Sp80056Ar3 Methods: P384 KASFFCSSC Sp80056Ar3 Cipher: AES128, AES192, AES256 ; Hash 6-4) 6-4) KAS-ECCEPHEMUNIFIEDNOKC KAS-ECCEPHEMUNIFIEDNOKC KAS-FFCEPHEMNOKC s N/A N/A N/A N/A RSAVerify ECDSASign Document Version 1.0

6-4) 6-4) SHA2512 ECDSAVERIFY SHA-2512 6-4) 6-4) KASFFCSSC Sp80056Ar3 6-4) s N/A Document Version 1.0

s SP800108 N/A AESGCM AESGCM AESCMAC AESKEYWRA AESKEYWRA AESCMAC AESCMAC AESCMAC AES128CMAC AES128CMAC AES256CMAC AES256CMAC Document Version 1.0

6-4) W e ! s Table 24: Conditional Self-Tests Cryptographic Algorithm Self-tests (CASTs) are performed on each boot of the module. Other 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-SSC or KASFFC-SSC SSP agreement (ECDSA and FFC tests respectively). The firmware load test is performed when a firmware image is loaded onto the module from an external source.

Table 25: Pre-Operational Periodic Information Document Version 1.0

Table 26: Conditional Periodic Information prior to any other use of cryptography by the module in the Approved mode of operation. These

N/A Table 27: Error States generated keypair/loaded image, returns an error indicator and resumes normal operation. Document Version 1.0

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 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> 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> 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. Document Version 1.0

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 after 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 >request system software add optional://fips-mode.tgz operator >request system software add optional://jpfe-fips.tgz Enabling Approved Mode of Operation 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 PTX Series, 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 rootauthentication password (i.e., Crypto Officer credentials) as follows: root@device> edit Entering configuration mode [edit] root@device# set system root-authentication plain-textpassword 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 Document Version 1.0

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

For further information and for the Administrator guidance, please see the Junos OS FIPS Evaluated Configuration Guide for PTX, Release 22.4R2 document.

For further information and for the Administrator guidance, please see the Junos OS FIPS Evaluated Configuration Guide for PTX, Release 22.4R2 document.

No other maintenance requirements apply for operation of the module in the Approved/nonApproved modes as defined above.

The module can be securely sanitized at the end of its lifetime by zeroising it. Document Version 1.0

The module does not implement any mitigation of other attacks and thus the requirements per this section do not apply to the module. Document Version 1.0

Referenced URLs

• https://csrc.nist.gov/projects/cryptographic-module-validation-program
• https://www.juniper.net/support/downloads/junos.html