SRX1500 Common Criteria Guide Devices

Product Information

Specifications

• Product Name: SRX1500, SRX4100, SRX4200, and SRX4600
  Devices

• Published: 2023-12-21

• Release: 22.2R1

• Manufacturer: Juniper Networks, Inc.

• Address: 1133 Innovation Way Sunnyvale, California 94089
  USA

• Website: www.juniper.net

About This Guide

This guide provides information on the common criteria evaluated
configuration for the SRX1500, SRX4100, SRX4200, and SRX4600
devices. It covers topics such as understanding the FIPS mode of
operation, configuring roles and authentication methods,
configuring administrative credentials and privileges, and
configuring network time protocol (NTP).

Overview

Understanding the Common Criteria Evaluated Configuration

The common criteria evaluated configuration is a set of security
requirements and specifications that have been independently
evaluated and certified for the SRX1500, SRX4100, SRX4200, and
SRX4600 devices. It ensures that the devices meet specific security
standards and can be used in secure environments.

Understanding Junos OS in FIPS Mode of Operation

The FIPS mode of operation is a security feature that enables
the SRX devices to operate in compliance with the Federal
Information Processing Standards (FIPS). It provides enhanced
security measures and cryptographic algorithms to protect sensitive
data.

Understanding FIPS Mode of Operation Terminology and Supported

Cryptographic Algorithms

This section explains the terminology used in the FIPS mode of
operation and provides information on the supported cryptographic
algorithms. It helps users understand the security features and
capabilities of the devices.

Identifying Secure Product Delivery

This section guides users on how to identify if the product has
been securely delivered. It covers topics such as tamper-evident
seals and cryptographic modules.

Understanding Management Interfaces

This section provides information on the management interfaces
available on the SRX devices. It explains how to access and
configure these interfaces for device management.

Configuring Roles and Authentication Methods

Understanding Roles and Services for Junos OS in FIPS Mode of

Operation

This section explains the roles and services available for Junos
OS in the FIPS mode of operation. It helps users understand how to
configure and manage user roles and authentication methods for
secure access to the devices.

Understanding Services for Junos OS in FIPS Mode of

Operation

This section provides detailed information on the services
available for Junos OS in the FIPS mode of operation. It covers
topics such as SSH, SNMP, and HTTPS, and explains how to configure
and secure these services.

Downloading Software Packages from Juniper Networks

This section guides users on how to download software packages
from Juniper Networks. It provides step-by-step instructions on
accessing the download portal and selecting the appropriate
software packages for the SRX devices.

Installing Junos Software Packages

This section explains the process of installing Junos software
packages on the SRX devices. It covers topics such as verifying
package integrity, transferring packages to the devices, and
initiating the installation process.

Understanding Zeroization to Clear System Data for FIPS Mode of

Operation

Zeroization is a process that clears all system data, including
cryptographic keys and configurations, to ensure data security.
This section explains how to perform zeroization on the SRX devices
in the FIPS mode of operation.

Loading Firmware on the Device

This section provides instructions on how to load firmware on
the SRX devices. It covers topics such as preparing the firmware
image, transferring it to the devices, and initiating the firmware
upgrade process.

How to Enable and Configure Junos OS in FIPS Mode of

Operation

This section guides users on how to enable and configure Junos
OS in the FIPS mode of operation. It covers topics such as setting
the FIPS mode, configuring cryptographic modules, and verifying the
FIPS mode status.

Configuring Administrative Credentials and Privileges

Understanding the Associated Password Rules for an Authorized

Administrator

This section provides information on the password rules
associated with an authorized administrator account. It explains
the requirements for creating strong and secure passwords.

Configuring a Network Device Protection Profile Authorized

Administrator

This section guides users on how to configure a network device
protection profile authorized administrator. It explains the steps
to create an administrator account with the necessary privileges to
manage the SRX devices.

Network Time Protocol

NTP Overview

This section provides an overview of the Network Time Protocol
(NTP) and its importance in maintaining accurate time
synchronization across network devices.

Network Time Security (NTS) Support for NTP

This section explains the Network Time Security (NTS) support
for NTP. It covers the benefits of using NTS and provides
instructions on how to configure NTS for secure time
synchronization.

NTP Time Servers

This section provides information on NTP time servers and their
role in providing accurate time information to network devices. It
explains how to select and configure NTP time servers for the SRX
devices.

Configure NTP Time Server and Time Services

This section guides users on how to configure NTP time servers
and time services on the SRX devices. It covers topics such as
configuring server addresses, enabling authentication, and managing
time synchronization settings.

Configure the Router or Switch to Operate in Client Mode

This section provides instructions on how to configure the SRX
devices to operate in client mode for NTP. It explains the steps to
synchronize time with NTP servers.

Configure the Router or Switch to Operate in Symmetric Active

Mode

This section explains how to configure the SRX devices to
operate in symmetric active mode for NTP. It covers topics such as
configuring peer addresses and establishing symmetric
associations.

Configure the Router or Switch to Operate in Broadcast

Mode

This section guides users on how to configure the SRX devices to
operate in broadcast mode for NTP. It explains the steps to
broadcast time information to other network devices.

Configure the Router or Switch to Operate in Server Mode

This section provides instructions on how to configure the SRX
devices to operate in server mode for NTP. It covers topics such as
configuring reference clocks and serving time information to client
devices.

Example: Configure NTP as a Single Time Source for Router and

Switch Clock Synchronization

This section provides an example configuration for using NTP as
a single time source for clock synchronization on the SRX devices.
It explains the steps to configure NTP and verify the clock
synchronization status.

Synchronize and Coordinate Time Distribution Using NTP

This section explains how to synchronize and coordinate time
distribution across network devices using NTP. It covers topics
such as configuring time zones, enabling leap second handling, and
troubleshooting time synchronization issues.

FAQ

Q: Are the SRX devices compatible with other Juniper Networks

products?

A: Yes, the SRX devices are compatible with other Juniper
Networks products. They can be integrated into existing Juniper
Networks infrastructure for enhanced network security.

Q: Can I upgrade the firmware on the SRX devices without

interrupting network connectivity?

A: Yes, the firmware upgrade process on the SRX devices is
designed to minimize network interruptions. However, it is
recommended to schedule firmware upgrades during maintenance
windows to avoid any potential disruptions.

Q: How often should I perform zeroization on the SRX

devices?

A: The frequency of performing zeroization on the SRX devices
depends on the security requirements of your environment. It is
recommended to follow your organization’s security policies and
guidelines regarding zeroization.

Q: Can I configure multiple NTP time servers on the SRX

devices?

A: Yes, you can configure multiple NTP time servers on the SRX
devices for increased reliability and redundancy. It is recommended
to configure at least three time servers for optimal time
synchronization.

Q: How can I troubleshoot NTP synchronization issues on the SRX

devices?

A: If you experience NTP synchronization issues on the SRX
devices, you can start by checking the NTP configuration, verifying
the connectivity to the time servers, and reviewing the system logs
for any error messages. You can also consult the Juniper Networks
support resources for further assistance.

Junos® OS
Common Criteria Guide for SRX1500, SRX4100, SRX4200, and SRX4600 Devices

Published
2023-12-21

RELEASE
22.2R1

ii
Juniper Networks, Inc. 1133 Innovation Way Sunnyvale, California 94089 USA 408-745-2000 www.juniper.net
Juniper Networks, the Juniper Networks logo, Juniper, and Junos are registered trademarks of Juniper Networks, Inc. in the United States and other countries. All other trademarks, service marks, registered marks, or registered service marks are the property of their respective owners.
Juniper Networks assumes no responsibility for any inaccuracies in this document. Juniper Networks reserves the right to change, modify, transfer, or otherwise revise this publication without notice.
Junos® OS Common Criteria Guide for SRX1500, SRX4100, SRX4200, and SRX4600 Devices 22.2R1 Copyright © 2023 Juniper Networks, Inc. All rights reserved.
The information in this document is current as of the date on the title page.
YEAR 2000 NOTICE
Juniper Networks hardware and software products are Year 2000 compliant. Junos OS has no known time-related limitations through the year 2038. However, the NTP application is known to have some difficulty in the year 2036.
END USER LICENSE AGREEMENT
The Juniper Networks product that is the subject of this technical documentation consists of (or is intended for use with) Juniper Networks software. Use of such software is subject to the terms and conditions of the End User License Agreement (“EULA”) posted at https://support.juniper.net/support/eula/. By downloading, installing or using such software, you agree to the terms and conditions of that EULA.

iii

Table of Contents

About This Guide | viii

1

Overview

Understanding the Common Criteria Evaluated Configuration | 2

Understanding Junos OS in FIPS Mode of Operation | 3

Understanding FIPS Mode of Operation Terminology and Supported Cryptographic Algorithms | 5

Identifying Secure Product Delivery | 8

Applying Tamper-Evident Seals to the Cryptographic Module | 10

Understanding Management Interfaces | 12

2

Configuring Roles and Authentication Methods

Understanding Roles and Services for Junos OS in FIPS Mode of Operation | 14

Understanding Services for Junos OS in FIPS Mode of Operation | 16

Downloading Software Packages from Juniper Networks | 21

Installing Junos Software Packages | 21

Understanding Zeroization to Clear System Data for FIPS Mode of Operation | 22

Loading Firmware on the Device | 24

How to Enable and Configure Junos OS in FIPS Mode of Operation | 24

3

Configuring Administrative Credentials and Privileges

Understanding the Associated Password Rules for an Authorized Administrator | 29

Configuring a Network Device Protection Profile Authorized Administrator | 31

4

Network Time Protocol

NTP Overview | 34 Network Time Security (NTS) Support for NTP | 35

iv

NTP Time Servers | 38

Configure NTP Time Server and Time Services | 39 Configure the Router or Switch to Operate in Client Mode | 40

Configure the Router or Switch to Operate in Symmetric Active Mode | 41

Configure the Router or Switch to Operate in Broadcast Mode | 41

Configure the Router or Switch to Operate in Server Mode | 42

Example: Configure NTP as a Single Time Source for Router and Switch Clock Synchronization | 43

Synchronize and Coordinate Time Distribution Using NTP | 44 Configure NTP | 44

Configure NTP Boot Server | 45

Specify a Source Address for an NTP Server | 46

NTP Configuration | 48

Example: Configure NTP | 51 Requirements | 51

Overview | 52

Configuration | 52

Verification | 54

NTP Authentication Keys | 56

Configure Devices to Listen to Broadcast Messages Using NTP | 57

Configure Devices to Listen to Multicast Messages Using NTP | 57

5

Configuring SSH and Console Connection

Understanding FIPS Authentication Methods | 60

Configuring a System Login Message and Announcement | 61

Limiting the Number of User Login Attempts for SSH Sessions | 62

Configuring SSH on the Evaluated Configuration | 63

v

6

Configuring the Remote Syslog Server

Sample Syslog Server Configuration on a Linux System | 66

Configuring Event Logging to a Local File | 66

Configuring Event Logging to a Remote Server | 67

Configuring Event Logging to a Remote Server when Initiating the Connection from the Remote Server | 67

Forwarding Logs to the External Syslog Server | 73

7

Configuring Audit Log Options

Configuring Audit Log Options in the Evaluated Configuration | 75

Configuring Audit Log Options for SRX1500, SRX4100, SRX4200, and SRX4600 Devices | 75

Sample Code Audits of Configuration Changes | 76

8

Configuring Event Logging

Event Logging Overview | 81

Interpreting Event Messages | 86

Logging Changes to Secret Data | 87

Login and Logout Events Using SSH | 89

Logging of Audit Startup | 89

9

Configuring a Secure Logging Channel

Creating a Secure Logging Channel | 92

10

Configuring VPNs

Configuring VPN on a Device Running Junos OS | 100

11

Configuring Security Flow Policies

Understanding a Security Flow Policy on a Device Running Junos OS | 124

12

Configuring Traffic Filtering Rules

Overview | 129

Understanding Protocol Support | 129

vi

Configuring Traffic Filter Rules | 131

Configuring Default Deny-All and Reject Rules | 132

Logging the Dropped Packets Using Default Deny-all Option | 133

Configuring Mandatory Reject Rules for Invalid Fragments and Fragmented IP Packets | 134

Configuring Default Reject Rules for Source Address Spoofing | 135

Configuring Default Reject Rules with IP Options | 136

Configuring Default Reject Rules | 137

13

Configuring Network Attacks

Configuring IP Teardrop Attack Screen | 139

Configuring TCP Land Attack Screen | 140

Configuring ICMP Fragment Screen | 142

Configuring Ping-Of-Death Attack Screen | 144

Configuring tcp-no-flag Attack Screen | 146

Configuring TCP SYN-FIN Attack Screen | 148

Configuring TCP fin-no-ack Attack Screen | 150

Configuring UDP Bomb Attack Screen | 152

Configuring UDP CHARGEN DoS Attack Screen | 152

Configuring TCP SYN and RST Attack Screen | 154

Configuring ICMP Flood Attack Screen | 157

Configuring TCP SYN Flood Attack Screen | 158

Configuring TCP Port Scan Attack Screen | 160

Configuring UDP Port Scan Attack Screen | 162

Configuring IP Sweep Attack Screen | 164

14

Configuring the IDP Extended Package

IDP Extended Package Configuration Overview | 167

vii

15

Configuring Cluster Mode

Understanding Cluster Mode | 169

Configuring L2 HA Link Encryption tunnel | 169

Configuring PKI Based L2HA Link Encryption | 174

16

Performing Self-Tests on a Device

Understanding FIPS Self-Tests | 185

17

Configuration Statements

checksum-validate | 196

code | 198

data-length | 199

destination-option | 201

extension-header | 203

header-type | 204

home-address | 206

identification | 208

icmpv6 (Security IDP Custom Attack) | 210

ihl (Security IDP Custom Attack) | 212

option-type | 213

reserved (Security IDP Custom Attack) | 215

routing-header | 217

sequence-number (Security IDP ICMPv6 Headers) | 218

type (Security IDP ICMPv6 Headers) | 220

viii
About This Guide
Use this guide to configure and evaluate SRX1500, SRX4100, SRX4200, and SRX4600 devices for Common Criteria (CC) compliance. Common Criteria for information technology is an international agreement signed by several countries that permit the evaluation of security products against a common set of standards.
RELATED DOCUMENTATION Common Criteria and FIPS Certifications

1 CHAPTER
Overview
Understanding the Common Criteria Evaluated Configuration | 2 Understanding Junos OS in FIPS Mode of Operation | 3 Understanding FIPS Mode of Operation Terminology and Supported Cryptographic Algorithms | 5 Identifying Secure Product Delivery | 8 Applying Tamper-Evident Seals to the Cryptographic Module | 10 Understanding Management Interfaces | 12

2
Understanding the Common Criteria Evaluated Configuration
IN THIS SECTION Understanding Common Criteria | 3 Supported Platforms | 3
This document describes the steps required to duplicate the configuration of the device running Junos OS when the device is evaluated. This is referred to as the evaluated configuration. The following list describes the standards to which the device has been evaluated: · Collaborative Protection Profile for Network Devices, NDcPPv2.2e–https://
www.commoncriteriaportal.org/files/ppfiles/CPP_ND_V2.2E.pdf. PP modules for NDcPP are as follows: · MOD_FW_CPP v1.4e ­https://www.niap- ccevs.org/MMO/PP/MOD_CPP_FW_v1.4e.pdf · MOD_IPS_V1.0 ­https://www.niap- ccevs.org/MMO/PP/MOD_IPS_v1.0.pdf · VPNGW_MOD v1.1 ­ https://www.niap- ccevs.org/MMO/PP/mod_vpngw_v1.1.pdf · Network Device Collaborative Protection Profile (NDcPPv2.2)/Stateful Traffic Filter Firewall Collaborative Protection Profile (FWcPP) Extended Package VPN Gateway, Version 2.2, 22 March 2020 (VPNEP) · Collaborative Protection Profile for Stateful Traffic Filter Firewalls, version 2.0, 14 March 2018 (FWcPP)https://www.commoncriteriaportal.org/files/ppfiles/CPP_FW_V2.0E.pdf · Collaborative Protection Profile for Network Devices or Collaborative Protection Profile for Stateful Traffic Filter Firewalls Extended Package (EP) for Intrusion Prevention Systems (IPS), (IPSEP) · FIPS–https://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf These documents are available at https://www.niap-ccevs.org/Profile/PP.cfm.

3
NOTE: On SRX1500, SRX4100, SRX4200, and SRX4600 devices, Junos OS Release 22.2R1 is certified for Common Criteria with FIPS mode enabled on the devices.
Understanding Common Criteria
Common Criteria for information technology is an international agreement signed by several countries that permits the evaluation of security products against a common set of standards. In the Common Criteria Recognition Arrangement (CCRA) at http://www.commoncriteriaportal.org/ccra/, the participants agree to mutually recognize evaluations of products performed in other countries. All evaluations are performed using a common methodology for information technology security evaluation. For more information on Common Criteria, see http://www.commoncriteriaportal.org/.
Supported Platforms
For the features described in this document, the following platforms are supported: · The IPSEP, NDcPP, FWcPP, and VPNEP apply to:
· SRX1500, SRX4100, SRX4200, and SRX4600
RELATED DOCUMENTATION Identifying Secure Product Delivery | 8
Understanding Junos OS in FIPS Mode of Operation
IN THIS SECTION About the Cryptographic Boundary on Your Device | 4

4
How FIPS Mode of Operation Differs from Non-FIPS Mode of Operation | 5 Validated Version of Junos OS in FIPS Mode of Operation | 5
Federal Information Processing Standards (FIPS) 140-3 defines security levels for hardware and software that perform cryptographic functions. Junos-FIPS is a version of the Junos operating system (Junos OS) that complies with Federal Information Processing Standard (FIPS) 140-3. Operating SRX Series Firewalls in a FIPS 140-3 Level 2 environment requires enabling and configuring FIPS mode of operation on the device from the Junos OS command-line interface (CLI). The Security Administrator enables FIPS mode of operation in Junos OS Release 22.2R1 and sets up keys and passwords for the system and other FIPS users who can view the configuration. Both user types can also perform normal configuration tasks on the device (such as modify interface types) as individual user configuration allows.
BEST PRACTICE: Be sure to verify the secure delivery of your device and apply tamperevident seals to its vulnerable ports.
About the Cryptographic Boundary on Your Device
FIPS 140-3 compliance requires a defined cryptographic boundary around each cryptographic module on a device. Junos OS in FIPS mode of operation prevents the cryptographic module from running any software that is not part of the FIPS-certified distribution, and allows only FIPS-approved cryptographic algorithms to be used. No critical security parameters (CSPs), such as passwords and keys, can cross the cryptographic boundary of the module by, for example, being displayed on a console or written to an external log file.
CAUTION: Virtual Chassis features are not supported in FIPS mode of operation. Do not configure a Virtual Chassis in FIPS mode of operation.
To physically secure the cryptographic module, all Juniper Networks devices require a tamper-evident seal on the USB and mini-USB ports.

5
How FIPS Mode of Operation Differs from Non-FIPS Mode of Operation
Unlike Junos OS in non-FIPS mode of operation, Junos OS in FIPS mode of operation is a nonmodifiable operational environment. In addition, Junos OS in FIPS mode of operation differs in the following ways from Junos OS in non-FIPS mode of operation: · Self-tests of all cryptographic algorithms are performed at startup. · Self-tests of random number and key generation are performed continuously. · Weak cryptographic algorithms such as Data Encryption Standard (DES) and MD5 are disabled. · Weak, remote, or unencrypted management connections must not be configured. · Passwords must be encrypted with strong one-way algorithms that do not permit decryption. · Junos-FIPS administrator passwords must be at least 10 characters long. · Cryptographic keys must be encrypted before transmission. The FIPS 140-3 standard is available for download from the National Institute of Standards and Technology (NIST) at http://csrc.nist.gov/publications/fips/fips140-3/fips1402.pdf.
Validated Version of Junos OS in FIPS Mode of Operation
To determine the validated version of Junos OS in FIPS mode of operation and for regulatory compliance information about Common Criteria and FIPS for Juniper Networks products, see the Juniper Networks Compliance Advisor.
Understanding FIPS Mode of Operation Terminology and Supported Cryptographic Algorithms
IN THIS SECTION FIPS Terminology | 6 Supported Cryptographic Algorithms | 7

6
Use the definitions of FIPS terms and supported algorithms to help you understand Junos OS in FIPS mode of operation.

FIPS Terminology

Critical security parameter (CSP)

Security-related information–for example, secret and private cryptographic keys and authentication data such as passwords and personal identification numbers (PINs)– whose disclosure or modification can compromise the security of a cryptographic module or the information it protects.

Cryptographic module

The set of hardware, software, and firmware that implements approved security functions (including cryptographic algorithms and key generation) and is contained within the cryptographic boundary. SRX Series devices are certified at FIPS 140-3 Level 2.

Security Administrator

Person with appropriate permissions who is responsible for securely enabling, configuring, monitoring, and maintaining Junos OS in FIPS mode of operation on a device.

ESP

Encapsulating Security Payload (ESP) protocol. The part of the IPsec protocol that

guarantees the confidentiality of packets through encryption. The protocol ensures

that if an ESP packet is successfully decrypted, and no other party knows the secret

key the peers share, the packet was not wiretapped in transit.

FIPS

Federal Information Processing Standards. FIPS 140-3 specifies requirements for

security and cryptographic modules. Junos OS in FIPS mode of operation complies

with FIPS 140-3 Level 2.

IKE

The Internet Key Exchange (IKE) is part of IPsec and provides ways to securely

negotiate the shared private keys that the authentication header (AH) and ESP

portions of IPsec need to function properly. IKE employs Diffie-Hellman key-

exchange methods and is optional in IPsec. (The shared keys can be entered manually

at the endpoints.)

IPsec

The IP Security (IPsec) protocol. A standard way to add security to Internet communications. An IPsec security association (SA) establishes secure communication with another FIPS cryptographic module by means of mutual authentication and encryption.

KATs

Known answer tests. System self-tests that validate the output of cryptographic algorithms approved for FIPS and test the integrity of some Junos OS modules.

7

SA SPI SSH Zeroization

Security association (SA). A connection between hosts that allows them to communicate securely by defining, for example, how they exchange private keys. As Security Administrator, you must manually configure an internal SA on devices running Junos OS in FIPS mode of operation. All values, including the keys, must be statically specified in the configuration.
Security parameter index (SPI). A numeric identifier used with the destination address and security protocol in IPsec to identify an SA. Because you manually configure the SA for Junos OS in FIPS mode of operation, the SPI must be entered as a parameter rather than derived randomly.
A protocol that uses strong authentication and encryption for remote access across a nonsecure network. SSH provides remote login, remote program execution, file copy, and other functions. It is intended as a secure replacement for rlogin, rsh, and rcp in a UNIX environment. To secure the information sent over administrative connections, use SSHv2 for CLI configuration. In Junos OS, SSHv2 is enabled by default, and SSHv1, which is not considered secure, is disabled.
Erasure of all CSPs and other user-created data on a device before its operation as a FIPS cryptographic module–or in preparation for repurposing the device for nonFIPS operation. The Security Administrator can zeroize the system with a CLI operational command.

Supported Cryptographic Algorithms
Each implementation of an algorithm is checked by a series of known answer test (KAT) self-tests. Any self-test failure results in a FIPS error state.

BEST PRACTICE: For FIPS 140-3 compliance, use only FIPS-approved cryptographic algorithms in Junos OS in FIPS mode of operation.

The following cryptographic algorithms are supported in FIPS mode of operation. Symmetric methods use the same key for encryption and decryption, while asymmetric methods (preferred) use different keys for encryption and decryption.

AES

The Advanced Encryption Standard (AES), defined in FIPS PUB 197. The AES algorithm uses

keys of 128, 192, or 256 bits to encrypt and decrypt data in blocks of 128 bits.

8

DiffieHellman

A method of key exchange across a nonsecure environment (such as the Internet). The Diffie-Hellman algorithm negotiates a session key without sending the key itself across the network by allowing each party to pick a partial key independently and send part of that key to the other. Each side then calculates a common key value. This is a symmetrical method, and keys are typically used only for a short time, discarded, and regenerated.

ECDH

Elliptic Curve Diffie-Hellman. A variant of the Diffie-Hellman key exchange algorithm that uses cryptography based on the algebraic structure of elliptic curves over finite fields. ECDH allows two parties, each having an elliptic curve public-private key pair, to establish a shared secret over an insecure channel. The shared secret can be used either as a key or to derive another key for encrypting subsequent communications using a symmetric key cipher.

ECDSA

Elliptic Curve Digital Signature Algorithm. A variant of the Digital Signature Algorithm (DSA) that uses cryptography based on the algebraic structure of elliptic curves over finite fields. The bit size of the elliptic curve determines the difficulty of decrypting the key. The public key believed to be needed for ECDSA is about twice the size of the security level, in bits. ECDSA using the P-256, P-384, or the P-521 curve can be configured under OpenSSH.

HMAC

Defined as “Keyed-Hashing for Message Authentication” in RFC 2104, HMAC combines hashing algorithms with cryptographic keys for message authentication. For Junos OS in FIPS mode of operation, HMAC uses the iterated cryptographic hash function SHA-1 (designated as HMAC-SHA1) along with a secret key.

Identifying Secure Product Delivery
There are several mechanisms provided in the delivery process to ensure that a customer receives a product that has not been tampered with. The customer should perform the following checks upon receipt of a device to verify the integrity of the platform.
· Shipping label–Ensure that the shipping label correctly identifies the correct customer name and address as well as the device.
· Outside packaging–Inspect the outside shipping box and tape. Ensure that the shipping tape has not been cut or otherwise compromised. Ensure that the box has not been cut or damaged to allow access to the device.
· Inside packaging–Inspect the plastic bag and seal. Ensure that the bag is not cut or removed. Ensure that the seal remains intact.

9
If the customer identifies a problem during the inspection, he or she should immediately contact the supplier. Provide the order number, tracking number, and a description of the identified problem to the supplier. Additionally, there are several checks that can be performed to ensure that the customer has received a box sent by Juniper Networks and not a different company masquerading as Juniper Networks. The customer should perform the following checks upon receipt of a device to verify the authenticity of the device: · Verify that the device was ordered using a purchase order. Juniper Networks devices are never
shipped without a purchase order.
· When a device is shipped, a shipment notification is sent to the e-mail address provided by the customer when the order is taken. Verify that this e-mail notification was received. Verify that the email contains the following information: · Purchase order number
· Juniper Networks order number used to track the shipment
· Carrier tracking number used to track the shipment
· List of items shipped including serial numbers
· Address and contacts of both the supplier and the customer
· Verify that the shipment was initiated by Juniper Networks. To verify that a shipment was initiated by Juniper Networks, you should perform the following tasks: · Compare the carrier tracking number of the Juniper Networks order number listed in the Juniper Networks shipping notification with the tracking number on the package received.
· Log on to the Juniper Networks online customer support portal at https://support.juniper.net/ support/ to view the order status. Compare the carrier tracking number or the Juniper Networks order number listed in the Juniper Networks shipment notification with the tracking number on the package received.
RELATED DOCUMENTATION Understanding the Common Criteria Evaluated Configuration

10
Applying Tamper-Evident Seals to the Cryptographic Module
IN THIS SECTION General Tamper-Evident Seal Instructions | 11 Applying Tamper- Evident Seals on the SRX1500 Device | 11 Applying Tamper-Evident Seals on the SRX4100, SRX4200, and SRX4600 Device | 12
The cryptographic modules physical embodiment is that of a multi-chip standalone device that meets Level 2 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. Tamper-evident seals allow the operator to verify if the enclosure has been breached. These seals are not factory-installed and must be applied by the Cryptographic Officer.
NOTE: Seals are available for order from Juniper Networks using part number JNPR-FIPSTAMPER-LBLS.
As a Cryptographic Officer, you are responsible for: · Applying seals to secure the cryptographic module · Controlling any unused seals · Controlling and observing any changes, such as repairs or booting from an external USB drive to the
cryptographic module, that require removing or replacing the seals to maintain the security of the module As per the security inspection guidelines, upon receipt of the cryptographic module, the Cryptographic Officer must check that the labels are free of any tamper evidence.

11
General Tamper-Evident Seal Instructions
All FIPS-certified switches require a tamper-evident seal on the USB ports. While applying seals, follow these general instructions: · Handle the seals with care. Do not touch the adhesive side. Do not cut or otherwise resize a seal to
make it fit. · Make sure all surfaces to which the seals are applied are clean and dry and clear of any residue. · Apply the seals with firm pressure across the seal to ensure adhesion. Allow at least 1 hour for the
adhesive to cure.
Applying Tamper-Evident Seals on the SRX1500 Device
On SRX1500 devices, apply 10 tamper-evident seals at the following locations: · Front pane:
· The front of the SRX1500 has two slot covers. The slot covers should be secured with two screws each and then two tamper-evident labels must applied to the slots. The tamper-evident labels go from the front of the SRX1500 to the top.
· Apply two tamper labels to cover the USB port and two tamper labels to cover the High Availability port.
· Rear pane: · The rear of the SRX1500 has two tamper-evident seals, the tamper-evident seal at top of the rear-view wraps to the top of the device and covers the fourth screw from the side containing the power supply. · Apply one tamper label on the rear of the SRX1500, on the SSD slot cover, to the bottom of the SRX1500. · Apply two tamper labels to cover the indicated screw on the left and right side of the SRX1500 and wrap to the bottom of the SRX1500.

12
Applying Tamper-Evident Seals on the SRX4100, SRX4200, and SRX4600 Device
NOTE: The placement of the tamper evident labels for the SRX4100, SRX4200, and SRX4600 devices is exactly the same.
Apply 11 tamper-evident seals at the following locations: · Apply two tamper- evident labels at the top of the chassis, covering one screw on the top-back left
and one screw on the top-back right. The tamper evident labels cover the screws on the top of the chassis and wrap down each side of the chassis. · Apply three tamper-evident labels at the bottom of the chassis, covering three screws that secure the faceplates on the front of the chassis. The three screws are entirely on the bottom of the chassis, they do not wrap around to any other portion of the chassis. · Apply two tamper-evident labels covering the two USB ports on the front of the SRX4100 and the SRX4200 devices. · Apply two tamper-evident labels covering the two HA ports and two tamper-evident labels covering the second HA port.
Understanding Management Interfaces
The following management interfaces can be used in the evaluated configuration: · Local Management Interfaces–The RJ-45 console port on the rear panel of a device is configured as
RS-232 data terminal equipment (DTE). You can use the command-line interface (CLI) over this port to configure the device from a terminal. · Remote Management Protocols–The device can be remotely managed over any Ethernet interface. SSHv2 is the only permitted remote management protocol that can be used in the evaluated configuration, and it is enabled by default on the device. The remote management protocols J-Web and Telnet are not available for use on the device in the evaluated configuration.
RELATED DOCUMENTATION Understanding the Common Criteria Evaluated Configuration

2 CHAPTER
Configuring Roles and Authentication Methods
Understanding Roles and Services for Junos OS in FIPS Mode of Operation | 14 Understanding Services for Junos OS in FIPS Mode of Operation | 16 Downloading Software Packages from Juniper Networks | 21 Installing Junos Software Packages | 21 Understanding Zeroization to Clear System Data for FIPS Mode of Operation |
22 Loading Firmware on the Device | 24 How to Enable and Configure Junos OS in FIPS Mode of Operation | 24

14
Understanding Roles and Services for Junos OS in FIPS Mode of Operation
IN THIS SECTION Security Administrator Role and Responsibilities | 14 FIPS User Role and Responsibilities | 15 What Is Expected of All FIPS Users | 16
The Juniper Networks Junos operating system (Junos OS) running in non-FIPS mode of operation allows a wide range of capabilities for users, and authentication is identity-based. In contrast, the FIPS 140-3 standard defines two user roles: Security Administrator and FIPS user. These roles are defined in terms of Junos OS user capabilities. All other user types defined for Junos OS in FIPS mode of operation (operator, administrative user, and so on) must fall into one of the two categories: Security Administrator or FIPS user. For this reason, user authentication in FIPS mode of operation is role-based rather than identity-based. In addition to their FIPS roles, both user types can perform normal configuration tasks on the device as individual user configuration allows. Security Administrators and FIPS users perform all FIPS- related configuration tasks and issue all statements and commands for Junos OS in FIPS mode of operation. Security Administrator and FIPS user configurations must follow the guidelines for Junos OS in FIPS mode of operation.
Security Administrator Role and Responsibilities
The Security Administrator is the person responsible for enabling, configuring, monitoring, and maintaining Junos OS in FIPS mode of operation on a device. The Security Administrator securely installs Junos OS on the device, enables FIPS mode of operation, establishes keys and passwords for other users and software modules, and initializes the device before network connection. The Security Administrator can configure and monitor the module through a console or SSH connection.

15
BEST PRACTICE: We recommend that the Security Administrator administer the system in a secure manner by keeping passwords secure and checking audit files.
The permissions that distinguish the Security Administrator from other FIPS users are secret, security, maintenance, and control. For FIPS compliance, assign the Security Administrator to a login class that contains all of these permissions. A user with the Junos OS maintenance permission can read files containing critical security parameters (CSPs).
NOTE: Junos OS in FIPS mode of operation does not support the FIPS 140-3 maintenance role, which is different from the Junos OS maintenance permission.
Among the tasks related to Junos OS in FIPS mode of operation, the Security Administrator is expected to: · Set the initial root password. · Reset user passwords for FIPS-approved algorithms during upgrades from Junos OS. · Set up manual IPsec SAs for configuration with dual Routing Engines. · Examine log and audit files for events of interest. · Erase user-generated files and data on (zeroize) the device.
FIPS User Role and Responsibilities
All FIPS users, including the Security Administrator, can view the configuration. Only the user assigned as the Security Administrator can modify the configuration. The permissions that distinguish Security Administrators from other FIPS users are secret, security, maintenance, and control. For FIPS compliance, assign the FIPS user to a class that contains none of these permissions. FIPS users configure networking features on the device and perform other tasks that are not specific to FIPS mode of operation. FIPS users who are not Security Administrators can perform reboots and view status output.

16
What Is Expected of All FIPS Users
All FIPS users, including the Security Administrator, must observe security guidelines at all times. All FIPS users must: · Keep all passwords confidential. · Store devices and documentation in a secure area. · Deploy devices in secure areas. · Check audit files periodically. · Conform to all other FIPS 140-3 security rules. · Follow these guidelines:
· Users are trusted. · Users abide by all security guidelines. · Users do not deliberately compromise security. · Users behave responsibly at all times.
RELATED DOCUMENTATION Understanding FIPS Mode of Operation Terminology and Supported Cryptographic Algorithms | 5 Understanding Zeroization to Clear System Data for FIPS Mode of Operation
Understanding Services for Junos OS in FIPS Mode of Operation
IN THIS SECTION Understanding Authenticated Services | 17 Critical Security Parameters | 18

17 All services implemented by the module are listed in the tables that follow.

Understanding Authenticated Services

Table 1 on page 17 lists the authenticated services on the device running Junos OS. Table 1: Authenticated services

Authenticated Services

Description

Security Administrator

User (read-only)

User (network)

Configure security Security relevant

x

­

­

configuration

Configure

Non-security

x

­

­

relevant

configuration

Secure traffic

IPsec protected

­

­

x

routing

Status

Display the status x

x

­

Zeroize

Destroy all critical x

­

­

security parameters

(CSPs)

SSH connect

Initiate SSH

x

x

­

connection for SSH

monitoring and

control (CLI)

IPsec connect

Initiate IPsec

x

­

x

connection (IKE)

Console access

Console monitoring x

x

­

and control (CLI)

18

Table 1: Authenticated services (Continued)

Authenticated Services

Description

Security Administrator

User (read-only)

User (network)

Remote reset

Software-initiated x

­

­

reset

Table 2: Unauthenticated traffic

Service

Description

Local reset

Hardware reset or power cycle

Traffic

Traffic requiring no cryptographic services

Critical Security Parameters

Critical security parameters (CSPs) are security-related information such as cryptographic keys and passwords that can compromise the security of the cryptographic module or the security of the information protected by the module if they are disclosed or modified.
Zeroization of the system erases all traces of CSPs in preparation for operating the device as a cryptographic module.
Table 3 on page 18 lists the CSP access rights within services.
Table 3: CSP Access Rights Within Services

Service

CSPs

DRBG_Se DRBG_Stat SSH PHK

ed

e

SSH DH

SSH-SEK ESP-SEK

Configure security

­

E

G, W

­

­

­

19

Table 3: CSP Access Rights Within Services (Continued)

Service

CSPs

DRBG_Se DRBG_Stat SSH PHK

ed

e

SSH DH

SSH-SEK ESP-SEK

Configure

­

­

­

­

­

­

Secure Traffic

­

­

­

­

­

E

Status

­

­

­

­

­

­

Zeroize

Z

Z

Z

Z

Z

Z

SSH connect

­

E

E

G, E

G, E

­

IPSec connect

­

E

­

­

­

G

Console access

­

­

­

­

­

­

Remote reset

G, E

G

­

Z

Z

Z

Local Reset

G, E

G

­

Z

Z

Z

Traffic

­

­

­

­

­

­

Service
Configure security Configure

CSPs IKE-PSK W ­

IKE-Priv G, W ­

IKE-SKEYI

IKE-SKE

IKE-DH-PRI

­

­

­

­

­

­

20

(Continued)
Service
Secure Traffic Status Zeroize SSH connect IPSec connect Console access Remote reset Local Reset Traffic

CSPs IKE-PSK ­ ­ Z ­ E ­ ­ ­ ­

IKE-Priv ­ ­ Z ­ E ­ ­ ­ ­

IKE-SKEYI

IKE-SKE

IKE-DH-PRI

­

E

­

­

­

­

­

­

­

­

­

­

G

G

G

­

­

­

Z

Z

Z

Z

Z

Z

­

­

­

Here: · G = Generate: The device generates the CSP. · E = Execute: The device runs using the CSP. · W = Write: The CSP is updated or written to the device. · Z = Zeroize: The device zeroizes the CSP.

RELATED DOCUMENTATION Understanding Zeroization to Clear System Data for FIPS Mode of Operation Understanding FIPS Authentication Methods | 60

21
Downloading Software Packages from Juniper Networks
To operate in Junos OS in FIPS mode, the device must have the following software package installed. You can download the following Junos OS software packages from the Juniper Networks website: · Junos OS for SRX1500, SRX4100, SRX4200, and SRX4600 devices Release 22.2R1. Before you begin to download the software, ensure that you have a Juniper Networks Web account and a valid support contract. To obtain an account, complete the registration form at the Juniper Networks website: https://userregistration.juniper.net/entitlement/setupAccountInfo.do. To download software packages from Juniper Networks: 1. Using a Web browser, follow the links to the download URL on the Juniper Networks webpage.
https://support.juniper.net/support/downloads/ 2. Log in to the Juniper Networks authentication system using the username (generally your e-mail
address) and password supplied by Juniper Networks representatives. 3. Download the software. See Downloading Software
RELATED DOCUMENTATION Installation and Upgrade Guide
Installing Junos Software Packages
SRX Series devices can provide the security defined by Federal Information Processing Standards (FIPS) 140-3 Level 2 if these devices are operated in the Junos OS in FIPS mode.
NOTE: Junos OS is delivered in signed packages that contain digital signatures to ensure the Juniper Networks software is running. When installing the software packages, Junos OS validates the signatures and the public key certificates used to digitally sign the software packages. If the signature or certificate is found to be invalid (for example, when the certificate validity period has

22
expired or cannot be verified against the root CA stored in the Junos OS internal store), the installation process fails.
To install these software packages, perform the following tasks: 1. Download the Junos OS package and the Junos FIPS mode package from https://support.juniper.net/
support/downloads/. See Downloading Software. 2. Install the Junos OS on your device using a TFTP server, see Installing Junos OS on SRX Series
Devices from the Boot Loader Using a TFTP Server or install Junos OS on your device using the following CLI command: request system software add /<image- path>/ no-copy no-validate reboot.
RELATED DOCUMENTATION Installation and Upgrade Guide
Understanding Zeroization to Clear System Data for FIPS Mode of Operation
IN THIS SECTION Why Zeroize? | 23 When to Zeroize? | 23
Zeroization completely erases all configuration information on the device, including all plaintext passwords, secrets, and private keys for SSH, local encryption, local authentication, and IPsec. To exit the FIPS mode you need to zeroize the device. The cryptographic module provides a non-approved mode of operation in which non-approved cryptographic algorithms are supported. When moving from the non-approved mode of operation to the approved mode of operation, the Security Administrator must zeroize the non-approved mode critical security parameters (CSPs). For SRX1500, SRX4100, SRX4200, and SRX4600 devices, the Security Administrator initiates the zeroization process by entering the request vmhost zeroize hypervisor command

23
from the CLI after enabling FIPS mode of operation. Use of this command is restricted to the Security Administrator.
CAUTION: Perform system zeroization with care. After the zeroization process is complete, no data is left on the device. This command erases all the CSPs, configurations, and the hard disk partitions containing the device image. Hence, the device does not boot up on zeroization and USB reimage is required to recover the device.
Zeroization can be time-consuming. Although all configurations are removed in a few seconds, the zeroization process goes on to overwrite all media, which can take considerable time depending on the size of the media.
Why Zeroize?
Your device is not considered a valid FIPS cryptographic module until all CSPs have been entered–or reentered–while the device is in FIPS mode of operation. For FIPS 140-3 compliance, the only way to exit from FIPS mode is to zeroize the TOE.
When to Zeroize?
As a Security Administrator, perform zeroization in the following situations: · Before FIPS operation–To prepare your device for operation as a FIPS cryptographic module,
perform zeroization to remove the non-approved mode critical security parameters (CSPs) and enable FIPS mode on the device. · Before non-FIPS operation–To begin repurposing your device for non-FIPS operation, perform zeroization on the device.
NOTE: Juniper Networks does not support installing non-FIPS software in a FIPS mode of operation, but doing so might be necessary in certain test environments. Be sure to zeroize the system first.
· When a tamper-evident seal is disturbed–If the seal on an insecure port has been tampered with, the system is considered to be compromised. After applying new tamper-evident seals to the appropriate locations, zeroize the system and set up new passwords and CSPs.

24
Loading Firmware on the Device
The Junos OS 22.2R1 FIPS images only accept the firmware signed with ECDSA and rejects any firmware signed with RSA+SHA1. You cannot downgrade to images that are signed with RSA+SHA1 from “ECDSA signed only” images. In this scenario, the SRX Series Firewall does not load the firmware.
How to Enable and Configure Junos OS in FIPS Mode of Operation
You, as Security Administrator, can enable and configure Junos OS in FIPS mode of operation on your device. Before you begin enabling and configuring FIPS mode of operation on the device: · Verify the secure delivery of your device. See “Identifying Secure Product Delivery” on page 8. · Apply tamper-evident seals. See “Applying Tamper-Evident Seals to the Cryptographic Module” on
page 10. To enable the Junos OS in FIPS mode of operation, perform the following steps: 1. Zeroize the device before enabling FIPS mode of operation
user@host> request system zeroize hypervisor 2. Enable the FIPS mode on the device.
user@host# set system fips level 2 3. Set the root password.
user@host# set system root-authentication plain-text-password. Enter a password. 4. Remove the CSPs on commit check. user@host# commit 5. After you reboot the device, perform integrity and self-test when the module is operating in FIPS mode.

25

6. Configure IKEv2 when AES-GCM is used for encryption of IKE and/or IPSec.

user@host# set security ike proposal encryption-algorithm ?

Possible completions:

aes-128-cbc AES-CBC 128-bit encryption algorithm

aes-128-gcm AES-GCM 128-bit encryption algorithm

aes-192-cbc AES-CBC 192-bit encryption algorithm

aes-256-cbc AES-CBC 256-bit encryption algorithm

aes-256-gcm AES-GCM 256-bit encryption algorithm

user@host# set security ike proposal encryption-algorithm aes-256-gcm

user@host# set security ipsec proposal encryption- algorithm aes-128-gcm

user@host# set security ike gateway version ?

Possible completions:

v1-only

The connection must be initiated using IKE version 1

v2-only

The connection must be initiated using IKE version 2

user@host# set security ike gateway version v2-only

user@host# commit

commit complete

Ensure that the backup image of the firmware is also a JUNOS-FIPS image by issuing the request system snapshot command.

user@host-srx4200:fips> show version Hostname: host-srx4200 Model: srx4200 Junos: 22.2R1.9 JUNOS OS Kernel 64-bit [20220607.2c547a1_builder_stable_12_222] JUNOS OS libs [20220607.2c547a1_builder_stable_12_222] JUNOS OS runtime [20220607.2c547a1_builder_stable_12_222] JUNOS OS time zone information [20220607.2c547a1_builder_stable_12_222] JUNOS network stack and utilities [20220617.153850_builder_junos_222_r1] JUNOS libs [20220617.153850_builder_junos_222_r1] JUNOS OS libs compat32 [20220607.2c547a1_builder_stable_12_222] JUNOS OS 32-bit compatibility [20220607.2c547a1_builder_stable_12_222] JUNOS libs compat32 [20220617.153850_builder_junos_222_r1] JUNOS runtime [20220617.153850_builder_junos_222_r1] Junos vmguest package [20220617.153850_builder_junos_222_r1] JUNOS py extensions [20220617.153850_builder_junos_222_r1] JUNOS py base [20220617.153850_builder_junos_222_r1] JUNOS OS vmguest [20220607.2c547a1_builder_stable_12_222] JUNOS OS crypto [20220607.2c547a1_builder_stable_12_222]

26
JUNOS OS boot-ve files [20220607.2c547a1_builder_stable_12_222] JUNOS na telemetry [22.2R1.9] JUNOS Web Management Platform Package [20220617.153850_builder_junos_222_r1] JUNOS srx libs compat32 [20220617.153850_builder_junos_222_r1] JUNOS srx runtime [20220617.153850_builder_junos_222_r1] JUNOS Routing mpls-oam-basic [20220617.153850_builder_junos_222_r1] JUNOS Routing lsys [20220617.153850_builder_junos_222_r1] JUNOS Routing 32-bit Compatible Version [20220617.153850_builder_junos_222_r1] JUNOS Routing aggregated [20220617.153850_builder_junos_222_r1] Redis [20220617.153850_builder_junos_222_r1] JUNOS probe utility [20220617.153850_builder_junos_222_r1] JUNOS common platform support [20220617.153850_builder_junos_222_r1] JUNOS srx platform support [20220617.153850_builder_junos_222_r1] JUNOS Openconfig [22.2R1.9] JUNOS mtx network modules [20220617.153850_builder_junos_222_r1] JUNOS modules [20220617.153850_builder_junos_222_r1] JUNOS srx modules [20220617.153850_builder_junos_222_r1] JUNOS srx libs [20220617.153850_builder_junos_222_r1] JUNOS L2 RSI Scripts [20220617.153850_builder_junos_222_r1] JUNOS srx Data Plane Crypto Support [20220617.153850_builder_junos_222_r1] JUNOS ike [20220617.153850_builder_junos_222_r1] JUNOS daemons [20220617.153850_builder_junos_222_r1] JUNOS srx daemons [20220617.153850_builder_junos_222_r1] JUNOS High End AppQos Daemon [20220617.153850_builder_junos_222_r1] JUNOS Services URL Filter package [20220617.153850_builder_junos_222_r1] JUNOS Services TLB Service PIC package [20220617.153850_builder_junos_222_r1] JUNOS Services Telemetry [20220617.153850_builder_junos_222_r1] JUNOS Services TCP-LOG [20220617.153850_builder_junos_222_r1] JUNOS Services SSL [20220617.153850_builder_junos_222_r1] JUNOS Services SOFTWIRE [20220617.153850_builder_junos_222_r1] JUNOS Services Stateful Firewall [20220617.153850_builder_junos_222_r1] JUNOS Services RTCOM [20220617.153850_builder_junos_222_r1] JUNOS Services RPM [20220617.153850_builder_junos_222_r1] JUNOS Services PCEF package [20220617.153850_builder_junos_222_r1] JUNOS Services NAT [20220617.153850_builder_junos_222_r1] JUNOS Services Mobile Subscriber Service Container package [20220617.153850_builder_junos_222_r1] JUNOS Services MobileNext Software package [20220617.153850_builder_junos_222_r1] JUNOS Services Logging Report Framework package [20220617.153850_builder_junos_222_r1] JUNOS Services LL-PDF Container package [20220617.153850_builder_junos_222_r1] JUNOS Services Jflow Container package [20220617.153850_builder_junos_222_r1] JUNOS Services Deep Packet Inspection package [20220617.153850_builder_junos_222_r1] JUNOS Services IPSec [20220617.153850_builder_junos_222_r1]

27
JUNOS Services IDS [20220617.153850_builder_junos_222_r1] JUNOS IDP Services [20220617.153850_builder_junos_222_r1] JUNOS Services HTTP Content Management package [20220617.153850_builder_junos_222_r1] JUNOS Services DNS Filter package (i386) [20220617.153850_builder_junos_222_r1] JUNOS Services Crypto [20220617.153850_builder_junos_222_r1] JUNOS Services Captive Portal and Content Delivery Container package [20220617.153850_builder_junos_222_r1] JUNOS Services COS [20220617.153850_builder_junos_222_r1] JUNOS AppId Services [20220617.153850_builder_junos_222_r1] JUNOS Services Application Level Gateways [20220617.153850_builder_junos_222_r1] JUNOS Services AACL Container package [20220617.153850_builder_junos_222_r1] JUNOS Extension Toolkit [20220617.153850_builder_junos_222_r1] JUNOS Packet Forwarding Engine Support (wrlinuxlts19) [20220617.153850_builder_junos_222_r1] JUNOS Packet Forwarding Engine Support (spc3) [20220617.153850_builder_junos_222_r1] JUNOS Packet Forwarding Engine Support (MX/EX92XX Common) [20220617.153850_builder_junos_222_r1] JUNOS Packet Forwarding Engine Support (M/T Common) [20220617.153850_builder_junos_222_r1] JUNOS Packet Forwarding Engine Support (MX Common) [20220617.153850_builder_junos_222_r1] JUNOS Juniper Malware Removal Tool (JMRT) [1.0.0+20220617.153850_builder_junos_222_r1] JUNOS J-Insight [20220617.153850_builder_junos_222_r1] JUNOS jfirmware [20220608.110139_builder_junos_222_r1] JUNOS Online Documentation [20220617.153850_builder_junos_222_r1] JUNOS jail runtime [20220607.2c547a1_builder_stable_12_222] JUNOS fips optest [22.2R1.9] JUNOS FIPS mode utilities [20220617.153850_builder_junos_222_r1] JUNOS dsa dsa [22.2R1.9] The fips keyword next to the hostname in the output indicates that the module is operating in FIPS mode for Junos Software Release 22.2R1for SRX1500, SRX4100, SRX4200, and SRX4600.
RELATED DOCUMENTATION
Loading Firmware on the Device | 24

3 CHAPTER
Configuring Administrative Credentials and Privileges
Understanding the Associated Password Rules for an Authorized Administrator | 29
Configuring a Network Device Protection Profile Authorized Administrator | 31

29
Understanding the Associated Password Rules for an Authorized Administrator
The authorized administrator is associated with a defined login class, and the administrator is assigned with all permissions. Data is stored locally for fixed password authentication.
NOTE: We recommend that you not use control characters in passwords.
Use the following guidelines and configuration options for passwords and when selecting passwords for authorized administrator accounts. Passwords should be: · Easy to remember so that users are not tempted to write it down. · Changed periodically. · Private and not shared with anyone. · Contain a minimum of 10 characters. The minimum password length is 10 characters.
[ edit ] administrator@host# set system login password minimum-length 10
· Include both alphanumeric and punctuation characters, composed of any combination of upper and lowercase letters, numbers, and special characters such as, “!”, “@”, “#”, “$”, “%”, “^”, “&”, “*”, “(“, and “)”. There should be at least a change in one case, one or more digits, and one or more punctuation marks.
· Contain character sets. Valid character sets include uppercase letters, lowercase letters, numbers, punctuation, and other special characters.
[ edit ] administrator@host# set system login password change-type character- sets

30
· Contain the minimum number of character sets or character set changes. The minimum number of character sets required in plain-text passwords in Junos FIPS is 2.
[ edit ] administrator@host# set system login password minimum-changes 2
NOTE: The authentication algorithm for plain-text passwords must be configured as sha256. [ edit ] administrator@host# set system login password format sha256
Weak passwords are: · Words that might be found in or exist as a permuted form in a system file such as /etc/passwd. · The hostname of the system (always a first guess). · Any words appearing in a dictionary. This includes dictionaries other than English, and words found
in works such as Shakespeare, Lewis Carroll, Roget’s Thesaurus, and so on. This prohibition includes common words and phrases from sports, sayings, movies, and television shows. · Permutations on any of the above. For example, a dictionary word with vowels replaced with digits (for example f00t) or with digits added to the end. · Any machine-generated passwords. Algorithms reduce the search space of password-guessing programs and so should not be used. Strong reusable passwords can be based on letters from a favorite phrase or word, and then concatenated with other, unrelated words, along with additional digits and punctuation. If the limit on the consecutive invalid password is reached, the user account is locked. The account automatically unlocks after the configured lockout time expires, or the account can be manually unlocked using the following command:
[ edit ] administrator@host# clear system login lockout user username
NOTE: Passwords should be changed periodically.

31
Configuring a Network Device Protection Profile Authorized Administrator
An account for root is always present in a configuration and is not intended for use in normal operation. In the evaluated configuration, the root account is restricted to the initial installation and configuration of the evaluated device. An NDPP authorized administrator must have all permissions, including the ability to change the router configuration. To configure an authorized administrator: 1. Create a login class named security-admin with all permissions.
[edit] root@host# set system login class security-admin permissions all 2. Define your NDPP user authorized administrator.
[edit] root@host# set system login user NDcPPv2-user class security-admin authentication encryptedpassword
OR
root@host# set system login user NDcPPv2-user class security-admin authentication plain-textpassword 3. Configure the authentication algorithm for plain-text passwords as sha256.
[edit] root@host# set system login password format sha256 4. Commit the changes.
[edit] root@host# commit

32
NOTE: The root password should be reset following the change to sha256 for the password storage format. This ensures the new password is protected using a sha256 hash, rather than the default password hashing algorithm. To reset the root password, use the set system login user root password password command, and confirm the new password when prompted.
RELATED DOCUMENTATION Understanding the Associated Password Rules for an Authorized Administrator | 29

4 CHAPTER
Network Time Protocol
NTP Overview | 34 NTP Time Servers | 38 Configure NTP Time Server and Time Services | 39 Example: Configure NTP as a Single Time Source for Router and Switch Clock Synchronization | 43 Synchronize and Coordinate Time Distribution Using NTP | 44 NTP Configuration | 48 Example: Configure NTP | 51 NTP Authentication Keys | 56 Configure Devices to Listen to Broadcast Messages Using NTP | 57 Configure Devices to Listen to Multicast Messages Using NTP | 57

34
NTP Overview
IN THIS SECTION Network Time Security (NTS) Support for NTP | 35
Network Time Protocol (NTP) is a widely used protocol used to synchronize the clocks of routers and other hardware devices on the Internet. Primary NTP servers are synchronized to a reference clock directly traceable to Coordinated Universal Time (UTC). Reference clocks include GPS receivers and telephone modem services, NTP accuracy expectations depend on the environment application requirements. However, NTP can generally maintain time to within tens of milliseconds over the public internet. NTP is defined in the RFC 5905: Network Time Protocol Version 4: Protocol and Algorithms Specification Devices running Junos OS can be configured to act as an NTP client, a secondary NTP server, or a primary NTP server. These variations are as follows: · Primary NTP Server–Primary NTP servers are synchronized to a reference clock that is directly
traceable to UTC. These servers then re-distribute this time data downstream to other Secondary NTP servers or NTP clients. · Secondary NTP Server–Secondary NTP servers are synchronized to a primary or secondary NTP server. These servers then re-distribute this data downstream to other Secondary NTP servers or NTP clients. · NTP Client–NTP clients are synchronized to a primary or secondary NTP server. Clients do not redistribute this time data to other devices.
NOTE: The NTP subnet includes a number of widely accessible public primary time servers that can be used as a network’s primary NTP server. Juniper Networks strongly recommends that you authenticate any primary servers you use.
Each device on your network can be configured to run in one or more of the following NTP modes: · Broadcast Mode–One or more devices is set up to transmit time information to a specified broadcast
or multicast address. Other devices listen for time sync packets on these addresses. This mode is less accurate than the client/server mode.

35
· Client/Server Mode–Devices are organized hierarchically across the network in client/server relationships.
· Symmetric Active (peer) Mode–Two or more devices are configured as NTP server peers to provide redundancy.
By default, if an NTP client time drifts so that the difference in time from the NTP server exceeds 128 milliseconds, the NTP client is automatically stepped back into synchronization. The NTP client will still synchronize with the server even if the offset between the NTP client and server exceeds the 1000second threshold. You can manually request that a device synchronize with an NTP server by using the set date ntp operational command on the router. On devices running Junos OS that have dual Routing Engines, the backup Routing Engine synchronizes directly with the primary Routing Engine. All Juniper platforms that run Junos OS support the leap second adjustment. By default, if the NTP server is aware of the leap second calculations, then the Junos device will automatically add the 1 second delay. PTP (Precision Time Protocol) is used to detect and propagate leap second synchronization changes throughout all nodes in a network. NTP is also required for Common Criteria compliance. For more information on the Common Criteria certification, see Public Sector Certifications. For more details about the Network Time Protocol, go to the Network Time Foundation website at http://www.ntp.org. NTP supports IPv4 VPN and IPv6 routing and forwarding (VRF) requests on Junos OS. VRF request is also supported on Junos OS Evolved Release 20.2R1 onwards. This enables an NTP server running on a provider edge (PE) router to respond to NTP requests from a customer edge (CE) router. As a result, a PE router can process any NTP request packet coming from different routing instances.
Network Time Security (NTS) Support for NTP
IN THIS SECTION NTS Overview | 36 Benefits of NTS | 36 Network Time Synchronization with NTS | 36

36
NTS Overview
NTS provides cryptographic security for network time synchronization and supports client-server mode of NTP. NTS uses Transport Layer Security (TLS) protocol and Authenticated Encryption with Associated Data (AEAD) to obtain network time in an authenticated manner to the users. NTS also provides support for encryption of NTP extension fields. The most important security processes are dependent on accurate time. Network time synchronization from a malicious source leads to serious consequences. Enabling NTS ensures accurate network time synchronization on your device.
Benefits of NTS
· Provides strong cryptographic protection against wide range of security attacks such as packet manipulation, spoofing, DDOS amplification attacks, and replay attacks
· Ensures accurate network time synchronization from a reliable source · Provides scalability: Servers can serve several clients without manually pre- configuring any client-
specific configuration. Because of the usage of cookies the server does not need to locally store the client specific data such as keys and AEAD algorithm · Prevents tracking of mobile devices
Network Time Synchronization with NTS
NTS consists of two protocols, the NTS Key Establishment protocol (NTS-KE) and the NTP time synchronization using NTS extension fields.
NTS-KE Protocol
In the NTS-KE protocol phase, the NTS-KE protocol manages the initial authentication, NTS parameter negotiation, and key establishment over TLS in the following order: 1. The client performs a TLS handshake with the NTS-KE server and successfully verify the certificates. 2. The client performs the NTS parameters negotiation with the server over the TLS-protected channel.
The cryptographic algorithms negotiated are AEAD methods, which protects the NTP packets in the second phase. 3. The client and the server successfully establish the key material for communication. 4. The server also sends a supply of initial cookies to the client to use in next phase.

37
5. The TLS channel closes and NTP proceeds to the next phase where actual exchange of time data happens.
NTS supports only the TLS version 1.3. The older TLS versions get rejected during the NTS-KE protocol phase.
NTP Time Synchronization Using NTS Extension Fields
This phase manages the encryption and authentication during NTP time synchronization through the extension fields in the NTP packets in the following order:
1. The client queries the NTP server about time with NTS extension fields. These extension fields include cookies and an authentication tag computed using negotiated AEAD algorithm and key material extracted from the NTS-KE handshake.
An NTS-secured NTP client request contains the following NTS extension fields:
· Unique Identifier Extension Field: Contains randomly generated data and provides the means for replay protection at the NTS level.
· NTS Cookie Extension Field: Contains the information about the key material, which establishes during NTS-KE phase, and the negotiated cryptographic algorithm. A cookie is only used once in a request to prevent tracking.
· NTS Cookie Placeholder Extension Field: (Optional) Communicates to the server that the client wants to receive additional cookies in the response packet.
· NTS Authenticator and Encrypted Extension Fields: Generated using AEAD Algorithm and key established during NTS-KE. This field provides the integrity protection for the NTP header and all the previous extension fields.
Constant refreshing of cookies protects a device from tracking when it changes network addresses. For example a mobile device moving across different networks. The lack of any recognizable data prevents an adversary from determining that two packets sent over different network addresses came from the same client.
2. When the server receives an NTS-secured request from the client, the server decrypts the cookie with a master key.
3. The server extracts the negotiated AEAD algorithm and the keys that are available in the cookie. Using this key, the server checks the integrity of the NTP packet to ensure no manipulations to the packet.
4. The server generates one or more new cookies and creates the NTP response packet. The server generates at least one new cookie and one additional cookie for each Cookie Placeholder Extension Field that the client added in the request packet.

38
The response packet contains two NTS extension fields: · The Unique Identifier Extension Field, which has the same contents from the Unique Identifier
field in request packet.
· The NTS Authenticator and Encrypted Extension Field, which secures the NTP header and the previous extension fields using the extracted keys.
5. The server also encrypts the cookies and includes them in the NTS Authenticator and Encrypted Extension Fields. This procedure also protects the client from tracking because an attacker cannot extract the cookies from a response message.
6. The server finalizes the response packet and sends the packet to the client.
7. The client receives the response packet.
8. The client checks the Unique Identifier field and verifies that the Unique Identifier matches with an outstanding request.
9. The client successfully performs the integrity check of the packet using the key and the AEAD algorithm.
10. The client decrypts the cookies and adds them to its pool and processes the time information received from server.
NTP Time Servers
The IETF defined the Network Time Protocol (NTP) to synchronize the clocks of computer systems connected to each other over a network. Most large networks have an NTP server that ensures that time on all devices is synchronized, regardless of the device location. If you use one or more NTP servers on your network, ensure you include the NTS server addresses in your Junos OS configuration. When configuring the NTP, you can specify which system on the network is the authoritative time source, or time server, and how time is synchronized between systems on the network. To do this, you configure the router, switch, or security device to operate in one of the following modes: · Client mode–In this mode, the local router or switch can be synchronized with the remote system,
but the remote system can never be synchronized with the local router or switch.
· Symmetric active mode–In this mode, the local router or switch and the remote system can synchronize with each other. You use this mode in a network in which either the local router or switch or the remote system might be a better source of time.

39
Symmetric active mode can be initiated by either the local or the remote system. Only one system needs to be configured to do so. This means that the local system can synchronize with any system that offers symmetric active mode without any configuration whatsoever. However, we strongly encourage you to configure authentication to ensure that the local system synchronizes only with known time servers. · Broadcast mode–In this mode, the local router or switch sends periodic broadcast messages to a client population at the specified broadcast or multicast address. Normally, you include this statement only when the local router or switch is operating as a transmitter. · Server mode–In this mode, the local router or switch operates as an NTP server. In NTP server mode, the Junos OS supports authentication as follows: · If the NTP request from the client comes with an authentication key (such as a key ID and
message digest sent with the packet), the request is processed and answered based on the authentication key match. · If the NTP request from the client comes without any authentication key, the request is processed and answered without authentication.
Configure NTP Time Server and Time Services
IN THIS SECTION Configure the Router or Switch to Operate in Client Mode | 40 Configure the Router or Switch to Operate in Symmetric Active Mode | 41 Configure the Router or Switch to Operate in Broadcast Mode | 41 Configure the Router or Switch to Operate in Server Mode | 42
When you use NTP, configure the router or switch to operate in one of the following modes: · Client mode · Symmetric active mode · Broadcast mode · Server mode

40
The following topics describe how to configure these modes of operation:
Configure the Router or Switch to Operate in Client Mode
To configure the local router or switch to operate in client mode, include the server statement and other optional statements at the [edit system ntp] hierarchy level:
[edit system ntp] server address ; authentication-key key-number type type value password; trusted-key[key- numbers];
Specify the address of the system acting as the time server. You must specify an address, not a hostname. To include an authentication key in all messages sent to the time server, include the key option. The key corresponds to the key number you specify in the authentication-key statement, as described in . By default, the router or switch sends NTP version 4 packets to the time server. To set the NTP version level to 1, 2, or 3, include the version option. If you configure more than one time server, you can mark one server preferred by including the prefer option. The following example shows how to configure the router or switch to operate in client mode:
[edit system ntp] authentication-key 1 type md5 value “$ABC123″; server 10.1.1.1 key 1 prefer; trusted-key 1;

41
Configure the Router or Switch to Operate in Symmetric Active Mode
To configure the local router or switch to operate in symmetric active mode, include the peer statement at the [edit system ntp] hierarchy level:
[edit system ntp] peer address ;
Specify the address of the remote system. You must specify an address, not a hostname. To include an authentication key in all messages sent to the remote system, include the key option. The key corresponds to the key number you specify in the authentication-key statement. By default, the router or switch sends NTP version 4 packets to the remote system. To set the NTP version level to 1, 2 or 3, include the version option. If you configure more than one remote system, you can mark one system preferred by including the prefer option:
peer address prefer;
Configure the Router or Switch to Operate in Broadcast Mode
To configure the local router or switch to operate in broadcast mode, include the broadcast statement at the [edit system ntp] hierarchy level:
[edit system ntp] broadcast address <ttl value>;
Specify the broadcast address on one of the local networks or a multicast address assigned to NTP. You must specify an address, not a hostname. If the multicast address is used, it must be 224.0.1.1. To include an authentication key in all messages sent to the remote system, include the key option. The key corresponds to the key number you specify in the authentication-key statement. By default, the router or switch sends NTP version 4 packets to the remote system. To set the NTP version level to 1, 2, or 3, include the version option.

42
Configure the Router or Switch to Operate in Server Mode
In server mode, the router or switch acts as an NTP server for clients when the clients are configured appropriately. The only prerequisite for ” server mode” is that the router or switch must be receiving time from another NTP peer or server. No other configuration is necessary on the router or switch. When configuring the NTP service in the management VRF (mgmt_junos), you must configure at least one IP address on a physical or logical interface within the default routing instance and ensure that this interface is up in order for the NTP service to work with the mgmt_junos VRF.
To configure the local router or switch to operate as an NTP server, include the following statements at the [edit system ntp] hierarchy level:
[edit system ntp] authentication-key key-number type type value password; server address ; trusted-key [key- numbers];
Specify the address of the system acting as the time server. You must specify an address, not a hostname.
To include an authentication key in all messages sent to the time server, include the key option. The key corresponds to the key number you specify in the authentication-key statement.
By default, the router or switch sends NTP version 4 packets to the time server. To set the NTP version level to 1,or 2, or 3, include the version option.
If you configure more than one time server, you can mark one server preferred by including the prefer option.
The following example shows how to configure the router or switch to operate in server mode:
[edit system ntp] authentication-key 1 type md5 value “$ABC123”; server 192.168.27.46 prefer; trusted-key 1;

43
Example: Configure NTP as a Single Time Source for
Router and Switch Clock Synchronization
Debugging and troubleshooting are much easier when the timestamps in the log files of all the routers or switches are synchronized, because events that span the network can be correlated with synchronous entries in multiple logs. We strongly recommend using the Network Time Protocol (NTP) to synchronize the system clocks of routers, switches, and other network equipment.
By default, NTP operates in an entirely unauthenticated manner. If a malicious attempt to influence the accuracy of a router or switch’s clock succeeds, it could have negative effects on system logging, make troubleshooting and intrusion detection more difficult, and impede other management functions.
The following sample configuration synchronizes all the routers or switches in the network to a single time source. We recommend using authentication to make sure that the NTP peer is trusted. The bootserver statement identifies the server from which the initial time of day and date is obtained when the router boots. The server statement identifies the NTP server used for periodic time synchronization. The authentication-key statement specifies that an HMAC- Message Digest 5 (MD5) scheme should be used to hash the key value for authentication, which prevents the router or switch from synchronizing with an attacker’s host posing as the time server.
[edit] system {
ntp { authentication-key 2 type md5 value “$ABC123”; # SECRET-DATA boot-server 10.1.4.1; server 10.1.4.2 key 2; trusted key 2;
} }

44
Synchronize and Coordinate Time Distribution Using NTP
IN THIS SECTION Configure NTP | 44 Configure NTP Boot Server | 45 Specify a Source Address for an NTP Server | 46
Using NTP to synchronize and coordinate time distribution in a large network involves these tasks:
Configure NTP
· To configure NTP on the switch, include the ntp statement at the [edit system] hierarchy level:
[edit system] ntp {
authentication-key number type type value password; boot-server (address | hostname); broadcast