Juniper EX4400 Common Criteria Evaluated Configuration User Guide

August 21, 2024
JUNIPer

Juniper EX4400 Common Criteria Evaluated Configuration

Specifications

  • Model: EX4400-24MP, EX4400-24P, EX4400-24T, EX4400-48F, EX4400-48MP, EX4400-48P, EX4400-48T
  • Published: 2024-04-30
  • Release: 22.3R1
  • Manufacturer: Juniper Networks, Inc.

Product Information
The EX4400 series of devices by Juniper Networks are designed for secure and efficient network management. These devices support Common Criteria and FIPS standards to ensure data security and integrity.

Overview

Understanding the Common Criteria Evaluated Configuration:

  • Read through the guide to understand the configuration requirements for Common Criteria evaluation.

Configuring Roles and Authentication Methods
Understanding Roles and Services for Junos OS in Common Criteria and FIPS:

  • Learn about the roles and services available in Junos OS for compliance with Common Criteria and FIPS standards.

Installing Junos OS Software Package

  • Download the required software packages from Juniper Networks.
  • Follow the installation instructions provided in the guide.

Enabling FIPS Mode

  • Follow the steps to enable FIPS mode on the device for enhanced
    security.

Configuring Administrative Credentials and Privileges

Understanding the Associated Password Rules for an Authorized Administrator:

  • Review the password rules for authorized administrators to ensure secure access.

Authentication Methods in FIPS Mode of Operation:

  • Explore the authentication methods available for FIPS mode operation.

FAQs

Q: How do I download software packages from Juniper Networks?
A: You can download software packages from Juniper Networks by visiting their official website and accessing the relevant download section for your device.

Q: What is FIPS mode and why is it important?
A: FIPS mode is a security standard that ensures cryptographic algorithms are implemented correctly for secure data handling. It is important for maintaining data integrity and confidentiality.

1 CHAPTER
Overview
Understanding the Common Criteria Evaluated Configuration | 2 Understanding Junos OS in FIPS Mode | 3 Understanding Common Criteria and FIPS Terminology and Supported Cryptographic Algorithms | 5 Identifying Secure Product Delivery | 9 Understanding Management Interfaces | 11

2
Understanding the Common Criteria Evaluated Configuration
IN THIS SECTION Understanding Common Criteria | 2 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: · NDcPP v2.2e–https://www.niap- ccevs.org/MMO/PP/CPP_ND_V2.2E.pdf The Archived Protection Profiles documents are available at https://www.niap-ccevs.org/Profile/PP.cfm? archived=1.
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 https://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 https://www.commoncriteriaportal.org/. Target of Evaluation (TOE) is a device or a system subjected to evaluation based on the Collaborative Protection Profile (cPP).

3
Supported Platforms
For the features described in this document, the following platforms are supported to qualify NDcPPv2.2e: · EX4400 Series devices (https://www.juniper.net/us/en/products/switches/ex-series.html).
RELATED DOCUMENTATION Identifying Secure Product Delivery | 9
Understanding Junos OS in FIPS Mode
IN THIS SECTION About the Cryptographic Boundary on Your Device | 4 How FIPS Mode Differs from Non-FIPS Mode | 4 Validated Version of Junos OS in FIPS Mode | 4
Federal Information Processing Standards (FIPS) 140-3 defines security levels for hardware and software that perform cryptographic functions. Operating your device in a FIPS 140-3 Level 1 environment requires enabling and configuring FIPS mode on the device from the Junos OS CLI. The Security Administrator enables FIPS mode in Junos OS and sets up keys and passwords for the system and other FIPS users who can view the configuration. Both Security Administrator and user can perform normal configuration tasks on the device (such as modify interface types) as individual user configuration allows.

4
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 prevents the cryptographic module from executing 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 in unencrypted format.
CAUTION: Virtual Chassis features are not supported in FIPS mode. Do not configure a Virtual Chassis in FIPS mode.
How FIPS Mode Differs from Non-FIPS Mode
Unlike Junos OS in non-FIPS mode, Junos OS in FIPS mode is a non-modifiable operational environment. In addition, Junos OS in FIPS mode differs in the following ways from Junos OS in nonFIPS mode: · 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 Message Digest 5 (MD5)
are disabled. · Weak or unencrypted management connections must not be configured. However, TOE allows local
and un-encrypted console access across all modes of operation. · 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.
Validated Version of Junos OS in FIPS Mode
To determine whether a Junos OS release is NIST-validated, see the compliance page on the Juniper Networks Web site (https://apps.juniper.net/compliance/).

5
RELATED DOCUMENTATION Identifying Secure Product Delivery | 9
Understanding Common Criteria and FIPS Terminology and Supported Cryptographic Algorithms
IN THIS SECTION Terminology | 5 Supported Cryptographic Algorithms | 7

Use the definitions of Common Criteria and FIPS terms, and supported algorithms to help you understand Junos OS.

Terminology

Common Criteria
Security Administrator
NDcPPv2.2e

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.
For Common Criteria, user accounts in the TOE have the following attributes: user identity (user name), authentication data (password), and role (privilege). The Security Administrator is associated with the defined login class “security-admin”, which has the necessary permission set to permit the administrator to perform all tasks necessary to manage the Junos OS.
Collaborative Protection Profile for Network Devices, Version 2.2e, dated 23 March 2020.

6

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. For details, see “Understanding the Operational Environment for Junos OS in FIPS Mode” on page 15.

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. For fixed-configuration devices, the cryptographic module is the device case. For modular devices, the cryptographic module is the Routing Engine.

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 complies with FIPS

140-3 Level 1.

FIPS maintenance role

The role the Security Administrator assumes to perform physical maintenance or logical maintenance services such as hardware or software diagnostics. For FIPS 140-3 compliance, the Security Administrator zeroizes the Routing Engine on entry to and exit from the FIPS maintenance role to erase all plain-text secret and private keys and unprotected CSPs.

NOTE: The FIPS maintenance role is not supported on Junos OS in FIPS mode.

Hashing KATs SA

A message authentication method that applies a cryptographic technique iteratively to a message of arbitrary length and produces a hash message digest or signature of fixed length that is appended to the message when sent.
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. For details, see “Understanding FIPS Self-Tests” on page 118.
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

7

SSH Zeroization

running Junos OS in FIPS mode. All values, including the keys, must be statically specified in the configuration. On the devices with more than one Routing Engine, the configuration must match on both ends of the connection between the Routing Engines. For communication to take place, each Routing Engine must have the same configured options, which need no negotiation and do not expire. .
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. For details, see “Understanding Zeroization to Clear System Data for FIPS Mode” on page 23.

Supported Cryptographic Algorithms
Table 1 on page 8 summarizes the high level protocol algorithm support.

8

Table 1: Protocols Allowed in FIPS Mode

Protocol Key Exchange

Authentication

Cipher

Integrity

SSHv2

· dh-group14-sha1 · ECDH-sha2-nistp256 · ECDH-sha2-nistp384 · ECDH- sha2-nistp521

Host (module): · ECDSA P-256 · SSH-RSA Client (user): · ECDSA P-256 · ECDSA P-384 · ECDSA P-521 · SSH-RSA · RSA-SHA2-256 · RSA-SHA2-512

· AES CTR 128 · AES CTR 256 · AES CBC 128 · AES CBC 256

· HMAC-SHA-1 · HMAC-SHA-256 · HMAC-SHA-512

The following cryptographic algorithms are supported in FIPS mode. Symmetric methods use the same key for encryption and decryption, while asymmetric methods 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 or 256 bits to encrypt and decrypt data in blocks of 128 bits.

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

9

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 strength, in bits. ECDSA uses the P-256, P-384, and P-521 curves that 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.

SHA-256, SHA-384, and SHA-512

Secure hash algorithms (SHA) belonging to the SHA-2 standard defined in FIPS PUB 180-2. Developed by NIST, SHA-256 produces a 256-bit hash digest, SHA-384 produces a 384-bit hash digest, and SHA-512 produces a 512-bit hash digest.

AES-CMAC

AES-CMAC provides stronger assurance of data integrity than a checksum or an errordetecting code. The verification of a checksum or an error-detecting code detects only accidental modifications of the data, while CMAC is designed to detect intentional, unauthorized modifications of the data, as well as accidental modifications.

RELATED DOCUMENTATION Understanding FIPS Self-Tests | 118 Understanding Zeroization to Clear System Data for FIPS Mode | 23
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.

10
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 | 2

11
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. The remote management protocols J-Web and Telnet are not available for use on the device.
RELATED DOCUMENTATION Understanding the Common Criteria Evaluated Configuration | 2

2 CHAPTER
Configuring Roles and Authentication Methods
Understanding Roles and Services for Junos OS in Common Criteria and FIPS | 13
Understanding the Operational Environment for Junos OS in FIPS Mode | 15 Understanding Password Specifications and Guidelines for Junos OS in FIPS Mode | 19 Downloading Software Packages from Juniper Networks | 21 Install Junos OS Software Package | 21 Understanding Zeroization to Clear System Data for FIPS Mode | 23 Zeroizing the System | 25 Enabling FIPS Mode | 26 Configuring Security Administrator and FIPS User Identification and Access | 30

13
Understanding Roles and Services for Junos OS in Common Criteria and FIPS
IN THIS SECTION Security Administrator Role and Responsibilities | 13 FIPS User Role and Responsibilities | 14 What Is Expected of All FIPS Users | 14
The Security Administrator is associated with the defined login class “security-admin”, which has the necessary permission set to allow the administrator to perform all tasks necessary to manage the Junos OS. Administrative users (Security Administrator) must provide unique identification and authentication data before any administrative access to the system is granted. Security Administrator roles and responsibilities are as follows: 1. Security Administrator can administer locally and remotely. 2. Create, modify, and delete administrator accounts, including configuration of authentication failure
parameters. 3. Re-enable an Administrator account. 4. Responsible for the configuration and maintenance of cryptographic elements related to the
establishment of secure connections to and from the evaluated product. The Juniper Networks Junos operating system (Junos OS) running in non-FIPS mode allows a wide range of capabilities for users, and authentication is identity- based. Security Administrator performs all FIPS-mode-related configuration tasks and issue all statements and commands for Junos OS in FIPS mode.
Security Administrator Role and Responsibilities
The Security Administrator is the person responsible for enabling, configuring, monitoring, and maintaining Junos OS in FIPS mode on a device. The Security Administrator securely installs Junos OS

14
on the device, enables FIPS mode, establishes keys and passwords for other users and software modules, and initializes the device before network connection.
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). Among the tasks related to Junos OS in FIPS mode, the Security Administrator is expected to: · Set the initial root password. The length of the password should be at least 10 characters. · Reset user passwords with FIPS-approved algorithms. · Examine log and audit files for events of interest. · Erase user-generated files, keys, and data by zeroizing 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. FIPS user can view status output but cannot reboot or zeroize the device.
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.

15
· 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 Zeroizing the System | 25 Configuring Security Administrator and FIPS User Identification and Access | 30
Understanding the Operational Environment for Junos OS in FIPS Mode
IN THIS SECTION Hardware Environment for Junos OS in FIPS Mode | 16 Software Environment for Junos OS in FIPS Mode | 16 Critical Security Parameters | 17
A Juniper Networks device running the Junos operating system (Junos OS) in FIPS mode forms a special type of hardware and software operational environment that is different from the environment of a device in non-FIPS mode:

16
Hardware Environment for Junos OS in FIPS Mode
Junos OS in FIPS mode establishes a cryptographic boundary in the device that no critical security parameters (CSPs) can cross using plain text. Each hardware component of the device that requires a cryptographic boundary for FIPS 140-3 compliance is a separate cryptographic module. There are two types of hardware with cryptographic boundaries in Junos OS in FIPS mode: one for each Routing Engine and one for entire chassis. Cryptographic methods are not a substitute for physical security. The hardware must be located in a secure physical environment. Users of all types must not reveal keys or passwords, or allow written records or notes to be seen by unauthorized personnel.
Software Environment for Junos OS in FIPS Mode
A Juniper Networks device running Junos OS in FIPS mode forms a special type of non-modifiable operational environment. To achieve this environment on the device, the system prevents the execution of any binary file that was not part of the certified Junos OS distribution. When a device is in FIPS mode, it can run only Junos OS. The Junos OS in FIPS mode software environment is established after the Security Administrator successfully enables FIPS mode on a device. The Junos OS image that includes FIPS mode is available on the Juniper Networks website and can be installed on a functioning device. For FIPS 140-3 compliance, we recommend deleting all user-created files and data from (zeroizing) the system immediately after enabling FIPS mode. Enabling FIPS mode disables many of the usual Junos OS protocols and services. In particular, you cannot configure the following services in Junos OS in FIPS mode: · finger · ftp · rlogin · telnet · tftp · xnm-clear-text Attempts to configure these services, or load configurations with these services configured, result in a configuration syntax error.

17
You can use only SSH as a remote access service. All passwords established for users after upgrading to Junos OS in FIPS mode must conform to Junos OS in FIPS mode specifications. Passwords must be between 10 and 20 characters in length and require the use of at least three of the five defined character sets (uppercase and lowercase letters, digits, punctuation marks, and keyboard characters, such as % and &, not included in the other four categories). Attempts to configure passwords that do not conform to these rules result in an error. All passwords and keys used to authenticate peers must be at least 10 characters in length, and in some cases the length must match the digest size.
NOTE: Do not attach the device to a network until you, the Security Administrator, complete the configuration from the local console connection.
For strict compliance, do not examine core and crash dump information on the local console in Junos OS in FIPS mode because some CSPs might be shown in plain text.

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 or Routing Engine as a cryptographic module.
Table 2 on page 17 lists CSPs on the device running Junos OS.
Table 2: Critical Security Parameters

CSP

Description

Zeroization

Use

method

SSH-2 private host key

ECDSA / RSA key used to identify the host, generated the first time SSH is configured.

Zeroize command. Used to identify the host.

18

Table 2: Critical Security Parameters (Continued)

CSP

Description

Zeroization

Use

method

SSH-2 session key

Session key used with SSHv2 and as a Diffie-Hellman private key.
Encryption: AES-128, AES-256.

Power cycle and terminate session.

Symmetric key used to encrypt data between host and client.

MACs: HMAC-SHA-1, HMACSHA-2-256,HMAC-SHA2-512.

Key exchange: dh-group14-sha1, ECDHsha2-nistp256, ECDH-sha2-nistp384, and ECDH-sha2-nistp521.

User authentication Hash of the user’s password: SHA-256,

key

SHA-512.

Zeroize command.

Used to authenticate a user to the cryptographic module.

Security Administrator authentication key

Hash of the Security Administrator’s password: SHA-256, SHA-512.

Zeroize command.

Used to authenticate the Security Administrator to the cryptographic module.

HMAC DRBG seed Seed for deterministic randon bit generator (DRBG).

Seed is not stored by the cryptographic module.

Used for seeding DRBG.

HMAC DRBG V value

The value (V) of output block length (outlen) in bits, which is updated each time another outlen bits of output are produced.

Power cycle.

A critical value of the internal state of DRBG.

HMAC DRBG key value

The current value of the outlen-bit key, which is updated at least once each time that the DRBG mechanism generates pseudorandom bits.

Power cycle.

A critical value of the internal state of DRBG.

19

Table 2: Critical Security Parameters (Continued)

CSP

Description

NDRNG entropy

Used as entropy input string to the HMAC DRBG.

Zeroization method
Power cycle.

Use
A critical value of the internal state of DRBG.

In Junos OS in FIPS mode, all CSPs must enter and leave the cryptographic module in encrypted form. Any CSP encrypted with a non-approved algorithm is considered plain text by FIPS.
Local passwords are hashed with the secure hash algorithm SHA-256, or SHA-512. Password recovery is not possible in Junos OS in FIPS mode. Junos OS in FIPS mode cannot boot into single-user mode without the correct root password.

RELATED DOCUMENTATION Understanding Password Specifications and Guidelines for Junos OS in FIPS Mode | 19 Understanding Zeroization to Clear System Data for FIPS Mode | 23

Understanding Password Specifications and Guidelines for Junos OS in FIPS Mode
Ensure that the device is in FIPS mode before you configure the Security Administrator or any users. All passwords established for users by the Security Administrator must conform to the following Junos OS in FIPS mode requirements. Attempts to configure passwords that do not conform to the following specifications result in an error. · Length. The passwords must contain at least 10 characters. · Character set requirements. Passwords must contain at least three of the following five defined
character sets: · Uppercase letters · Lowercase letters · Digits

20
· Punctuation marks · Keyboard characters not included in the other four sets–such as the percent sign (%) and the
ampersand (&) · Authentication requirements. All passwords and keys used to authenticate peers must contain at
least 10 characters, and in some cases the number of characters must match the digest size. · Password encryption: To change the default encryption method (SHA512) include the format
statement at the [edit system login password] hierarchy level. Guidelines for strong passwords. Strong, reusable passwords can be based on letters from a favorite phrase or word and then concatenated with other unrelated words, along with added digits and punctuation. In general, a strong password is: · Easy to remember so that users are not tempted to write it down. · Made up of mixed alphanumeric characters and punctuation. For FIPS compliance include at least
one change of case, one or more digits, and one or more punctuation marks. · Changed periodically. · Not divulged to anyone. Characteristics of weak passwords. Do not use the following weak passwords: · Words that might be found in or exist as a permuted form in a system files such as /etc/passwd. · The hostname of the system (always a first guess). · Any word or phrase that appears in a dictionary or other well-known source, including dictionaries
and thesauruses in languages other than English; works by classical or popular writers; or common words and phrases from sports, sayings, movies or television shows. · Permutations on any of the above–for example, a dictionary word with letters replaced with digits (root) or with digits added to the end. · Any machine-generated password. Algorithms reduce the search space of password-guessing programs and so must not be used.
RELATED DOCUMENTATION Understanding the Operational Environment for Junos OS in FIPS Mode | 15

21
Downloading Software Packages from Juniper Networks
You can download the Junos OS software package from the Juniper Networks website. 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/. 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 Install Junos OS Software Package | 21
Install Junos OS Software Package
You can use this procedure to upgrade Junos OS on the device with a single Routing Engine.
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 expired or cannot be verified against the root CA stored in the Junos OS internal store), the installation process fails.
To install software upgrades on your device with a single Routing Engine: 1. Download the software package as described in “Downloading Software Packages from Juniper
Networks ” on page 21.

22
2. If you have not already done so, connect to the console port on the device from your management device, and log in to the Junos OS CLI.
3. (Optional) Back up the current software configuration to a second storage option. See the Junos OS Installation and Upgrade Guide for instructions on performing this task.
4. (Optional) Copy the software package to the device. We recommend that you use FTP to copy the file to the /var/tmp/ directory. This step is optional because Junos OS can also be upgraded when the software image is stored at a remote location. These instructions describe the software upgrade process for both scenarios.
5. Install the new package on the device:
user@host> request system software add package
Replace package with one of the following paths: · For a software package in a local directory on the device, use /var/tmp/package.tgz.
· For a software package on a remote server, use one of the following paths, replacing package with the software package name. · ftp://hostname/pathname/package.tgz
· http://hostname/pathname/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. This is your last chance to stop the installation.
6. Reboot the device to load the installation and start the new software:
user@host> request system reboot
7. After the reboot has completed, log in and use the show version command to verify that the new version of the software is successfully installed.
user@host> show version Hostname: hostname Model: ex4400-24t Junos: 22.3R3.5 JUNOS OS Kernel 64-bit [20220603.3f9a7bb_builder_stable_12_214] JUNOS OS libs [20220603.3f9a7bb_builder_stable_12_214]

23
JUNOS OS runtime [20220603.3f9a7bb_builder_stable_12_214] JUNOS OS time zone information [20220603.3f9a7bb_builder_stable_12_214] JUNOS OS libs compat32 [20220603.3f9a7bb_builder_stable_12_214] JUNOS OS 32-bit compatibility [20220603.3f9a7bb_builder_stable_12_214] JUNOS py extensions [20220719.195034_builder_junos_214_r3] JUNOS py base [20220719.195034_builder_junos_214_r3] JUNOS early ex config [20220719.195034_builder_junos_214_r3] JUNOS OS EFI runtime [20220603.3f9a7bb_builder_stable_12_214] JUNOS OS crypto [20220603.3f9a7bb_builder_stable_12_214] JUNOS OS boot-ve files [20220603.3f9a7bb_builder_stable_12_214] JUNOS OS EFI boot files [20220603.3f9a7bb_builder_stable_12_214] JUNOS network stack and utilities [20220719.195034_builder_junos_214_r3] JUNOS libs [20220719.195034_builder_junos_214_r3] JUNOS libs compat32 [20220719.195034_builder_junos_214_r3] JUNOS runtime [20220719.195034_builder_junos_214_r3] JUNOS na telemetry [22.3R3.5] JUNOS Web Management Platform Package [20220719.195034_builder_junos_214_r3] JUNOS ex runtime [20220719.195034_builder_junos_214_r3] Understanding Zeroization to Clear System Data for FIPS Mode
IN THIS SECTION
Why Zeroize? | 24 When to Zeroize? | 24
Zeroization completely erases all configuration information on the Routing Engines, including all plaintext passwords, secrets, and private keys for SSH, local encryption, local authentication, and IPsec.
The Security Administrator initiates the zeroization process by entering the request system zeroize operational command from the CLI after enabling FIPS mode. Use of this command is restricted to the Security Administrator.

24
CAUTION: Perform system zeroization with care. After the zeroization process is complete, no data is left on the Routing Engine. The device is returned to the factory default state, without any configured users or configuration files. 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 critical security parameters (CSPs) have been entered–or reentered–while the device is in FIPS mode. For FIPS 140-3 compliance, the only way to exit from FIPS mode is to zeroize the TOE.
When to Zeroize?
As Security Administrator, perform zeroization in the following situations: · Before Enabling FIPS mode of operation: To prepare your device for operation as a FIPS
cryptographic module, perform zeroization before enabling FIPS mode. · Before repurposing to non-FIPS mode of operation: To begin repurposing your device for non-FIPS
mode of operation, perform zeroization on the device.
NOTE: Juniper Networks does not support installing non-FIPS software in a FIPS environment, but doing so might be necessary in certain test environments. Be sure to zeroize the system first.
RELATED DOCUMENTATION Enabling FIPS Mode | 26

25
Zeroizing the System
Your device is not considered a valid FIPS cryptographic module until all critical security parameters (CSPs) have been entered–or reentered–while the device is in FIPS mode. For FIPS 140-3 compliance, you must zeroize the system to remove sensitive information before disabling FIPS mode on the device. As Security Administrator, you run the request system zeroize command to remove all user-created files from a device and replace the user data with zeros. This command completely erases all configuration information on the Routing Engines, including all rollback configuration files and plain-text passwords, secrets, and private keys for SSH, local encryption, local authentication, and IPsec. To zeroize your device:
CAUTION: Perform system zeroization with care. After the zeroization process is complete, no data is left on the Routing Engine. The device is returned to the factory default state, without any configured users or configuration files.
1. From the CLI, enter
root@host> request system zeroize warning: System will be rebooted and may not boot without configuration Erase all data, including configuration and log files? [yes, no] (no) 2. To initiate the zeroization process, type yes at the prompt:
Erase all data, including configuration and log files? [yes, no] (no) yes warning: zeroizing localre
The entire operation can take considerable time depending on the size of the media, but all critical security parameters (CSPs) are removed within a few seconds. The physical environment must remain secure until the zeroization process is complete.
RELATED DOCUMENTATION Enabling FIPS Mode | 26 Understanding Zeroization to Clear System Data for FIPS Mode | 23

26
Enabling FIPS Mode
FIPS mode is not automatically enabled when you install Junos OS on the device. As Security Administrator, you must explicitly enable FIPS mode on the device by setting the FIPS level to 1 (one), the FIPS 140-3 level at which the devices are certified. A device on which FIPS mode is not enabled has a FIPS level of 0 (zero).
NOTE: To transition to FIPS mode, passwords must be encrypted with a FIPS- compliant hash algorithm. The encryption format must be SHA-256 or higher. Passwords that do not meet this requirement, such as passwords that are hashed with MD5, must be reconfigured or removed from the configuration before FIPS mode can be enabled.
To enable FIPS mode in Junos OS on the device: 1. Enter configuration mode:
root@host> configure Entering configuration mode [edit] root@host#
2. Enable FIPS mode on the device by setting the FIPS level to 1, and verify the level:
[edit] root@host# set system fips level 1
[edit] root@host#show system fips {
level 1; }
3. Commit the configuration:

27

NOTE: If the device terminal displays error messages about the presence of critical security parameters (CSPs), delete those CSPs, and then commit the configuration.

root@host# commit configuration check succeeds [edit] ‘system’ reboot is required to transition to FIPS level 1
commit complete
4. Reboot the device:
[edit] root@host# run request system reboot Reboot the system ? [yes,no] (no) yes
During the reboot, the device runs Known Answer Tests (KATS). It returns a login prompt:
NOTE: The new hash algorithm affect only those passwords that are generated after commit.

@ 1556787428 mgd start Creating initial configuration: … mgd: Running FIPS Self-tests mgd: Testing kernel KATS: mgd: NIST 800-90 HMAC DRBG Known Answer Test: mgd: DES3-CBC Known Answer Test: mgd: HMAC-SHA1 Known Answer Test: mgd: HMAC-SHA2-256 Known Answer Test: mgd: SHA-2-384 Known Answer Test: mgd: SHA-2-512 Known Answer Test: mgd: AES128-CMAC Known Answer Test: mgd: AES-CBC Known Answer Test: mgd: Testing MACSec KATS: mgd: AES128-CMAC Known Answer Test: mgd: AES256-CMAC Known Answer Test: mgd: AES-ECB Known Answer Test: mgd: AES-KEYWRAP Known Answer Test:

Passed Passed Passed Passed Passed Passed Passed Passed
Passed Passed Passed Passed

28

mgd: KBKDF Known Answer Test: mgd: Testing libmd KATS: mgd: HMAC-SHA1 Known Answer Test: mgd: HMAC-SHA2-256 Known Answer Test: mgd: SHA-2-512 Known Answer Test: mgd: Testing OpenSSL v1.0.2 KATS: mgd: NIST 800-90 HMAC DRBG Known Answer Test: mgd: FIPS ECDSA Known Answer Test: mgd: FIPS ECDH Known Answer Test: mgd: FIPS RSA Known Answer Test: mgd: DES3-CBC Known Answer Test: mgd: HMAC-SHA1 Known Answer Test: mgd: HMAC-SHA2-224 Known Answer Test: mgd: HMAC- SHA2-256 Known Answer Test: mgd: HMAC-SHA2-384 Known Answer Test: mgd: HMAC- SHA2-512 Known Answer Test: mgd: AES-CBC Known Answer Test: mgd: AES-GCM Known Answer Test: mgd: ECDSA-SIGN Known Answer Test: mgd: KDF-IKE-V1 Known Answer Test: mgd: KDF-SSH-SHA256 Known Answer Test: mgd: KAS-ECC-EPHEM-UNIFIED-NOKC Known Answer Test: mgd: KAS-FFC-EPHEM-NOKC Known Answer Test: mgd: Testing OpenSSL KATS: mgd: NIST 800-90 HMAC DRBG Known Answer Test: mgd: FIPS ECDSA Known Answer Test: mgd: FIPS ECDH Known Answer Test: mgd: FIPS RSA Known Answer Test: mgd: DES3-CBC Known Answer Test: mgd: HMAC-SHA1 Known Answer Test: mgd: HMAC-SHA2-224 Known Answer Test: mgd: HMAC-SHA2-256 Known Answer Test: mgd: HMAC-SHA2-384 Known Answer Test: mgd: HMAC-SHA2-512 Known Answer Test: mgd: AES-CBC Known Answer Test: mgd: AES-GCM Known Answer Test: mgd: ECDSA-SIGN Known Answer Test: mgd: KDF-IKE-V1 Known Answer Test: mgd: KDF-SSH- SHA256 Known Answer Test: mgd: KAS-ECC-EPHEM-UNIFIED-NOKC Known Answer Test: mgd: KAS-FFC-EPHEM-NOKC Known Answer Test: mgd: Testing QuickSec 7.0 KATS: mgd: NIST 800-90 HMAC DRBG Known Answer Test:

Passed
Passed Passed Passed
Passed Passed Passed Passed Passed Passed Passed Passed Passed Passed Passed Passed Passed Passed Passed Passed Passed
Passed Passed Passed Passed Passed Passed Passed Passed Passed Passed Passed Passed Passed Passed Passed Passed Passed
Passed

29

mgd: DES3-CBC Known Answer Test: mgd: HMAC-SHA1 Known Answer Test: mgd: HMAC- SHA2-224 Known Answer Test: mgd: HMAC-SHA2-256 Known Answer Test: mgd: HMAC- SHA2-384 Known Answer Test: mgd: HMAC-SHA2-512 Known Answer Test: mgd: AES-CBC Known Answer Test: mgd: AES-GCM Known Answer Test: mgd: SSH-RSA-ENC Known Answer Test: mgd: SSH-RSA-SIGN Known Answer Test: mgd: SSH-ECDSA-SIGN Known Answer Test: mgd: KDF-IKE-V1 Known Answer Test: mgd: KDF-IKE-V2 Known Answer Test: mgd: Testing QuickSec KATS: mgd: NIST 800-90 HMAC DRBG Known Answer Test: mgd: DES3-CBC Known Answer Test: mgd: HMAC-SHA1 Known Answer Test: mgd: HMAC-SHA2-224 Known Answer Test: mgd: HMAC-SHA2-256 Known Answer Test: mgd: HMAC-SHA2-384 Known Answer Test: mgd: HMAC-SHA2-512 Known Answer Test: mgd: AES-CBC Known Answer Test: mgd: AES-GCM Known Answer Test: mgd: SSH-RSA-ENC Known Answer Test: mgd: SSH-RSA-SIGN Known Answer Test: mgd: KDF-IKE-V1 Known Answer Test: mgd: KDF-IKE-V2 Known Answer Test: mgd: Testing SSH IPsec KATS: mgd: NIST 800-90 HMAC DRBG Known Answer Test: mgd: DES3-CBC Known Answer Test: mgd: HMAC-SHA1 Known Answer Test: mgd: HMAC-SHA2-256 Known Answer Test: mgd: AES-CBC Known Answer Test: mgd: SSH-RSA-ENC Known Answer Test: mgd: SSH-RSA- SIGN Known Answer Test: mgd: KDF-IKE-V1 Known Answer Test: mgd: Testing file integrity: mgd: File integrity Known Answer Test: mgd: Testing crypto integrity: mgd: Crypto integrity Known Answer Test:

Passed Passed Passed Passed Passed Passed Passed Passed Passed Passed Passed Passed Passed
Passed Passed Passed Passed Passed Passed Passed Passed Passed Passed Passed Passed Passed
Passed Passed Passed Passed Passed Passed Passed Passed
Passed
Passed

30
Log in to the device. The CLI displays a banner that is followed by a prompt that includes “:fips”:
— JUNOS 22.3R1-20190716 built 2019-12-29 04:12:22 UTC root@host:fips> 5. Reboot the device again to restore the HMAC-DRBG as an active random adapter:
[edit] root@host# run request system reboot Reboot the system ? [yes,no] (no) yes During the reboot, the device runs Known Answer Tests (KATS) as shown in the step 4. It returns a login prompt:
— JUNOS 22.3R1-20190716 built 2019-12-29 04:12:22 UTC root@host:fips> 6. After the reboot has completed, log in and use the show version local command to verify.
NOTE: Use “local” keyword for operational commands in FIPS mode. For example, show version local, and show system uptime local.
Configuring Security Administrator and FIPS User Identification and Access
IN THIS SECTION Configuring Security Administrator Login Access | 31 Configuring FIPS User Login Access | 32

31
Security Administrator and FIPS users perform all configuration tasks for Junos OS in FIPS mode and issue all Junos OS in FIPS mode statements and commands. Security Administrator and FIPS user configurations must follow Junos OS in FIPS mode guidelines.
Configuring Security Administrator Login Access
Junos OS in FIPS mode offers a finer granularity of user permissions than those mandated by FIPS 140-3.
For FIPS 140-3 compliance, any FIPS user with the secret, security, maintenance, and control permission bits set is a Security Administrator. In most cases the super-user class suffices for the Security Administrator.
To configure login access for a Security Administrator:
1. Log in to the device with the root password if you have not already done so, and enter configuration mode:
root@host:fips> configure Entering configuration mode [edit] root@host:fips#
2. Name the user “security-administrator” and assign the Security Administrator a user ID (for example, 6400) and a class (for example, super- user). When you assign the class, you assign the permissions– for example, secret, security, maintenance, and control.
[edit] root@host:fips# set system login user crypto-officer uid 6400 class super-user
3. Following the guidelines in “Understanding Password Specifications and Guidelines for Junos OS in FIPS Mode” on page 19, assign the Security Administrator a plain-text password for login authentication. Set the password by typing a password after the prompts New password and Retype new password.
[edit] root@host:fips# set system login user crypto-officer class super-user authentication plaintext-password

32
4. Optionally, display the configuration:
[edit] root@host:fips# edit system [edit system] root@host:fips# show login {
user crypto-officer { uid 6400; authentication { encrypted-password “<cipher- text>”; ## SECRET-DATA } class super-user;
} }
5. If you are finished configuring the device, commit the configuration and exit:
[edit] root@host:fips# commit commit completeroot@host:fips# exit root@host:fips> exit
Otherwise, go on to “Configuring FIPS User Login Access” on page 32.
Configuring FIPS User Login Access
A fips-user is defined as any FIPS user that does not have the secret, security, maintenance, and control permission bits set. As the Security Administrator, you set up FIPS users.
To configure login access for a FIPS user:
1. Log in to the device with your Security Administrator password if you have not already done so, and enter configuration mode:
crypto-officer@host:fips> configure Entering configuration mode

33
[edit] crypto-officer@host:fips#
2. Give the user a username, assign the FIPS user a user ID (for example, 6401) and a class (for example , read-only). When you assign the class, you assign the permissions–for example, clear, configure, network, resetview, and view-configuration.
[edit] crypto-officer@host:fips# set system login user fips-user1 uid 6401 class read-only
3. Following the guidelines in “Understanding Password Specifications and Guidelines for Junos OS in FIPS Mode” on page 19, assign the FIPS a plain-text password for login authentication. Set the password by typing a password after the prompts New password and Retype new password.
[edit] crypto-officer@host:fips# set system login user fips-user1 class operator authentication plain-text-password
4. Optionally, display the configuration:
[edit] crypto-officer@host:fips# edit system [edit system] crypto- officer@host:fips# show login {
user fips-user1 { uid 6401; authentication { encrypted-password “<cipher- text>”; ## SECRET-DATA } read-only;
} }
5. If you are finished configuring the device, commit the configuration and exit:
[edit] crypto-officer@host:fips# commit crypto-officer@host:fips> exit

34
RELATED DOCUMENTATION Understanding Roles and Services for Junos OS in Common Criteria and FIPS | 13

3 CHAPTER
Configuring Administrative Credentials and Privileges
Understanding the Associated Password Rules for an Authorized Administrator | 36
Authentication Methods in FIPS Mode of Operation | 38 Configuring a Network Device collaborative Protection Profile for an Authorized Administrator | 39 Customize Time | 41 Configuring Inactivity Timeout Period Configuration, and Local and Remote Idle Session Termination | 41

36
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. · 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 ] security-administrator@host# set system login password change-type character-sets
· 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 3.
[ edit ] security-administrator@host# set system login password minimum- changes 3

37
· Contain the minimum number of characters required for a password. By default, Junos OS passwords must be at least 6 characters long. The valid range for this option is 10 to 20 characters.
[ edit ] security-administrator@host:fips# set system login password minimum- length 10
NOTE: The device supports ECDSA (P-256, P-384, and P-521) and RSA (2048, 3072, and 4092 modulus bit length) key-types. [ 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.
NOTE: Passwords should be changed periodically.
RELATED DOCUMENTATION Identifying Secure Product Delivery | 9

38
Authentication Methods in FIPS Mode of Operation
IN THIS SECTION Username and Password Authentication over the Console and SSH | 38 Username and Public Key Authentication over SSH | 39
The Juniper Networks Junos operating system (Junos OS) running in FIPS mode of operation allows a wide range of capabilities for users, and authentication is identity-based. The following types of identity-based authentication are supported in the FIPS mode of operation:
Username and Password Authentication over the Console and SSH
In this authentication method, the user is requested to enter the username and password after logging in to the TOE. The device enforces the user to enter a minimum of 10-characters password that is chosen from the 96 human-readable ASCII characters.
NOTE: The maximum password length is 20 characters.
In this method, the device enforces a timed access mechanism–for example, first two failed attempts to enter the correct password (assuming 0 time to process), no timed access is enforced. When the user enters the password for the third time, the module enforces a 5-second delay. Each failed attempt thereafter results in an additional 5-second delay above the previous failed attempt. For example, if the fourth failed attempt is a 10-second delay, then the fifth failed attempt is a 15-second delay, the sixth failed attempt is a 20-second delay, and the seventh failed attempt is a 25-second delay. Therefore, this leads to a maximum of seven possible attempts in a 1-minute period for each getty active terminal. So, the best approach for the attacker would be to disconnect after 4 failed attempts, and wait for a new getty to be spawned. This would allow the attacker to perform roughly 9.6 attempts per minute (576 attempts per hour or 60 minutes). This would be rounded off to 9 attempts per minute, because there is no such thing as 0.6 attempts. Thus the probability of a successful random attempt is 1/9610, which is less than 1/1 million. The probability of a success with multiple consecutive attempts in a 1-minute period is 9/(9610), which is less than 1/100,000.

39
Username and Public Key Authentication over SSH
With SSH public-key authentication, the user provides the username and proves ownership of the private key corresponding to the public key stored on the server. The device supports ECDSA (P-256, P-384, and P-521) and RSA (2048-bit or higher since our RSA implementation is FIPS 186-4 compliant). The probability of a success with multiple consecutive attempts in a 1-minute period is 5.6e7/(2128).
RELATED DOCUMENTATION Configuring SSH on the Evaluated Configuration | 47
Configuring a Network Device collaborative Protection Profile for an 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 NDcPP Version 2.2e 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. Configure the hashing algorithm used for password storage as sha512.
root@host# set system login password format sha512
NOTE: For your security devices, the default password algorithm is sha512, and it is not necessary to configure the plain-text passwords for EX4650 switches and QFX5120 switches.

40
3. Commit the changes.
[edit] root@host# commit
4. Define your NDcPP Version 2.2e authorized administrator.
[edit] root@host#set system login user user-name class security-admin authentication encryptedpassword
5. Load an SSH key file that was previously generated using ssh-keygen. This command loads RSA (SSH version 2), or ECDSA (SSH version 2).
[edit] root@host# set system root-authentication load-key-file url:filename
6. Set the log-key-changes configuration statement to log when SSH authentication keys are added or removed.
[edit] root@host#set system services ssh log-key-changes
NOTE: When the log-key-changes configuration statement is enabled and committed (with the commit command in configuration mode), Junos OS logs the changes to the set of authorized SSH keys for each user (including the keys that were added or removed). Junos OS logs the differences since the last time the log-key-changes configuration statement was enabled. If the log-key- changes configuration statement was never enabled, then Junos OS logs all the authorized SSH keys.
7. Commit the changes.
[edit] root@host# commit

41
RELATED DOCUMENTATION Understanding the Associated Password Rules for an Authorized Administrator | 36
Customize Time
To customize time, disable NTP and set the date. 1. Disable NTP.
[edit] security-administrator@hostname:fips# deactivate groups global system ntp security-administrator@hostname:fips# deactivate system ntp security- administrator@hostname:fips# commit security-administrator@hostname:fips# exit 2. Setting date and time. Date and time format is YYYYMMDDHHMM.ss.
security-administrator@hostname:fips> set date 201803202034.00 security- administrator@hostname:fips> set cli timestamp
Configuring Inactivity Timeout Period Configuration, and Local and Remote Idle Session Termination
IN THIS SECTION Configure Session Termination | 42 Sample Output for Local Administrative Session Termination | 43 Sample Output for Remote Administrative Session Termination | 43 Sample Output for User Initiated Termination | 44

42
Configure Session Termination
Terminate the session after the security administrator specifies inactive timeout period. 1. Set the idle timeout.
[edit] security-administrator@host:fips# set system login class security-admin idle-timeout 2 2. Configure the login access privileges.
[edit] security-administrator@host:fips# set system login class security-admin permissions all 3. Commit the configuration.
[edit] security-administrator@host:fips# commit
commit complete 4. Set the password.
[edit] security-administrator@host:fips# set system login user NDcPPv2-user authentication plaintext-password New password: Retype new password: 5. Define login class.
[edit] security-administrator@host:fips# set system login user NDcPPv2-user class security-admin

43
6. Commit the configuration.
[edit] security-administrator@host:fips# commit
commit complete
Sample Output for Local Administrative Session Termination
con host Trying a.b.c.d… ‘autologin’: unknown argument (‘set ?’ for help). Connected to device.example.com Escape character is ‘^]’. Type the hot key to suspend the connection: Z FreeBSD/amd64 (host) (ttyu0) login: NDcPPv2-user Password: Last login: Sun Jun 23 22:42:27 from 10.224.33.70 — JUNOS 22.3R1 Kernel 64-bit JNPR-12.1-20220628.HEAD__ci_fbs NDcPPv2-user@host> Warning: session will be closed in 1 minute if there is no activity Warning: session will be closed in 10 seconds if there is no activity Idle timeout exceeded: closing session FreeBSD/amd64 (host) (ttyu0)
Sample Output for Remote Administrative Session Termination
ssh NDcPPv2-user@host Password: Last login: Sun Jun 23 22:48:05 2019 — JUNOS 22.3R1 Kernel 64-bit JNPR-12.1-20220628.HEAD__ci_fbs

44
NDcPPv2-user@host> exit
Connection to host closed. ssh NDcPPv2-user@host Password: Last login: Sun Jun 23 22:50:50 2019 from 10.224.33.70 — JUNOS 22.3R1 Kernel 64-bit JNPR-12.1-20220628.HEAD__ci_fbs NDcPPv2-user@host> Warning: session will be closed in 1 minute if there is no activity Warning: session will be closed in 10 seconds if there is no activity Idle timeout exceeded: closing session
Connection to host closed.
Sample Output for User Initiated Termination
ssh NDcPPv2-user@host Password: Last login: Sun Jun 23 22:48:05 2019 — JUNOS 22.3R1 Kernel 64-bit JNPR-12.1-20220628.HEAD__ci_fbs NDcPPv2-user@host> exit
Connection to host closed.

4 CHAPTER
Configuring SSH and Console Connection
Configuring a System Login Message and Announcement | 46 Configuring SSH on the Evaluated Configuration | 47 Limiting the Number of User Login Attempts for SSH Sessions | 49

46
Configuring a System Login Message and Announcement
A login message appears before the user logs in and an announcement appears after the user logs in. By default, no login message or announcement is displayed on the device. To configure a system login message through console or management interface, use the following command:
[edit] user@host# set system login message login-message-banner-text To configure system announcement, use the following command:
[edit] user@host# set system login announcement system-announcement-text
NOTE: · If the message text contains any spaces, enclose it in quotation marks. · You can format the message using the following special characters:
· n–New line · t–Horizontal tab · ‘–Single quotation mark · “–Double quotation mark · \–Backslash
RELATED DOCUMENTATION Configuring SSH on the Evaluated Configuration | 47

47
Configuring SSH on the Evaluated Configuration
SSH is an allowed remote management interface in the evaluated configuration. This topic describes how to configure SSH on the device.
· Before you begin, log in with your root account on the device.
To configure SSH on the device:
1. Specify the permissible SSH host-key algorithms for the system services.
[edit ] root@host# set system services ssh hostkey-algorithm ssh-ecdsa root@host# set system services ssh hostkey-algorithm no-ssh-dss root@host# set system services ssh hostkey-algorithm ssh-rsa root@host# set system services ssh hostkey-algorithm no-ssh-ed25519
2. Specify the SSH key-exchange for Diffie-Hellman keys for the system services.
[edit ] root@host# set system services ssh key-exchange dh-group14-sha1 root@host# set system services ssh key-exchange ecdh-sha2-nistp256 root@host# set system services ssh key-exchange ecdh-sha2-nistp384 root@host# set system services ssh key-exchange ecdh-sha2-nistp521
3. Specify all the permissible message authentication code algorithms for SSHv2.
[edit ] root@host# set system services ssh macs hmac-sha1 root@host# set system services ssh macs hmac-sha2-256 root@host# set system services ssh macs hmac-sha2-512
4. Specify the ciphers allowed for protocol version 2.
[edit ] root@host# set system services ssh ciphers aes128-cbc root@host# set system services ssh ciphers aes256-cbc root@host# set system services ssh ciphers aes128-ctr root@host# set system services ssh ciphers aes256-ctr

48

NOTE: To disable SSH service, you can deactivate SSH configurations: root@host# deactivate system services ssh

NOTE: To disable Netconf service, you can deactivate netconf configurations: root@host# deactivate system services netconf ssh

Supported SSH hostkey algorithm:

ssh-ecdsa ssh-rsa

Allow generation of ECDSA host-key Allow generation of RSA host-key

Supported SSH key-exchange algorithm:

dh-group14-sha1 ecdh-sha2-nistp256 ecdh-sha2-nistp384 ecdh-sha2-nistp521

The RFC 4253 mandated group14 with SHA1 hash The EC Diffie-Hellman on nistp256 with SHA2-256 The EC Diffie-Hellman on nistp384 with SHA2-384 The EC Diffie- Hellman on nistp521 with SHA2-512

Supported MAC algorithm:

hmac-sha1 hmac-sha2-256 hmac-sha2-512

Hash-based MAC using Secure Hash Algorithm (SHA1) Hash-based MAC using Secure Hash Algorithm (SHA2) Hash-based MAC using Secure Hash Algorithm (SHA2)

Supported SSH ciphers algorithm:

aes128-cbc aes128-ctr
aes256-cbc aes256-ctr

128-bit AES with Cipher Block Chaining 128-bit AES with Counter Mode
256-bit AES with Cipher Block Chaining 256-bit AES with Counter Mode

49
RELATED DOCUMENTATION Limiting the Number of User Login Attempts for SSH Sessions | 49
Limiting the Number of User Login Attempts for SSH Sessions
An administrator may login remotely to a device through SSH. Administrator credentials are stored locally on the device. If the administrator presents a valid username and password, access to the Target of Evaluation (TOE) is granted. If the credentials are invalid, the TOE allows the authentication to be retried after an interval that starts after 1 second and increases exponentially. If the number of authentication attempts exceed the configured maximum, no authentication attempts are accepted for a configured time interval. When the interval expires, authentication attempts are again accepted.
You configure the amount of time the device gets locked after failed attempts. The amount of time in minutes before the user can attempt to log in to the device after being locked out due to the number of failed login attempts specified in the tries-before-disconnect statement. When a user fails to correctly login after the number of allowed attempts specified by the tries- before-disconnect statement, the user must wait the configured amount of minutes before attempting to log in to the device again. During this lockout- period the remote session user still have access to the TOE through the console as the root user. The lockout-period must be greater than zero. The range at which you can configure the lockout-period is one through 43,200 minutes.
[edit system login] user@host# set retry-options lockout-period number
You can configure the device to limit the number of attempts to enter a password while logging through SSH. Using the following command, the connection.
[edit system login] user@host# set retry-options tries-before-disconnect number
Here, tries-before-disconnect is the number of times a user can attempt to enter a password when logging in. The connection closes if a user fails to log in after the number specified. The range is from 2 through 10, and the default value is 3.

50
The local administrator access will be maintained even if the remote administration is made permanently or temporarily unavailable due to the multiple failed login attempts. The console login for local administration will be available to the users during the lockout period.
You can also configure a delay, in seconds, before a user can try to enter a password after a failed attempt.
[edit system login] user@host# set retry-options backoff-threshold number
Here, backoff-threshold is the threshold for the number of failed login attempts before the user experiences a delay in being able to enter a password again. The range is from 1 through 3, and the default value is 2 seconds.
In addition, the device can be configured to specify the threshold for the number of failed attempts before the user experiences a delay in entering the password again.
[edit system login] user@host# set retry-options backoff-factor number
Here, backoff-factor is the length of time, in seconds, before a user can attempt to log in after a failed attempt. The delay increases by the value specified for each subsequent attempt after the threshold. The range is from 5 through 10, and the default value is 5 seconds. You can control user access through SSH. By configuring ssh root-login deny , you can ensure the root account remains active and continues to have local administrative privileges to the TOE even if other remote users are logged off.
[edit system] user@host# set services ssh root-login deny
The SSH2 protocol provides secure terminal sessions utilizing the secure encryption. The SSH2 protocol enforces running the key-exchange phase and changing the encryption and integrity keys for the session. Key exchange is done periodically, after specified seconds or after specified bytes of data have passed over the connection. You can configure thresholds for SSH rekeying, FCS_SSHS_EXT.1.8 and FCS_SSHC_EXT.1.8. The TSF ensures that within the SSH connections the same session keys are used

51
for a threshold of no longer than one hour, and no more than one gigabyte of the transmitted data. When either of the thresholds are reached, a rekey must be performed.
[edit system] security-administrator@host:fips# set services ssh rekey time- limit number Time limit before renegotiating session keys is 1 through 1440 minutes.
[edit system] security-administrator@host:fips# set services ssh rekey data- limit number Data limit before renegotiating session keys is 51200 through 4294967295 byte.
NOTE: For SSH connection being unintentionally broken, we need to re-initiate the SSH connection to log in back to TOE.
RELATED DOCUMENTATION Configuring SSH on the Evaluated Configuration | 47

5 CHAPTER
Configuring the Remote Syslog Server
Syslog Server Configuration on a Linux System | 53

References

Read User Manual Online (PDF format)

Read User Manual Online (PDF format)  >>

Download This Manual (PDF format)

Download this manual  >>

Related Manuals