Juniper EX4400 Common Criteria Evaluated Configuration User Guide
- August 21, 2024
- JUNIPer
Table of Contents
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:
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
- per.net
- Preparing for Software Installation and Upgrade (Junos OS) | Junos OS | Juniper Networks
- IEEE SA - IEEE 802.1AE-2018
- Downloads
- User Registration
- commoncriteriaportal.org/
- Understanding Media Access Control Security (MACsec) | Junos OS | Juniper Networks
- Junos OS Documentation | Juniper Networks
- Customer and Partner Stories - Network Performance Solutions and Networking Security - Juniper Networks
- NIAP
- NIAP
Read User Manual Online (PDF format)
Read User Manual Online (PDF format) >>