Security Target for Junos OS 22.2R1 for MX Series with MX-SPC3 Juniper Networks, Inc.
Version 1.1 Page 1 of 67
Security Target for Junos OS 22.2R1 for MX Series with MX-
SPC3
Juniper Networks, Inc.
Version 1.1
May 21, 2024
Prepared for:
Juniper Networks, Inc.
1133 Innovation Way
Sunnyvale, CA 94089
www.juniper.net
Security Target for Junos OS 22.2R1 for MX Series with MX-SPC3 Juniper Networks, Inc.
Version 1.1 Page 2 of 67
Abstract
This document provides the basis for an evaluation of a specific Target of Evaluation (TOE), Junos OS
22.2R1 for MX Series with MX-SPC3. This Security Target (ST) is conformant to the Collaborative
Protection Profile for Network Devices [CPP_ND] and PP-Module for VPN Gateways [MOD_VPNGW].
References
[CC1] Common Criteria for Information Technology Security Evaluation, Part 1: Introduction and
General Model, CCMB-2017-04-001, Version 3.1 Revision 5, April 2017
[CC2] Common Criteria for Information Technology Security Evaluation, Part 2: Security Functional
Components, CCMB-2017-04-002, Version 3.1 Revision 5, April 2017
[CC3] Common Criteria for Information Technology Security Evaluation, Part 3: Security Assurance
Components, CCMB-2017-04-003, Version 3.1 Revision 5, April 2017
[CC_Add] CC and CEM Addenda, Exact Conformance, Selection-Based SFRs, Optional SFRs,
CCDB-2021-09-30, Version 2.0, Sep 2021
[ENT] Seeding of the Kernel RBG, Junos OS 22.2R1, In MX240 Platform Running Junos 22.2R1.9,
Version 1.1, 20 July 2022
[CPP_ND] Collaborative Protection Profile for Network Devices, Version 2.2e 23-March-2020
[PP_CONF] PP-Configuration for Network Device and Virtual Private Network (VPN) Gateways,
Version 1.1, 1 July 2020
[MOD_VPNGW] PP-Module for Virtual Private Network (VPN) Gateways, Version: 1.1, 18 June 2020
Product Guide References
[ECG] Common Criteria Configuration Guide for MX240, MX480, and MX960 Devices, Release
22.2R1, 30 March 2023
Security Target for Junos OS 22.2R1 for MX Series with MX-SPC3 Juniper Networks, Inc.
Version 1.1 Page 3 of 67
Table of Contents
1 Introduction ....................................................................................................................................6
1.1 ST reference............................................................................................................................6
1.2 TOE Reference.........................................................................................................................6
1.3 About this document ..............................................................................................................6
1.4 Document Conventions ..........................................................................................................6
1.5 TOE Overview..........................................................................................................................7
1.6 TOE Description.......................................................................................................................7
1.6.1 Overview .........................................................................................................................7
1.6.2 Physical boundary...........................................................................................................8
1.6.3 Logical Boundary.............................................................................................................9
1.6.4 Non-TOE hardware/software/firmware .......................................................................10
1.6.5 Summary of out scope items ........................................................................................10
2 Conformance Claim.......................................................................................................................11
2.1 CC Conformance Claim .........................................................................................................11
2.2 PP Conformance claim..........................................................................................................11
2.3 Technical Decisions...............................................................................................................11
2.2.1 Technical Decisions applicable to [CPP_ND].................................................................11
2.2.2 Technical decisions applicable to [MOD_VPNGW].......................................................12
2.2.3 Other technical decisions..............................................................................................12
3 Security Problem Definition..........................................................................................................13
3.1 Threats ..................................................................................................................................13
3.2 Assumptions..........................................................................................................................16
3.3 Organizational Security Policies............................................................................................17
4 Security Objectives........................................................................................................................18
4.1 Security Objectives for the TOE ............................................................................................18
4.2 Security Objectives for the Operational Environment..........................................................19
4.3 Security Objectives rationale ................................................................................................20
5 Security Functional Requirements................................................................................................21
5.1 Security Audit (FAU)..............................................................................................................21
5.1.1 Security Audit Data generation (FAU_GEN)..................................................................21
5.1.2 Security audit event storage (Extended – FAU_STG_EXT)............................................24
5.2 Cryptographic Support (FCS).................................................................................................24
5.2.1 Cryptographic Key Management (FCS_CKM)................................................................24
5.2.2 Cryptographic Operation (FCS_COP) ............................................................................26
5.2.3 Random Bit Generation (Extended – FCS_RBG_EXT)....................................................26
5.2.4 Cryptographic Protocols (Extended – FCS_ IPSEC_EXT & FCS_SSHS_EXT SSH Protocol27
Security Target for Junos OS 22.2R1 for MX Series with MX-SPC3 Juniper Networks, Inc.
Version 1.1 Page 4 of 67
5.3 Identification and Authentication (FIA) ................................................................................29
5.3.1 Authentication Failure Management (FIA_AFL) ...........................................................29
5.3.2 Password Management (Extended – FIA_PMG_EXT)...................................................29
5.3.3 User Identification and Authentication (Extended – FIA_UIA_EXT) .............................29
5.3.4 User authentication (FIA_UAU) (Extended – FIA_UAU_EXT)........................................30
5.3.5 Authentication using X.509 certificates (Extended – FIA_X509_EXT)...........................30
5.4 Security Management (FMT) ................................................................................................31
5.4.1 Management of functions in TSF (FMT_MOF)..............................................................31
5.4.2 Management of TSF Data (FMT_MTD) .........................................................................32
5.4.3 Specification of Management Functions (FMT_SMF)...................................................32
5.4.4 Security management roles (FMT_SMR) ......................................................................33
5.5 Protection of the TSF (FPT) ...................................................................................................33
5.5.1 Protection of TSF Data (Extended – FPT_SKP_EXT) ......................................................33
5.5.2 Protection of Administrator Passwords (Extended – FPT_APW_EXT)..........................33
5.5.3 TSF testing (Extended – FPT_TST_EXT).........................................................................34
5.5.4 Trusted Update (FPT_TUD_EXT) ...................................................................................34
5.5.5 Time stamps (Extended – FPT_STM_EXT)) ...................................................................34
5.5.6 Self-test Failures (FPT_FLS) ...........................................................................................35
5.6 TOE Access (FTA)...................................................................................................................35
5.6.1 TSF-initiated Session Locking (Extended – FTA_SSL_EXT) ............................................35
5.6.2 Session locking and termination (FTA_SSL) ..................................................................35
5.6.3 TOE access banners (FTA_TAB).....................................................................................35
5.7 Trusted path/channels (FTP).................................................................................................35
5.7.1 Trusted Channel (FTP_ITC)............................................................................................35
5.7.2 Trusted Path (FTP_TRP).................................................................................................36
5.8 Packet Filtering (FPF) ............................................................................................................36
5.8.1 Packet Filtering Rules (FPF_RUL_EXT)...........................................................................36
6 Security Assurance Requirements ................................................................................................38
7 TOE Summary Specification..........................................................................................................39
7.1 Protected communications...................................................................................................39
7.1.1 Algorithms and zeroization...........................................................................................39
7.1.2 Random Bit Generation ................................................................................................43
7.1.3 SSH ................................................................................................................................43
7.1.4 IPsec ..............................................................................................................................46
7.2 Administrator Authentication...............................................................................................49
7.3 Correct Operation.................................................................................................................51
7.4 Trusted Update .....................................................................................................................51
7.5 Audit......................................................................................................................................52
Security Target for Junos OS 22.2R1 for MX Series with MX-SPC3 Juniper Networks, Inc.
Version 1.1 Page 5 of 67
7.6 Management.........................................................................................................................55
7.7 Packet Filtering......................................................................................................................60
8 Rationales......................................................................................................................................63
8.1 SFR dependency analysis ......................................................................................................63
9 Glossary.........................................................................................................................................66
Security Target for Junos OS 22.2R1 for MX Series with MX-SPC3 Juniper Networks, Inc.
Version 1.1 Page 6 of 67
1 Introduction
1. This section identifies the Security Target (ST), Target of Evaluation (TOE), Security Target
organization, document conventions, and terminology. It also includes an overview of the
evaluated products.
1.1 ST reference
ST Title Security Target for Junos OS 22.2R1 for MX Series with MX-SPC3
ST Revision 1.1
ST Date May 21, 2024
Author Juniper Networks, Inc.
cPP Conformance [CPP_ND], [MOD_VPNGW]
1.2 TOE Reference
TOE Title Junos OS 22.2R1 for MX Series with MX-SPC3
1.3 About this document
2. This Security Target follows the following format:
Section Title Description
1 Introduction Provides an overview of the TOE and defines the
hardware and firmware that make up the TOE as well as
the physical and logical boundaries of the TOE
2 Conformance Claims Lists evaluation conformance to Common Criteria
versions, Protection Profiles, or Packages where
applicable
3 Security Problem Definition Specifies the threats, assumptions and organizational
security policies that affect the TOE
4 Security Objectives Defines the security objectives for the TOE/operational
environment and provides a rationale to demonstrate
that the security objectives satisfy the threats
5 Security Functional Requirements Contains a statement of the functional requirements for
this TOE
6 Security Assurance Requirements Contains a statement of the assurance requirements for
this TOE
7 TOE Summary Specification Identifies the IT security functions provided by the TOE
and maps them to the applicable security functional
requirements
Table 1 Document Organization
1.4 Document Conventions
3. This document follows the same conventions as those applied in [CPP_ND] in the completion of
operations on Security Functional Requirements, namely:
• Unaltered SFRs are stated in the form used in [CC2] or their extended component definition
(ECD);
• Refinement made in the ST: the refinement text is indicated with bold text and
strikethroughs;
• Selection completed in the ST: the selection values are indicated with underlined text
4. e.g. “[selection: disclosure, modification, loss of use]” in [CC2] or an ECD might become
“disclosure” (completion;
Security Target for Junos OS 22.2R1 for MX Series with MX-SPC3 Juniper Networks, Inc.
Version 1.1 Page 7 of 67
• Assignment completed in the ST: indicated with italicized text;
• Assignment completed within a selection in the ST: the completed assignment text is
indicated with italicized and underlined text
5. e.g. “[selection: change_default, query, modify, delete, [assignment: other operations]]” in [CC2]
or an ECD might become “change_default, select_tag” (completion of both selection and
assignment);
• Iteration: indicated by adding a string starting with “/” (e.g. “FCS_COP.1/Hash”).
1.5 TOE Overview
6. The Target of Evaluation (TOE) is Juniper Networks, Inc. Junos OS 22.2R1 operating system on
MX series universal routing modular platforms MX240, MX480 and MX960 with the MX-SPC3
services card. The MX Series platforms deliver powerful routing, switching, security, and services
features.
7. The TOE ensures that security-relevant activity is audited and that the TOE functions are
protected from potential attacks. The TOE also implements IPsec for multi-site virtual private
network (VPN) gateway functionality and to tunnel remote administrate SSH connections The
TOE provides tools to manage all security functions.
1.6 TOE Description
1.6.1 Overview
8. The TOE is a security product that supports a variety of high-speed interfaces for medium/large
networks and network applications. Juniper Networks routers share common Junos OS
firmware, features, and technology for compatibility across platforms.
9. The TOE is physically self-contained. It houses all software, firmware and hardware to perform
all functions. The hardware consists of two major components: the router chassis and the
interface modules (also known as line cards) which allow it to communicate with the different
types of networks that may be required within the environment where the router will be used.
10. The architecture of each appliance cleanly separates routing and control functions from packet
forwarding operations, thereby eliminating bottlenecks and permitting the router to maintain a
high level of performance.
11. Each instance of the TOE consists of the following major architectural components:
• The Routing Engine (RE) runs the Junos firmware and provides Layer 3 routing services
and network management for all operations necessary for the configuration and
operation of the TOE. The RE also controls the flow of information through the TOE,
including Network Address Translation (NAT) and all operations necessary for the
encryption/decryption of packets for secure communication via the IPSec protocol.
• The Packet Forwarding Engine (PFE) provides all operations necessary for transit packet
forwarding.
12. The Routing Engine and Packet Forwarding Engine perform their primary tasks independently,
while constantly communicating through a high-speed internal link. This arrangement provides
streamlined forwarding and routing control and the capability to run Internet-scale networks at
high speeds.
13. The appliances support numerous routing standards for flexibility and scalability as well as IETF
SSHv2 and IPsec protocols. These functions can all be managed through the Junos firmware,
either from a connected terminal console or via a network connection. Network management
Security Target for Junos OS 22.2R1 for MX Series with MX-SPC3 Juniper Networks, Inc.
Version 1.1 Page 8 of 67
can be secured using IPsec and SSH protocols. All management, whether from a user connecting
to a terminal or from the network, requires successful authentication.
14. In the evaluated deployment the TOE is managed and configured via Command Line Interface,
either via a directly connected console or using SSH connections, which can be further protected
using IPsec if required.
1.6.2 Physical boundary
15. The physical boundary of the TOE architecture illustrated in Figure 1 is the entire chassis of the
TOE. It includes both the hardware and the firmware of the TOE. The TOE is the Junos OS 22.2R1
firmware running on the MX Series routers listed in Table 1. The line cards included in the
evaluated TOE are also listed in Table 1. The physical boundary of the TOE includes the firmware
implementing the KVM Hypervisor, the firmware implementing the Routing Engine and the
Packet Forwarding Engine. The TOE is contained within the physical boundary of the appliance
chassis.
16.
Figure 1 TOE Physical boundary
Chassis Switch control
board (SCB)
Routing
Engine (RE)
Services Processing
Card (SPC)
Modular Port
Concentrator (MPC)
MX240 SCBE3-MX RE-S-X6-64G
RE-S-X6-128G
MX-SPC3 MPC10E-10C
MPC10E-15C
MX480 SCBE3-MX RE-S-X6-64G
RE-S-X6-128G
MX-SPC3 MPC10E-10C
MPC10E-15C
MX960 SCBE3-MX RE-S-X6-64G
RE-S-X6-128G
MX-SPC3 MPC10E-10C
MPC10E-15C
Table 2 TOE configuration details
17. The line cards and modules supported for by the MX240, MX480 and MX960 routers are
described in the following reference documents:
• MX240 Universal Routing Platform Hardware Guide
• MX480 Universal Routing Platform Hardware Guide
• MX960 Universal Routing Platform Hardware Guide
18. The install packages for the TOE software are the following:
Security Target for Junos OS 22.2R1 for MX Series with MX-SPC3 Juniper Networks, Inc.
Version 1.1 Page 9 of 67
• junos-vmhost-install-mx-x86-64-22.2R1.9.tgz
19. The guidance document included as part of the TOE is [ECG].
1.6.3 Logical Boundary
20. The logical boundary of the TOE includes the following security functionality.
Security Functionality Description
Protected Communications The TOE implements an SSH server for protected communications
between itself and SSH clients. SSH is used by administrators to
establish secure sessions between management stations and the
TOE and to connect the TOE to external syslog servers.
The TOE also implements IPsec for multi-site virtual private
network (VPN) gateway functionality and to tunnel remote
administrate SSH connections. Each application connecting to the
TOE using SSH and IPsec must be successfully authenticated prior
to any information exchange.
Telnet, File Transfer Protocol (FTP) and Secure Socket Layer (SSL)
are out of scope.
The TOE includes cryptographic modules which implement the
underlying cryptographic services. The cryptographic services
include key management and protection of stored keys,
cryptographic algorithms, random bit generation, and crypto-
administration. The cryptographic modules provide confidentiality
and integrity services for authentication and for protecting
communications with adjacent systems.
Administrator
Authentication
Administrative users must be successfully authenticated using
unique identification and authentication data before any
administrative access to the system is granted. Authentication data
entered and stored on the TOE is protected. The TOE can be
configured to terminate interactive user sessions and to present an
access banner with warning messages prior to authentication.
Correct Operation The TOE provides for cryptographic and non-cryptographic self-
tests and is capable of automated recovery from failure states.
Trusted Update The administrator can initiate update of the TOE firmware. The
integrity of any firmware updates is verified prior to installation.
Audit Junos auditable events are stored in the syslog files on the
appliance and can be sent to an external log server via Netconf
over SSH. Auditable events include start-up and shutdown of the
audit functions, authentication events, service requests, and all the
events listed in Table 4. Audit records include the date and time,
event category, event type, username, and the outcome of the
event (success or failure). Local syslog storage limits are
configurable and are monitored. If the storage limits are reached
the oldest logs will be overwritten.
Security Target for Junos OS 22.2R1 for MX Series with MX-SPC3 Juniper Networks, Inc.
Version 1.1 Page 10 of 67
Security Functionality Description
Management The TOE provides a Security Administrator role that is authorized
and responsible for:
1. configuration and maintenance of cryptographic protocols
used in the establishment of secure connections to and
from the TOE,
2. regular reviews of all audit data,
3. initiation of trusted update function,
4. administration of VPN functionality, and
5. all administrative tasks.
The devices are managed through a Command Line Interface (CLI)
which is accessible through a local (serial) console connection or a
remote administrative (SSH) session.
Packet Filtering The TOE provides network traffic filtering based on examination of
network packets and the application of information flow rules to
each packet. Based on the rules, the TOE determines whether the
packet is forwarded or dropped.
Information Flow Control The TOE is designed to forward network packets (i.e. information
flows) from source network entities to destination network entities
based on available routing information. This information is either
provided directly by TOE users or indirectly from other network
entities (outside the TOE) configured by the TOE users. The TOE
has the capability to regulate the information flow across its
interfaces. Traffic filters can be set in accordance with the
presumed identity of the source, the identity of the destination,
the transport layer protocol, the source service identifier, and the
destination service identifier (TCP or UDP port number).
1.6.4 Non-TOE hardware/software/firmware
21. The TOE requires SFPs/PIMs to operate and communicate with the connected network. The TOE
also relies on the provision of the following items, none of which is part of the TOE, in the
network environment:
• Syslog server supporting SSHv2 connections to send audit logs;
• SSHv2 client for remote administration;
• Serial connection client for local administration;
• IPsec peer.
1.6.5 Summary of out scope items
• Use of telnet, since it violates the Trusted Path requirement set (see Section 5.7.2)
• Use of TOE-terminated and TOE-initiated FTP connections, since they violate the Trusted
Path requirement set (see Section 5.7.2)
• Use of SNMP, since it violates the Trusted Path requirement set (see Section 5.7.2)
• Use of SSL, including management via J-Web, JUNOScript and JUNOScope, since it violates
the Trusted Path requirement set (see Section 5.7.2)
• Use of CLI account super-user and junos root account.
Security Target for Junos OS 22.2R1 for MX Series with MX-SPC3 Juniper Networks, Inc.
Version 1.1 Page 11 of 67
2 Conformance Claim
2.1 CC Conformance Claim
22. This Security Target conforms to the requirements of Common Criteria v3.1, Revision 5 and is
Part 2 extended and Part 3 conformant.
2.2 PP Conformance claim
23. This Security Target claims conformance to:
• PP-Configuration for Network Device and Virtual Private Network (VPN) Gateways,
Version 1.1 [PP_CONF]
24. [PP_CONF] includes the following components:
• Base-PP: collaborative Protection Profile for Network Devices, Version 2.2e [CPP_ND]
• PP-Module: PP-Module for Virtual Private Network (VPN) Gateways, Version 1.1
[MOD_VPNGW]
2.3 Technical Decisions
25. In line with Labgram #105, this section identifies all NIAP Technical Decisions that are applicable
to this TOE.
2.2.1 Technical Decisions applicable to [CPP_ND]
TD Title Relevant to
ST
TD0800 Updated NIT Technical Decision for IPsec IKE/SA Lifetimes Tolerance Yes
TD0792 NIT Technical Decision: FIA_PMG_EXT.1 - TSS EA not in line with SFR Yes
TD0790 NIT Technical Decision: Clarification Required for testing IPv6 No
TD0738 NIT Technical Decision for Link to Allowed-With List Yes
TD0670 NIT Technical Decision for Mutual and Non-Mutual Auth TLSC Testing No
TD0639 NIT Technical Decision for Clarification for NTP MAC Keys No
TD0638 NIT Technical Decision for Key Pair Generation for Authentication Yes
TD0636 NIT Technical Decision for Clarification of Public Key User Authentication
for SSH
No
TD0635 NIT Technical Decision for TLS Server and Key Agreement Parameters No
TD0634 NIT Technical Decision for Clarification required for testing IPv6 No
TD0632 NIT Technical Decision for Consistency with Time Data for vNDs No
TD0631 NIT Technical Decision for Clarification of public key authentication for
SSH Server
Yes
TD0592 NIT Technical Decision for Local Storage of Audit Records Yes
TD0591 NIT Technical Decision for Virtual TOEs and hypervisors No
TD0581 NIT Technical Decision for Elliptic curve-based key establishment and
NIST SP 800-56Arev3
Yes
TD0580 NIT Technical Decision for clarification about use of DH14 in NDcPPv2.2e Yes
TD0572 NiT Technical Decision for Restricting FTP_ITC.1 to only IP address
identifiers
Yes
TD0571 NiT Technical Decision for Guidance on how to handle FIA_AFL.1 Yes
TD0570 NiT Technical Decision for Clarification about FIA_AFL.1 Yes
TD0569 NIT Technical Decision for Session ID Usage Conflict in
FCS_DTLSS_EXT.1.7
No
TD0564 NiT Technical Decision for Vulnerability Analysis Search Criteria Yes
Security Target for Junos OS 22.2R1 for MX Series with MX-SPC3 Juniper Networks, Inc.
Version 1.1 Page 12 of 67
TD Title Relevant to
ST
TD0563 NiT Technical Decision for Clarification of audit date information Yes
TD0556 NIT Technical Decision for RFC 5077 question No
TD0555 NIT Technical Decision for RFC Reference incorrect in TLSS Test No
TD0547 NIT Technical Decision for Clarification on developer disclosure of
AVA_VAN
Yes
TD0546 NIT Technical Decision for DTLS - clarification of Application Note 63 No
TD0538 NIT Technical Decision for Outdated link to allowed-with list. Yes
TD0537 NIT Technical Decision for Incorrect reference to FCS_TLSC_EXT.2.3 Yes
TD0536 NIT Technical Decision for Update Verification Inconsistency Yes
TD0528 NIT Technical Decision for Missing EAs for FCS_NTP_EXT.1.4 No
TD0527 Updates to Certificate Revocation Testing (FIA_X509_EXT.1) Yes
Table 3 Applicable NIAP Technical Decisions
2.2.2 Technical decisions applicable to [MOD_VPNGW]
TD Title Relevant to
ST
TD0633 NIT Technical Decision for Ipsec IKE/SA Lifetimes Tolerance Yes
TD0597 VPN GW IPv6 Protocol Support Yes
TD0590 Mapping of operational environment objectives Yes
TD0549 Consistency of Security Problem Definition update for
MOD_VPNGW_v1.0 and MOD_VPNGW_v1.1
Yes
2.2.3 Other technical decisions
26. All other NIAP Technical Decisions fall into one of the following categories and hence are not
applicable to this TOE:
• Relates to earlier version of PP/MOD claimed for this TOE. This TD has been superseded
by PP/MOD (and associated SD) released after this TD
• Relates to a PP/MOD that is not claimed for this TOE
Security Target for Junos OS 22.2R1 for MX Series with MX-SPC3 Juniper Networks, Inc.
Version 1.1 Page 13 of 67
3 Security Problem Definition
27. As this TOE is not distributed, none of the threats/assumptions/OSPs relating to distributed TOEs
are specified for this TOE.
3.1 Threats
28. The following threats for this TOE are as defined in [CPP_ND] Section 4.1, which also applies to
[MOD_VPNGW]. Namely:
• T.UNAUTHORIZED_ADMINISTRATOR_ACCESS
29. Threat agents may attempt to gain Administrator access to the network device by nefarious
means such as masquerading as an Administrator to the device, masquerading as the device to
an Administrator, replaying an administrative session (in its entirety, or selected portions), or
performing man-in-the-middle attacks, which would provide access to the administrative
session, or sessions between network devices. Successfully gaining Administrator access allows
malicious actions that compromise the security functionality of the device and the network on
which it resides.
• T.WEAK_CRYPTOGRAPHY
30. Threat agents may exploit weak cryptographic algorithms or perform a cryptographic exhaust
against the key space. Poorly chosen encryption algorithms, modes, and key sizes will allow
attackers to compromise the algorithms, or brute force exhaust the key space and give them
unauthorized access allowing them to read, manipulate and/or control the traffic with minimal
effort.
• T.UNTRUSTED_COMMUNICATION_CHANNELS
31. Threat agents may attempt to target network devices that do not use standardized secure
tunnelling protocols to protect the critical network traffic. Attackers may take advantage of
poorly designed protocols or poor key management to successfully perform man-in-the-middle
attacks, replay attacks, etc. Successful attacks will result in loss of confidentiality and integrity of
the critical network traffic, and potentially could lead to a compromise of the network device
itself.
• T.WEAK_AUTHENTICATION_ENDPOINTS
32. Threat agents may take advantage of secure protocols that use weak methods to authenticate
the endpoints – e.g. a shared password that is guessable or transported as plaintext. The
consequences are the same as a poorly designed protocol, the attacker could masquerade as the
Administrator or another device, and the attacker could insert themselves into the network
stream and perform a man-in-the-middle attack. The result is the critical network traffic is
exposed and there could be a loss of confidentiality and integrity, and potentially the network
device itself could be compromised.
• T.UPDATE_COMPROMISE
33. Threat agents may attempt to provide a compromised update of the software or firmware which
undermines the security functionality of the device. Non-validated updates or updates validated
using non-secure or weak cryptography leave the update firmware vulnerable to surreptitious
alteration.
• T.UNDETECTED_ACTIVITY
34. Threat agents may attempt to access, change, and/or modify the security functionality of the
network device without Administrator awareness. This could result in the attacker finding an
Security Target for Junos OS 22.2R1 for MX Series with MX-SPC3 Juniper Networks, Inc.
Version 1.1 Page 14 of 67
avenue (e.g., misconfiguration, flaw in the product) to compromise the device and the
Administrator would have no knowledge that the device has been compromised.
• T.SECURITY_FUNCTIONALITY_COMPROMISE
35. Threat agents may compromise credentials and device data enabling continued access to the
network device and its critical data. The compromise of credentials includes replacing existing
credentials with an attacker’s credentials, modifying existing credentials, or obtaining the
Administrator or device credentials for use by the attacker.
• T.PASSWORD_CRACKING
36. Threat agents may be able to take advantage of weak administrative passwords to gain
privileged access to the device. Having privileged access to the device provides the attacker
unfettered access to the network traffic and may allow them to take advantage of any trust
relationships with other network devices.
• T.SECURITY_FUNCTIONALITY_FAILURE
37. An external, unauthorized entity could make use of failed or compromised security functionality
and might therefore subsequently use or abuse security functions without prior authentication
to access, change or modify device data, critical network traffic or security functionality of the
device.
38. The following additional threats specified in [MOD_VPNGW] are also detailed for this TOE:
• T.NETWORK_DISCLOSURE1
39. Devices on a protected network may be exposed to threats presented by devices located outside
the protected network, which may attempt to conduct unauthorized activities. If known
malicious external devices are able to communicate with devices on the protected network, or if
devices on the protected network can establish communications with those external devices
(e.g., as a result of a phishing episode or by inadvertent responses to email messages), then
those internal devices may be susceptible to the unauthorized disclosure of information.
From an infiltration perspective, VPN gateways serve not only to limit access to only specific
destination network addresses and ports within a protected network, but whether network
traffic will be encrypted or transmitted in plaintext. With these limits, general network port
scanning can be prevented from reaching protected networks or machines, and access to
information on a protected network can be limited to that obtainable from specifically
configured ports on identified network nodes (e.g., web pages from a designated corporate web
server). Additionally, access can be limited to only specific source addresses and ports so that
specific networks or network nodes can be blocked from accessing a protected network thereby
further limiting the potential disclosure of information.
From an exfiltration perspective, VPN gateways serve to limit how network nodes operating on a
protected network can connect to and communicate with other networks limiting how and
where they can disseminate information. Specific external networks can be blocked altogether
or egress could be limited to specific addresses and/or ports. Alternately, egress options
available to network nodes on a protected network can be carefully managed in order to, for
example, ensure that outgoing connections are encrypted to further mitigate inappropriate
disclosure of data through packet sniffing.
• T.NETWORK_ACCESS2
1
Wording from [MOD_VPNGW]
2
Wording from [MOD_VPNGW]
Security Target for Junos OS 22.2R1 for MX Series with MX-SPC3 Juniper Networks, Inc.
Version 1.1 Page 15 of 67
40. Devices located outside the protected network may seek to exercise services located on the
protected network that are intended to only be accessed from inside the protected network or
only accessed by entities using an authenticated path into the protected network. Devices
located outside the protected network may, likewise, offer services that are inappropriate for
access from within the protected network.
From an ingress perspective, VPN gateways can be configured so that only those network
servers intended for external consumption by entities operating on a trusted network (e.g.,
machines operating on a network where the peer VPN gateways are supporting the connection)
are accessible and only via the intended ports. This serves to mitigate the potential for network
entities outside a protected network to access network servers or services intended only for
consumption or access inside a protected network.
From an egress perspective, VPN gateways can be configured so that only specific external
services (e.g., based on destination port) can be accessed from within a protected network, or
moreover are accessed via an encrypted channel. For example, access to external mail services
can be blocked to enforce corporate policies against accessing uncontrolled e-mail servers, or,
that access to the mail server must be done over an encrypted link.
• T.NETWORK_MISUSE3
41. Devices located outside the protected network, while permitted to access particular public
services offered inside the protected network, may attempt to conduct inappropriate activities
while communicating with those allowed public services. Certain services offered from within a
protected network may also represent a risk when accessed from outside the protected
network.
From an ingress perspective, it is generally assumed that entities operating on external networks
are not bound by the use policies for a given protected network. Nonetheless, VPN gateways can
log policy violations that might indicate violation of publicized usage statements for publicly
available services.
From an egress perspective, VPN gateways can be configured to help enforce and monitor
protected network use policies. As explained in the other threats, a VPN gateway can serve to
limit dissemination of data, access to external servers, and even disruption of services –all of
these could be related to the use policies of a protected network and as such are subject in some
regards to enforcement. Additionally, VPN gateways can be configured to log network usages
that cross between protected and external networks and as a result can serve to identify
potential usage policy violations
• T.DATA_INTEGRITY
42. Devices on a protected network may be exposed to threats presented by devices located outside
the protected network, which may attempt to modify the data without authorization. If known
malicious external devices are able to communicate with devices on the protected network or if
devices on the protected network can communicate with those external devices then the data
contained within the communications may be susceptible to a loss of integrity.
• T.REPLAY_ATTACK
43. If an unauthorized individual successfully gains access to the system, the adversary may have the
opportunity to conduct a “replay” attack. This method of attack allows the individual to capture
packets traversing throughout the network and send the packets at a later time, possibly
3
Wording from [MOD_VPNGW]
Security Target for Junos OS 22.2R1 for MX Series with MX-SPC3 Juniper Networks, Inc.
Version 1.1 Page 16 of 67
unknown by the intended receiver. Traffic is subject to replay if it meets the following
conditions:
o Cleartext: an attacker with the ability to view unencrypted traffic can identify an
appropriate segment of the communications to replay as well in order to cause the
desired outcome.
o No integrity: alongside cleartext traffic, an attacker can make arbitrary modifications
to captured traffic and replay it to cause the desired outcome if the recipient has no
means to detect these modifications.
44. No threats are identified for this TOE in addition to those specified in the collaborative
Protection Profile and PP-Modules that the ST claims conformance to.
3.2 Assumptions
45. The assumptions made for this TOE are as defined in [CPP_ND] Section 4.2, namely:
• A.PHYSICAL_PROTECTION
46. The network device is assumed to be physically protected in its operational environment and not
subject to physical attacks that compromise the security and/or interfere with the device’s
physical interconnections and correct operation. This protection is assumed to be sufficient to
protect the device and the data it contains. As a result, the cPP will not include any requirements
on physical tamper protection or other physical attack mitigations. The cPP will not expect the
product to defend against physical access to the device that allows unauthorized entities to
extract data, bypass other controls, or otherwise manipulate the device.
• A.LIMITED_FUNCTIONALITY
47. The device is assumed to provide networking functionality as its core function and not provide
functionality/services that could be deemed as general-purpose computing. For example, the
device should not provide a computing platform for general purpose applications (unrelated to
networking functionality).
• A.TRUSTED_ADMINSTRATOR
48. The Security Administrator(s) for the network device are assumed to be trusted and to act in the
best interest of security for the organization. This includes being appropriately trained, following
policy, and adhering to guidance documentation. Administrators are trusted to ensure
passwords/credentials have sufficient strength and entropy and to lack malicious intent when
administering the device. The network device is not expected to be capable of defending against
a malicious Administrator that actively works to bypass or compromise the security of the
device.
49. For TOEs supporting X.509v3 certificate-based authentication, the Security Administrator(s) are
expected to fully validate (e.g. offline verification) any CA certificate (root CA certificate or
intermediate CA certificate) loaded into the TOE’s trust store (aka 'root store', ' trusted CA Key
Store', or similar) as a trust anchor prior to use (e.g. offline verification).
• A.REGULAR_UPDATES
50. The network device firmware and software is assumed to be updated by an Administrator on a
regular basis in response to the release of product updates due to known vulnerabilities.
• A.ADMIN_CREDENTIALS_SECURE
51. The Administrator’s credentials (private key) used to access the network device are protected by
the platform on which they reside.
• A.RESIDUAL_INFORMATION
Security Target for Junos OS 22.2R1 for MX Series with MX-SPC3 Juniper Networks, Inc.
Version 1.1 Page 17 of 67
52. The Administrator must ensure that there is no unauthorized access possible for sensitive
residual information (e.g. cryptographic keys, keying material, PINs, passwords etc.) on
networking equipment when the equipment is discarded or removed from its operational
environment.
• A.NO_THRU_TRAFFIC_PROTECTION
53. This assumption is only applicable to interfaces in the TOE that are defined by the [CPP_ND]. For
these interfaces, the TOE does not provide any assurance regarding the protection of traffic that
traverses it.
54. The following assumption A.CONNECTIONS is introduced through compliance to
[MOD_VPNGW]. It is typically understood that an ST claiming exact compliance to a Protection
Profile cannot introduce assumptions. However, that is on the understanding this limits
applicability of the security functional requirements for the TOE, whereas this assumption is a
clarification of how the TOE is to be connected to distinct networks.
• A.CONNECTIONS
55. It is assumed that the TOE is connected to distinct networks in a manner that ensures that the
TOE security policies will be enforced on all applicable network traffic flowing among the
attached networks.
56. No assumptions are identified for this TOE in addition to those specified in the collaborative
Protection Profile and PP-modules that the .
3.3 Organizational Security Policies
57. The OSP P.ACCESS_BANNER applied for this TOE is as defined in [CPP_ND] Section 4.3. No
additional OSPs are identified and no modification to the statement of OSPs is made for this
TOE.
• P.ACCESS_BANNER
58. The TOE shall display an initial banner describing restrictions of use, legal agreements, or any
other appropriate information to which users consent by accessing the TOE.
Security Target for Junos OS 22.2R1 for MX Series with MX-SPC3 Juniper Networks, Inc.
Version 1.1 Page 18 of 67
4 Security Objectives
59. As this TOE is not distributed, none of the objectives relating to distributed TOEs are specified
for this TOE.
4.1 Security Objectives for the TOE
60. The security objectives for the TOE are trivially determined through the inverse of the statement
of threats presented in [CPP_ND] Section 4.1.
61. These are further augmented by the statement of security objectives for the TOE in relation to
the VPN capabilities as detailed in [MOD_VPNGW] Section 4.1, namely:
• O.ADDRESS_FILTERING
62. To address the issues associated with unauthorized disclosure of information, inappropriate
access to services, misuse of services, disruption or denial of services, and network-based
reconnaissance, compliant TOE’s will implement Packet Filtering capability. That capability will
restrict the flow of network traffic between protected networks and other attached networks
based on network addresses of the network nodes originating (source) and/or receiving
(destination) applicable network traffic as well as on established connection information.
• O.AUTHENTICATION – as also defined by the inverse of the threats defined in [CPP_ND]
Section 4.1
63. To further address the issues associated with unauthorized disclosure of information, a
compliant TOE’s authentication ability (IPSec) will allow a VPN peer to establish VPN connectivity
with another VPN peer and ensure that any such connection attempt is both authenticated and
authorized. VPN endpoints authenticate each other to ensure they are communicating with an
authorized external IT entity.
• O.CRYPTOGRAPHIC_FUNCTIONS – as also defined by the inverse of the threats defined
in [CPP_ND] Section 4.1
64. To address the issues associated with unauthorized disclosure of information, inappropriate
access to services, misuse of services, disruption of services, and network-based reconnaissance,
compliant TOEs will implement cryptographic capabilities. These capabilities are intended to
maintain confidentiality and allow for detection and modification of data that is transmitted
outside of the TOE.
• O.FAIL_SECURE
65. There may be instances where the TOE’s hardware malfunctions or the integrity of the TOE’s
software is compromised, the latter being due to malicious or non-malicious intent. To address
the concern of the TOE operating outside of its hardware or software specification, the TOE will
shut down upon discovery of a problem reported via the self-test mechanism and provide
signature-based validation of updates to the TSF.
• O.PORT_FILTERING
66. To further address the issues associated with unauthorized disclosure of information, etc., a
compliant TOE’s port filtering capability will restrict the flow of network traffic between
protected networks and other attached networks based on the originating (source) and/or
receiving (destination) port (or service) identified in the network traffic as well as on established
connection information.
• O.SYSTEM_MONITORING – as also defined by the inverse of the threats defined in
[CPP_ND] Section 4.1
Security Target for Junos OS 22.2R1 for MX Series with MX-SPC3 Juniper Networks, Inc.
Version 1.1 Page 19 of 67
67. To address the issues of administrators being able to monitor the operations of the VPN
gateway, it is necessary to provide a capability to monitor system activity. Compliant TOEs will
implement the ability to log the flow of network traffic. Specifically, the TOE will provide the
means for administrators to configure packet filtering rules to ‘log’ when network traffic is found
to match the configured rule. As a result, matching a rule configured to ‘log’ will result in
informative event logs whenever a match occurs. In addition, the establishment of security
associations (SAs) is auditable, not only between peer VPN gateways, but also with certification
authorities (CAs).
• O.TOE_ADMINISTRATION – as also defined by the inverse of the threats defined in
[CPP_ND] Section 4.1
68. Compliant TOEs will provide the functions necessary for an administrator to configure the packet
filtering rules, as well as the cryptographic aspects of the IPsec protocol that are enforced by the
TOE.
4.2 Security Objectives for the Operational Environment
69. The statement of security objectives for the operational environment of this TOE is as defined in
[CPP_ND] Section 5.1 and [MOD_VPNGW] Section 4.2, namely:
• OE.PHYSICAL
70. Physical security, commensurate with the value of the TOE and the data it contains, is provided
by the environment.
• OE.NO_GENERAL_PURPOSE
71. There are no general-purpose computing capabilities (e.g., compilers or user applications)
available on the TOE, other than those services necessary for the operation, administration and
support of the TOE.
• OE.TRUSTED_ADMIN
72. Security Administrators are trusted to follow and apply all guidance documentation in a trusted
manner.
73. For TOEs supporting X.509v3 certificate-based authentication, the Security Administrator(s) are
assumed to monitor the revocation status of all certificates in the TOE's trust store and to
remove any certificate from the TOE’s trust store in case such certificate can no longer be
trusted.
• OE.UPDATES
74. The TOE firmware and software is updated by an Administrator on a regular basis in response to
the release of product updates due to known vulnerabilities.
• OE.ADMIN_CREDENTIALS_SECURE
75. The Administrator’s credentials (private key) used to access the TOE must be protected on any
other platform on which they reside.
• OE.RESIDUAL_INFORMATION
The Security Administrator ensures that there is no unauthorized access possible for sensitive
residual information (e.g. cryptographic keys, keying material, PINs, passwords etc.) on networking
equipment when the equipment is discarded or removed from its operational environment.
• OE.CONNECTIONS
76. TOE administrators will ensure that the TOE is installed in a manner that will allow the TOE to
effectively enforce its policies on network traffic of monitored networks.
Security Target for Junos OS 22.2R1 for MX Series with MX-SPC3 Juniper Networks, Inc.
Version 1.1 Page 20 of 67
• OE.NO_THRU_TRAFFIC_PROTECTION
77. Except for interfaces covered by MOD_VPNGW, the TOE does not provide any protection of
traffic that traverses it.
4.3 Security Objectives rationale
78. As these objectives for the TOE and operational environment are the same as those specified in
[CPP_ND] and [MOD_VPNGW], the rationales provided in the prose of the following are wholly
applicable to this security target as the statements of threats, assumptions, OSPs and security
objectives provided in this security target are the same as those defined in the collaborative
Protection Profile, and PP-Module to which this ST claims conformance
• [CPP_ND] section 4
• [MOD_VPNGW] and section 4.3.
Security Target for Junos OS 22.2R1 for MX Series with MX-SPC3 Juniper Networks, Inc.
Version 1.1 Page 21 of 67
5 Security Functional Requirements
79. All security functional requirements are taken from [CPP_ND] and [MOD_VPNGW].
80. The Security Functional requirements are primarily structured according to [CPP_ND], with
requirements and operations from [MOD_VPNGW] inserted as appropriate. The SFRs are
presented in accordance with the conventions described in [CPP_ND] Section 6.1, and section
1.4 of this document.
81. As this TOE is not distributed, none of the security functional requirements relating to
distributed TOEs are specified for this TOE.
5.1 Security Audit (FAU)
5.1.1 Security Audit Data generation (FAU_GEN)
5.1.1.1 FAU_GEN.1 Audit data generation
FAU_GEN.1/ND Network Device Audit Data Generation
FAU_GEN.1.1/ND The TSF shall be able to generate an audit record of the following auditable
events:
a) Start-up and shut-down of the audit functions;
b) All auditable events for the not specified level of audit; and
c) All administrative actions comprising:
• Administrative login and logout (name of user account shall be logged if individual user
accounts are required for Administrators).
• Changes to TSF data related to configuration changes (in addition to the information
that a change occurred it shall be logged what has been changed).
• Generating/import of, changing, or deleting of cryptographic keys (in addition to the
action itself a unique key name or key reference shall be logged).
• Resetting passwords (name of related user account shall be logged).
• [
o Starting and stopping services.
];
d) Specifically defined auditable events listed in Table 4.
ST Application Note:
The “Services” referenced in the above requirement relate to the trusted communication channel to
the external syslog server (netconf over SSH) and the trusted path for remote administrative
sessions (SSH, which can be tunneled over IPsec).
FAU_GEN.1.2/ND The TSF shall record within each audit record at least the following information:
a) Date and time of the event, type of event, subject identity, and the outcome (success or
failure) of the event; and
b) For each audit event type, based on the auditable event definitions of the functional
components included in the ST, information specified in column three of Table 4.
Requirement Auditable Events Additional Audit Record
Contents
FAU_GEN.1 None None
FAU_GEN.2 None None
FAU_STG_EXT.1 None None
Security Target for Junos OS 22.2R1 for MX Series with MX-SPC3 Juniper Networks, Inc.
Version 1.1 Page 22 of 67
FAU_STG.1 None None
FCS_CKM.1 None None
FCS_CKM.2 None None
FCS_CKM.4 None None
FCS_COP.1/DataEncryption None None
FCS_COP.1/SigGen None None
FCS_COP.1/Hash None None
FCS_COP.1/KeyedHash None None
FCS_RBG_EXT.1 None None
FIA_AFL.1 Unsuccessful login attempts
limit is met or exceeded.
Origin of the attempt (e.g., IP
address).
FIA_PMG_EXT.1 None None
FIA_UIA_EXT.1 All use of identification and
authentication mechanism.
Provided user identity, origin of
the attempt (e.g., IP address).
FIA_UAU_EXT.2 All use of identification and
authentication mechanism.
Origin of the attempt (e.g., IP
address).
FIA_UAU.7 None None
FMT_MOF.1/ManualUpdate Any attempt to initiate a
manual update
None
FMT_MTD.1/CoreData All management activities of
TSF data
None
FMT_SMF.1/ND None None
FMT_SMR.2 None None
FPT_SKP_EXT.1 None None
FPT_APW_EXT.1 None None
FPT_TST_EXT.1 None None
FPT_TUD_EXT.1 Initiation of update; result of
the update attempt (success
or failure)
None.
FPT_STM_EXT.1 Discontinuous changes to time
- either Administrator
actuated or changed via an
automated process.
For discontinuous changes to
time: The old and new values for
the time. Origin of the attempt
to change time for success and
failure (e.g., IP address).
FTA_SSL_EXT.1 (if “terminate
the session” is selected)
The termination of a local
interactive session by the
session locking mechanism.
None.
FTA_SSL.3 The termination of a remote
session by the session locking
mechanism.
None
FTA_SSL.4 The termination of an
interactive session.
None
FTA_TAB.1 None None
FTP_ITC.1 Initiation of the trusted
channel.
Termination of the trusted
channel.
Failure of the trusted channel
functions.
Identification of the initiator and
target of failed trusted channels
establishment attempt.
FTP_TRP.1/Admin Initiation of the trusted path. None.
Security Target for Junos OS 22.2R1 for MX Series with MX-SPC3 Juniper Networks, Inc.
Version 1.1 Page 23 of 67
Termination of the trusted
path.
Failure of the trusted path
functions.
FCS_SSHS_EXT.1 Failure to establish an SSH
session
Reason for failure
FIA_X509_EXT.1/Rev Unsuccessful attempt to
validate a certificate.
Any addition, replacement or
removal of trust anchors in
the TOE's trust store.
Reason for failure of certificate
validation.
Identification of certificates
added, replaced or removed as
trust anchor in the TOE's trust
store.
FIA_X509_EXT.2 None None
FIA_X509_EXT.3 None None
FMT_MOF.1/Functions Modification of the behaviour
of the transmission of audit
data to an external IT entity,
the handling of audit data, the
audit functionality when Local
Audit Storage Space is full.
None.
FMT_MOF.1/Services Starting and stopping of
services.
None
FMT_MTD.1/CryptoKeys Management of cryptographic
keys.
None.
FCS_IPSEC_EXT.14
Session Establishment with
peer
Entire packet contents of
packets transmitted/received
during session establishment
FIA_X509_EXT.1 Session establishment with CA Entire packet contents of
packets transmitted/received
during session establishment
FPF_RUL_EXT.15
Application of rules
configured with the ‘log’
operation
Source and destination
addresses
Source and destination ports
Transport Layer Protocol
Table 4 FAU_GEN.1 Security Functional Requirements and Auditable Events6
5.1.1.2 FAU_GEN.2 User identity association
FAU_GEN.2 User identity association
FAU_GEN.2.1 For audit events resulting from actions of identified users, the TSF shall be able to
associate each auditable event with the identity of the user that caused the event.
4
As per [MOD_VPNGW]
5
As per [MOD_VPNGW]
6
Includes also audit evens from [MOD_VPNGW] and Error! Reference source not found.
Security Target for Junos OS 22.2R1 for MX Series with MX-SPC3 Juniper Networks, Inc.
Version 1.1 Page 24 of 67
5.1.2 Security audit event storage (Extended – FAU_STG_EXT)
5.1.2.1 FAU_ STG_EXT.1 Protected Audit Event Storage
FAU_STG_EXT.1 Protected Audit Event Storage
FAU_STG_EXT.1.1 The TSF shall be able to transmit the generated audit data to an external IT entity
using a trusted channel according to FTP_ITC.1.
ST Application Note
Transfer of the audit date to the external server is performed automatically (without further Security
Administrator intervention) in the evaluated deployment.
FAU_STG_EXT.1.2 The TSF shall be able to store generated audit data on the TOE itself. In addition
[TOE shall consist of a single standalone component that stores audit data locally.].
FAU_STG_EXT.1.3 The TSF shall [overwrite previous audit records according to the following rule:
[oldest log is overwritten]] when the local storage space for audit data is full.
5.1.2.2 FAU_STG.1 Protected audit trail storage (Optional)
FAU_STG.1 Protected audit trail storage
FAU_STG.1.1 The TSF shall protect the stored audit records in the audit trail from unauthorised
deletion.
FAU_STG.1.2 The TSF shall be able to prevent unauthorised modifications to the stored audit
records in the audit trail.
5.2 Cryptographic Support (FCS)
5.2.1 Cryptographic Key Management (FCS_CKM)
5.2.1.1 FCS_CKM.1 Cryptographic Key Generation (Refinement)
FCS_CKM.1/ND Cryptographic Key Generation/ND
FCS_CKM.1.1/ND The TSF shall generate asymmetric cryptographic keys in accordance with a
specified cryptographic key generation algorithm: [
• RSA schemes using cryptographic key sizes of 2048-bit or greater that meet the
following: FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Appendix B.3;
• ECC schemes using “NIST curves” [P-256, P-384, P-521] that meet the following: FIPS PUB
186-4, “Digital Signature Standard (DSS)”, Appendix B.4;
• FFC schemes using cryptographic key sizes of 2048 -bit or greater that meet the
following: FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Appendix B.1
• FFC Schemes using ‘safe-prime’ groups that meet the following: “NIST Special Publication
800-56A Revision 3, Recommendation for Pair-Wise Key Establishment Schemes Using
Discrete Logarithm Cryptography” and [RFC 3526].
] and specified cryptographic key sizes [assignment: cryptographic key sizes] that meet the
following: [assignment: list of standards].
Security Target for Junos OS 22.2R1 for MX Series with MX-SPC3 Juniper Networks, Inc.
Version 1.1 Page 25 of 67
5.2.1.2 FCS_CKM.1 Cryptographic Key Generation (Refinement)
FCS_CKM.1/IKE Cryptographic Key Generation (for IKE Peer Authentication)7
FCS_CKM.1.1/IKE The TSF shall generate asymmetric cryptographic keys used for IKE peer
authentication in accordance with a specified cryptographic key generation algorithm [
• FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Appendix B.3 for RSA schemes;
• FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Appendix B.4 for ECDSA schemes and
implementing “NIST curves” P-256, P-384 and [no other curves]]
and
• no other key generation algorithms]
and specified cryptographic key sizes equivalent to, or greater than, a symmetric key
strength of 112 bits.
5.2.1.3 FCS_CKM.2 Cryptographic Key Establishment (Refinement)
FCS_CKM.2 Cryptographic Key Establishment
FCS_CKM.2.1 The TSF shall perform cryptographic key establishment in accordance with a specified
cryptographic key establishment method: [
• Elliptic curve-based key establishment schemes that meet the following: NIST Special
Publication 800-56A Revision 3, “Recommendation for Pair-Wise Key Establishment
Schemes Using Discrete Logarithm Cryptography”8
;
• Finite field-based key establishment schemes that meet the following: NIST Special
Publication 800-56A Revision 2, “Recommendation for Pair-Wise Key Establishment
Schemes Using Discrete Logarithm Cryptography”;
• FFC Schemes using ‘safe-prime’ groups that meet the following: “NIST Special Publication
800-56A Revision 3, Recommendation for Pair-Wise Key Establishment Schemes Using
Discrete Logarithm Cryptography” and [groups listed in RFC 3526]9
.
] that meets the following: [assignment: list of standards].
5.2.1.4 FCS_CKM.4 Cryptographic Key Destruction
FCS_CKM.4 Cryptographic Key Destruction
FCS_CKM.4.1 The TSF shall destroy cryptographic keys in accordance with a specified cryptographic
key destruction method
• For plaintext keys in volatile storage, the destruction shall be executed by a [destruction
of reference to the key directly followed by a request for garbage collection];
• For plaintext keys in non-volatile storage, the destruction shall be executed by the
invocation of an interface provided by a part of the TSF that [
o logically addresses the storage location of the key and performs a [single
overwrite consisting of [zeroes]]
that meets the following: No Standard.
7
In accordance with [MOD_VPNGW]
8
As per TD0581
9
As per TD0580
Security Target for Junos OS 22.2R1 for MX Series with MX-SPC3 Juniper Networks, Inc.
Version 1.1 Page 26 of 67
5.2.2 Cryptographic Operation (FCS_COP)
5.2.2.1 FCS_COP.1 Cryptographic Operation
FCS_COP.1/DataEncryption Cryptographic Operation (AES Data Encryption/Decryption)
FCS_COP.1.1/DataEncryption10
The TSF shall perform encryption/decryption in accordance with a
specified cryptographic algorithm AES used in [CBC, GCM] and [CTR] mode and cryptographic key
sizes [128 bits, 256 bits] and [192 bits] that meet the following AES as specified in ISO 18033-3, [CBC
as specified in ISO 10116, GCM as specified in ISO 19772] and [CTR as specified in ISO 10116].
FCS_COP.1/SigGen Cryptographic Operation (Signature Generation and Verification)
FCS_COP.1.1/SigGen The TSF shall perform cryptographic signature services (generation and
verification) in accordance with a specified cryptographic algorithm [
• RSA Digital Signature Algorithm and cryptographic key sizes (modulus) [2048 bits, 3072
bits, 4096 bits],
• Elliptic Curve Digital Signature Algorithm and cryptographic key sizes [256 bits, 384 bits,
521 bits]
that meet the following: [
• For RSA schemes: FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Section 5.5, using
PKCS #1 v2.1 Signature Schemes RSASSA-PSS and/or RSASSA-PKCS1v1_5; ISO/IEC 9796-2,
Digital signature scheme 2 or Digital Signature scheme 3,
• For ECDSA schemes: FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Section 6 and
Appendix D, Implementing “NIST curves” [P-256, P-384, P-521]; ISO/IEC 14888-3, Section
6.4
].
FCS_COP.1/Hash Cryptographic Operation (Hash Algorithm)
FCS_COP.1.1/Hash The TSF shall perform cryptographic hashing services in accordance with a
specified cryptographic algorithm [SHA-1, SHA-256, SHA-384, SHA-512] and cryptographic key sizes
[assignment: cryptographic key sizes] and message digest sizes [160, 256, 384, 512] bits that meet
the following: ISO/IEC 10118-3:2004.
FCS_COP.1/KeyedHash Cryptographic Operation (Keyed Hash Algorithm)
FCS_COP.1.1/KeyedHash The TSF shall perform keyed-hash message authentication in accordance
with a specified cryptographic algorithm [HMAC-SHA-1, HMAC-SHA-256, HMAC-SHA-384, HMAC-
SHA-512] and cryptographic key sizes [160, 256, 384 and 512 bits] and message digest sizes [160,
256, 384 and 512] bits that meet the following: ISO/IEC 9797-2:2011, Section 7 “MAC Algorithm 2”.
5.2.3 Random Bit Generation (Extended – FCS_RBG_EXT)
5.2.3.1 FCS_RBG_EXT.1 Random Bit Generation
FCS_RBG_EXT.1 Random Bit Generation
FCS_RBG_EXT.1.1 The TSF shall perform all deterministic random bit generation services in
accordance with ISO/IEC 18031:2011 using [HMAC_DRBG (any)].
10
The wording is as per [MOD_VPNGW]
Security Target for Junos OS 22.2R1 for MX Series with MX-SPC3 Juniper Networks, Inc.
Version 1.1 Page 27 of 67
FCS_RBG_EXT.1.2 The deterministic RBG shall be seeded by at least one entropy source that
accumulates entropy from [[1] software-based noise source] with a minimum of [256 bits] of
entropy at least equal to the greatest security strength, according to ISO/IEC 18031:2011 Table C.1
“Security Strength Table for Hash Functions”, of the keys and hashes that it will generate.
5.2.4 Cryptographic Protocols (Extended – FCS_ IPSEC_EXT & FCS_SSHS_EXT SSH
Protocol
5.2.4.1 FCS_IPSEC_EXT.1 IPsec Protocol
FCS_IPSEC_EXT.1 IPsec Protocol
FCS_IPSEC_EXT.1.1 The TSF shall implement the IPsec architecture as specified in RFC 4301.
FCS_IPSEC_EXT.1.2 The TSF shall have a nominal, final entry in the SPD that matches anything that is
otherwise unmatched, and discards it.
FCS_IPSEC_EXT.1.3 The TSF shall implement [tunnel mode].
FCS_IPSEC_EXT.1.411
The TSF shall implement the IPsec protocol ESP as defined by RFC 4303 using
the cryptographic algorithms [AES-CBC-128 (RFC 3602), AES-CBC-256 (RFC 3602), AES-GCM-128 (RFC
4106), AES-GCM-256 (RFC 4106)] and [AES-CBC-192 (RFC 3602), AES-GCM-192 (RFC 4106)] together
with a Secure Hash Algorithm (SHA)-based HMAC [HMAC-SHA-256, HMAC-SHA-384, HMAC-SHA-
512].
FCS_IPSEC_EXT.1.5 The TSF shall implement the protocol [IKEv1, using Main Mode for Phase 1
exchanges, as defined in RFCs 2407, 2408, 2409, RFC 4109, [no other RFCs for extended sequence
numbers], and [RFC 4868 for hash functions];
• IKEv2 as defined in RFC 5996 and [with no support for NAT traversal], and [RFC 4868 for
hash functions]
]
FCS_IPSEC_EXT.1.6 The TSF shall ensure the encrypted payload in the [IKEv1, IKEv2] protocol uses
the cryptographic algorithms [AES-CBC-128, AES-CBC-192, AES-CBC-256 (specified in RFC 3602), AES-
GCM-128, AES-GCM-256 (specified in RFC 5282)].
FCS_IPSEC_EXT.1.7 The TSF shall ensure that [
• IKEv1 Phase 1 SA lifetimes can be configured by a Security Administrator based on [
o length of time, where the time values can be configured within [0.2-24] hours12
;
];
• IKEv2 SA lifetimes can be configured by a Security Administrator based on [
o length of time, where the time values can be configured within [0.2-24] hours
]
].
FCS_IPSEC_EXT.1.8 The TSF shall ensure that [
• IKEv1 Phase 2 SA lifetimes can be configured by a Security Administrator based on [
o length of time, where the time values can be configured within [8] hours;
];
• IKEv2 Child SA lifetimes can be configured by a Security Administrator based on [
o length of time, where the time values can be configured within [8] hours;
]
11
The wording as in [MOD_VPNGW]
12
Length of time can be configured between 180 seconds and 86,400 seconds.
Security Target for Junos OS 22.2R1 for MX Series with MX-SPC3 Juniper Networks, Inc.
Version 1.1 Page 28 of 67
].
FCS_IPSEC_EXT.1.9 The TSF shall generate the secret value x used in the IKE Diffie-Hellman key
exchange (“x” in g^x mod p) using the random bit generator specified in FCS_RBG_EXT.1, and having
a length of at least [224 (for DH Group 14), 256 (for DH Groups 19 and 24), 384 (for DH Group 20)
and 512 (for DH Group 21)] bits.
FCS_IPSEC_EXT.1.10 The TSF shall generate nonces used in [IKEv1, IKEv2] exchanges of length [
• at least 128 bits in size and at least half the output size of the negotiated pseudorandom
function (PRF) hash ].
FCS_IPSEC_EXT.1.1113
The TSF shall ensure that IKE protocols implement DH Group(s)
• [14 (2048-bit MODP), 15 (3072-bit MODP), 16 (4096-bit MODP)] according to RFC 3526
• 19 (256-bit Random ECP), 20 (384-bit random ECP), 21 (521-bit Random ECP), 24 (2048-
bit MODP with 256-bit POS) according to RFC 5114]
FCS_IPSEC_EXT.1.12 The TSF shall be able to ensure by default that the strength of the symmetric
algorithm (in terms of the number of bits in the key) negotiated to protect the [IKEv1 Phase 1, IKEv2
IKE_SA] connection is greater than or equal to the strength of the symmetric algorithm (in terms of
the number of bits in the key) negotiated to protect the [IKEv1 Phase 2, IKEv2 CHILD_SA] connection.
FCS_IPSEC_EXT.1.13 The TSF shall ensure that all IKE protocols perform peer authentication using
[RSA, ECDSA] that use X.509v3 certificates that conform to RFC 4945 and [Pre-shared Keys].
FCS_IPSEC_EXT.1.1414
The TSF shall only establish a trusted channel if the presented identifier in the
received certificate matches the configured reference identifier, where the presented and reference
identifiers are of the following fields and types: Distinguished Name (DN), [SAN: IP address, SAN:
Fully Qualified Domain Name (FQDN), SAN: user FQDN, no other reference identifier type].
5.2.4.2 FCS_SSHS_EXT.1 SSH Server Protocol
FCS_SSHS_EXT.1 SSH Server Protocol
FCS_SSHS_EXT.1.1 The TSF shall implement the SSH protocol that complies with RFCs 4251, 4252,
4253, 4254, [5656, 6668].
FCS_SSHS_EXT.1.2 The TSF shall ensure that the SSH protocol implementation supports the
following authentication methods as described in RFC 4252: public key-based, [password-based].
FCS_SSHS_EXT.1.3 The TSF shall ensure that, as described in RFC 4253, packets greater than [256K]
bytes in an SSH transport connection are dropped.
FCS_SSHS_EXT.1.4 The TSF shall ensure that the SSH transport implementation uses the following
encryption algorithms and rejects all other encryption algorithms: [aes128-cbc, aes256-cbc, aes128-
ctr, aes256-ctr].
FCS_SSHS_EXT.1.5 The TSF shall ensure that the SSH public-key based authentication
implementation uses [ssh-rsa, ecdsa-sha2-nistp256, ecdsa-sha2-nistp384, ecdsa-sha2-nistp521] as its
public key algorithm(s) and rejects all other public key algorithms.
FCS_SSHS_EXT.1.6 The TSF shall ensure that the SSH transport implementation uses [hmac-sha1,
hmac-sha2-256, hmac-sha2-512] as its MAC algorithm(s) and rejects all other MAC algorithm(s).
13
In accordance with [MOD_VPNGW]
14
In accordance with [MOD_VPNGW]
Security Target for Junos OS 22.2R1 for MX Series with MX-SPC3 Juniper Networks, Inc.
Version 1.1 Page 29 of 67
FCS_SSHS_EXT.1.7 The TSF shall ensure that [diffie-hellman-group14-sha1, ecdh-sha2-nistp256] and
[ecdh-sha2-nistp384, ecdh-sha2-nistp521] are the only allowed key exchange methods used for the
SSH protocol.
FCS_SSHS_EXT.1.8 The TSF shall ensure that within SSH connections, the same session keys are used
for a threshold of no longer than one hour, and each encryption key is used to protect no more than
one gigabyte of data. After any of the thresholds are reached, a rekey needs to be performed.
5.3 Identification and Authentication (FIA)
5.3.1 Authentication Failure Management (FIA_AFL)
5.3.1.1 FIA_AFL.1 Authentication Failure Management (Refinement)
FIA_AFL.1 Authentication Failure Management
FIA_AFL.1.1 The TSF shall detect when an Administrator configurable positive integer within [1 to
10] unsuccessful authentication attempts occur related to Administrators attempting to authenticate
remotely using a password.
FIA_AFL.1.2 When the defined number of unsuccessful authentication attempts has been met, the
TSF shall [prevent the offending Administrator from successfully establishing remote session using
any authentication method that involves a password until [Security Administrator has unlocked the
account] is taken by an Administrator; prevent the offending Administrator from successfully
establishing remote session using any authentication method that involves a password until an
Administrator defined time period has elapsed].
ST Application Note
Security Administrator can unlock the account of another administrator who has failed to
authenticate from the console instead of requiring the administrator to wait for the delay of a
configured time period to lapse before another attempt can be made to authenticate.
5.3.2 Password Management (Extended – FIA_PMG_EXT)
5.3.2.1 FIA_PMG_EXT.1 Password Management
FIA_PMG_EXT.1 Password Management
FIA_PMG_EXT.1.1 The TSF shall provide the following password management capabilities for
administrative passwords:
a) Passwords shall be able to be composed of any combination of upper and lower case letters,
numbers, and the following special characters: [“!”, “@”, “#”, “$”, “%”, “^”, “&”, “*”, “(“, “)”,
[and all other standard ASCII, extended ASCII and Unicode characters]];
b) Minimum password length shall be configurable to between [10] and [20] characters.
5.3.3 User Identification and Authentication (Extended – FIA_UIA_EXT)
5.3.3.1 FIA_UIA_EXT.1 User Identification and Authentication
FIA_UIA_EXT.1 User Identification and Authentication
FIA_UIA_EXT.1.1 The TSF shall allow the following actions prior to requiring the non-TOE entity to
initiate the identification and authentication process:
• Display the warning banner in accordance with FTA_TAB.1;
• [[ICMP echo]].
Security Target for Junos OS 22.2R1 for MX Series with MX-SPC3 Juniper Networks, Inc.
Version 1.1 Page 30 of 67
FIA_UIA_EXT.1.2 The TSF shall require each administrative user to be successfully identified and
authenticated before allowing any other TSF-mediated actions on behalf of that administrative user.
5.3.4 User authentication (FIA_UAU) (Extended – FIA_UAU_EXT)
5.3.4.1 FIA_UAU_EXT.2 Password-based Authentication Mechanism
FIA_UAU_EXT.2 Password-based Authentication Mechanism
FIA_UAU_EXT.2.1 The TSF shall provide a local [password-based] authentication mechanism to
perform local administrative user authentication.
5.3.4.2 FIA_UAU.7 Protected Authentication Feedback
FIA_UAU.7 Protected Authentication Feedback
FIA_UAU.7.1 The TSF shall provide only obscured feedback to the administrative user while the
authentication is in progress at the local console.
5.3.5 Authentication using X.509 certificates (Extended – FIA_X509_EXT)
5.3.5.1 FIA_X509_EXT.1 X.509 Certificate Validation
FIA_X509_EXT.1/Rev X.509 Certificate Validation
FIA_X509_EXT.1.1/Rev The TSF shall validate certificates in accordance with the following rules:
• RFC 5280 certificate validation and certificate path validation supporting a minimum
path length of three certificates.
• The certification path must terminate with a trusted CA certificate designated as a trust
anchor.
• The TSF shall validate a certification path by ensuring that all CA certificates in the
certification path contain the basicConstraints extension with the CA flag set to TRUE.
• The TSF shall validate the revocation status of the certificate using [a Certificate
Revocation List (CRL) as specified in RFC 5280 Section 6.3]
• The TSF shall validate the extendedKeyUsage field according to the following rules:
o Certificates used for trusted updates and executable code integrity verification
shall have the Code Signing purpose (id-kp 3 with OID 1.3.6.1.5.5.7.3.3) in the
extendedKeyUsage field.
o Server certificates presented for TLS shall have the Server Authentication purpose
(id-kp 1 with OID 1.3.6.1.5.5.7.3.1) in the extendedKeyUsage field.
o Client certificates presented for TLS shall have the Client Authentication purpose
(id-kp 2 with OID 1.3.6.1.5.5.7.3.2) in the extendedKeyUsage field.
o OCSP certificates presented for OCSP responses shall have the OCSP Signing
purpose (id-kp 9 with OID 1.3.6.1.5.5.7.3.9) in the extendedKeyUsage field.
FIA_X509_EXT.1.2/Rev The TSF shall only treat a certificate as a CA certificate if the basicConstraints
extension is present and the CA flag is set to TRUE.
5.3.5.2 FIA_X509_EXT.2 X.509 Certificate Authentication
FIA_X509_EXT.2 X.509 Certificate Authentication
FIA_X509_EXT.2.115
The TSF shall use X.509v3 certificates as defined by RFC 5280 to support
authentication for IPSec and [no additional uses].
15
In accordance to [MOD_VPNGW]
Security Target for Junos OS 22.2R1 for MX Series with MX-SPC3 Juniper Networks, Inc.
Version 1.1 Page 31 of 67
FIA_X509_EXT.2.2 When the TSF cannot establish a connection to determine the validity of a
certificate, the TSF shall [allow the Administrator to choose whether to accept the certificate in
these cases, not accept the certificate].
5.3.5.3 FIA_X509_EXT.3 X.509 Certificate Requests
FIA_X509_EXT.3 X.509 Certificate Requests
FIA_X509_EXT.3.1 The TSF shall generate a Certificate Request as specified by RFC 2986 and be able
to provide the following information in the request: public key and [device-specific information,
Common Name, Organization, Organizational Unit, Country].
FIA_X509_EXT.3.2 The TSF shall validate the chain of certificates from the Root CA upon receiving
the CA Certificate Response.
5.3.5.4 FIA_PSK_EXT.1 Pre-Shared Keys
5.3.5.5 FIA_PSK_EXT.1 Pre-Shared Keys 16
FIA_PSK_EXT.1.1 The TSF shall be able to use pre-shared keys for IPsec and [no other protocols].
FIA_PSK_EXT.1.2 The TSF shall be able to accept text-based pre-shared keys that:
• are 22 characters and [1 to 255 characters];
• composed of any combination of upper and lower case letters, numbers, and special
characters (that include: “!”, “@”, “#”, “$”, “%”, “^”, “&”, “*”, “(“, and “)”).
FIA_PSK_EXT.1.3 The TSF shall condition the text-based pre-shared keys by using [SHA-1,
[conversion of the text string into an authentication value as per RFC 2409 for IKEv1 or RFC 4306 for
IKEv2, using the pseudo-random function that is configured as the hash algorithm for the IKE
exchanges]].
FIA_PSK_EXT.1.4 The TSF shall be able to [accept] bit-based pre-shared keys.
5.4 Security Management (FMT)
5.4.1 Management of functions in TSF (FMT_MOF)
5.4.1.1 FMT_MOF.1/ManualUpdate Management of security functions behaviour
FMT_MOF.1/ManualUpdate Management of security functions behaviour
FMT_MOF.1.1/ManualUpdate The TSF shall restrict the ability to enable the functions to perform
manual updates to Security Administrators.
5.4.1.2 FMT_MOF.1/Services Management of security functions behaviour
FMT_MOF.1/Services Management of security functions behaviour
FMT_MOF.1.1/Services The TSF shall restrict the ability to start and stop the functions services to
Security Administrators.
16
In accordance with [MOD_VPNGW]
Security Target for Junos OS 22.2R1 for MX Series with MX-SPC3 Juniper Networks, Inc.
Version 1.1 Page 32 of 67
5.4.1.3 FMT_MOF.1/Functions Management of security functions behaviour
FMT_MOF.1/Functions Management of security functions behaviour
FMT_MOF.1.1/Functions The TSF shall restrict the ability to [modify the behaviour of] the functions
[transmission of audit data to an external IT entity, handling of audit data] to Security
Administrators.
5.4.2 Management of TSF Data (FMT_MTD)
5.4.2.1 FMT_MTD.1/CoreData Management of TSF Data
FMT_MTD.1/CoreData Management of TSF Data
FMT_MTD.1.1/CoreData The TSF shall restrict the ability to manage the TSF data to Security
Administrators.
5.4.2.2 FMT_MTD.1/CryptoKeys Management of TSF data
FMT_MTD.1/CryptoKeys Management of TSF data
FMT_MTD.1.1/CryptoKeys17
The TSF shall restrict the ability to manage the [cryptographic keys and
certificates used for VPN operations] to [Security Administrators].
5.4.3 Specification of Management Functions (FMT_SMF)
5.4.3.1 FMT_SMF.1 Specification of Management Functions
FMT_SMF.1/ND Specification of Management Functions for ND
FMT_SMF.1.1/ND18
The TSF shall be capable of performing the following management functions: [
• Ability to administer the TOE locally and remotely;
• Ability to configure the access banner;
• Ability to configure the session inactivity time before session termination or locking;
• Ability to update the TOE, and to verify the updates using digital signature and [no
other] capability prior to installing those updates;
• Ability to configure the authentication failure parameters for FIA_AFL.1;
• Ability to manage cryptographic keys;
• Ability to configure the cryptographic functionality;
• Ability to configure the lifetime for IPsec SAs;
• Ability to import X.509v3 certificates to the TOE's trust store;
• Ability to enable, disable, determine and modify the behavior of all the security functions
of the TOE identified in this PP Module [MOD_VPNGW];
• Ability to configure all security management functions identified in [MOD_VPNGW]other
sections of this PP Module;
• [
o Ability to configure audit behaviour (e.g. change storage locations for
o audit; changes to behaviour when local audit storage space is full);
o Ability to configure thresholds for SSH rekeying;
o Ability to re-enable an Administrator account;
o Ability to set the time which is used for time-stamps;
o Ability to configure the reference identifier for the peer;
o Ability to manage the trusted public keys database].
17
As per [MOD_VPNGW]
18
As per TD0631.
Security Target for Junos OS 22.2R1 for MX Series with MX-SPC3 Juniper Networks, Inc.
Version 1.1 Page 33 of 67
]
FMT_SMF.1/VPN Specification of Management Functions (VPN Gateway)19
FMT_SMF.1.1/VPN The TSF shall be capable of performing the following management functions: [
• Definition of packet filtering rules;
• Association of packet filtering rules to network interfaces;
• Ordering of packet filtering rules by priority;
• [
• Configuration of attributes used to deny establishment of remote VPN client
• session;]
5.4.4 Security management roles (FMT_SMR)
5.4.4.1 FMT_SMR.2 Restrictions on security roles
FMT_SMR.2 Restrictions on Security Roles
FMT_SMR.2.1 The TSF shall maintain the roles:
• Security Administrator.
FMT_SMR.2.2 The TSF shall be able to associate users with roles.
FMT_SMR.2.3 The TSF shall ensure that the conditions
• The Security Administrator role shall be able to administer the TOE locally;
• The Security Administrator role shall be able to administer the TOE remotely
are satisfied.
5.5 Protection of the TSF (FPT)
5.5.1 Protection of TSF Data (Extended – FPT_SKP_EXT)
5.5.1.1 FPT_SKP_EXT.1 Protection of TSF Data (for reading of all pre-shared, symmetric
and private keys)
FPT_SKP_EXT.1 Protection of TSF Data (for reading of all pre-shared, symmetric and private keys)
FPT_SKP_EXT.1.1 The TSF shall prevent reading of all pre-shared keys, symmetric keys, and private
keys.
5.5.2 Protection of Administrator Passwords (Extended – FPT_APW_EXT)
5.5.2.1 FPT_APW_EXT.1 Protection of Administrator Passwords
FPT_APW_EXT.1 Protection of Administrator Passwords
FPT_APW_EXT.1.1 The TSF shall store administrative passwords in non-plaintext form.
FPT_APW_EXT.1.2 The TSF shall prevent the reading of plaintext administrative passwords.
19
As per [MOD_VPNGW]
Security Target for Junos OS 22.2R1 for MX Series with MX-SPC3 Juniper Networks, Inc.
Version 1.1 Page 34 of 67
5.5.3 TSF testing (Extended – FPT_TST_EXT)
5.5.3.1 FPT_TST_EXT.1 TSF Testing (Extended)
FPT_TST_EXT.1 TSF testing
FPT_TST_EXT.1.1 The TSF shall run a suite of the following self-tests [during initial start-up (on
power on)] to demonstrate the correct operation of the TSF: [
• Noise source health tests,
• Power on test,
• File integrity test,
• Crypto integrity test,
• Authentication test,
• Algorithm known answer tests].
5.5.3.2 FPT_TST_EXT.3 TSF Self-Test with Defined Methods
FPT_TST_EXT.3 TSF Testing20
FPT_TST_EXT.3.1 The TSF shall run a suite of the following self-tests [[when loaded for execution]] to
demonstrate the correct operation of the TSF: [integrity verification of stored executable code].
FPT_TST_EXT.3.2 The TSF shall execute the self-testing through [a TSF-provided cryptographic
service specified in FCS_COP.1/SigGen].
5.5.4 Trusted Update (FPT_TUD_EXT)
5.5.4.1 FPT_TUD_EXT.1 Trusted Update
FPT_TUD_EXT.1 Trusted update
FPT_TUD_EXT.1.1 The TSF shall provide Security Administrators the ability to query the currently
executing version of the TOE firmware/software and [no other TOE firmware/software version].
FPT_TUD_EXT.1.2 The TSF shall provide Security Administrators the ability to manually initiate
updates to TOE firmware/software and [no other update mechanism].
FPT_TUD_EXT.1.321
The TSF shall provide means to authenticate firmware/software updates to the
TOE using a digital signature mechanism and [no other mechanism] prior to installing those
updates.
5.5.5 Time stamps (Extended – FPT_STM_EXT))
5.5.5.1 FPT_STM_EXT.1 Reliable Time Stamps
FPT_STM_EXT.1 Reliable Time Stamps
FPT_STM_EXT.1.1 The TSF shall be able to provide reliable time stamps for its own use.
FPT_STM_EXT.1.2 The TSF shall [allow the Security Administrator to set the time].
20
In accordance with [MOD_VPNGW]
21
In accordance with [MOD_VPNGW]
Security Target for Junos OS 22.2R1 for MX Series with MX-SPC3 Juniper Networks, Inc.
Version 1.1 Page 35 of 67
5.5.6 Self-test Failures (FPT_FLS)
5.5.6.1 FPT_FLS.1/SelfTest Fail Secure
5.5.6.1 FPT_FLS.1/SelfTest Fail Secure 22
FPT_FLS.1.1/SelfTest The TSF shall shut down when the following types of failures occur: [failure of
the power-on self-tests, failure of integrity check of the TSF executable image, failure of noise source
health tests].
5.6 TOE Access (FTA)
5.6.1 TSF-initiated Session Locking (Extended – FTA_SSL_EXT)
5.6.1.1 FTA_SSL_EXT.1 TSF-initiated Session Locking
FTA_SSL_EXT.1 TSF-initiated Session Locking
FTA_SSL_EXT.1.1 The TSF shall, for local interactive sessions, [terminate the session] after a Security
Administrator-specified time period of inactivity.
5.6.2 Session locking and termination (FTA_SSL)
5.6.2.1 FTA_SSL.3 TSF-initiated Termination (Refinement)
FTA_SSL.3 TSF-initiated Termination
FTA_SSL.3.1: The TSF shall terminate a remote interactive session after a Security Administrator-
configurable time interval of session inactivity.
5.6.2.2 FTA_SSL.4 User-initiated Termination (Refinement)
FTA_SSL.4 User-initiated Termination
FTA_SSL.4.1: The TSF shall allow Administrator-initiated termination of the Administrator’s own
interactive session.
5.6.3 TOE access banners (FTA_TAB)
5.6.3.1 FTA_TAB.1 Default TOE Access Banners (Refinement)
FTA_TAB.1 Default TOE Access Banners
FTA_TAB.1.1: Before establishing an administrative user session the TSF shall display a Security
Administrator-specified advisory notice and consent warning message regarding use of the TOE.
5.7 Trusted path/channels (FTP)
5.7.1 Trusted Channel (FTP_ITC)
5.7.1.1 FTP_ITC.1 Inter-TSF trusted channel (Refinement)
FTP_ITC.1 Inter-TSF trusted channel
FTP_ITC.1.1 The TSF shall be capable of using [IPsec, SSH] to provide a trusted communication
channel between itself and authorized IT entities supporting the following capabilities: audit server,
[no other capabilities] that is logically distinct from other communication channels and provides
22
In accordance with [MOD_VPNGW]
Security Target for Junos OS 22.2R1 for MX Series with MX-SPC3 Juniper Networks, Inc.
Version 1.1 Page 36 of 67
assured identification of its end points and protection of the channel data from disclosure and
detection of modification of the channel data.
FTP_ITC.1.2 The TSF shall permit the TSF or the authorized IT entities to initiate communication via
the trusted channel.
FTP_ITC.1.3 The TSF shall initiate communication via the trusted channel for [streaming of syslog
events].
FTP_ITC.1/VPN Inter-TSF trusted channel (VPN Communications)23
FTP_ITC.1.1/VPN The TSF shall be capable of using IPsec to provide a communication channel
between itself and authorized IT entities supporting VPN communications that is logically distinct
from other communication channels and provides assured identification of its end points and
protection of the channel data from disclosure and detection of modification of the channel data.
FTP_ITC.1.2/VPN The TSF shall permit [the authorized IT entities] to initiate communication via the
trusted channel.
FTP_ITC.1.3/VPN The TSF shall initiate communication via the trusted channel for [remote VPN
gateways/peers].
5.7.2 Trusted Path (FTP_TRP)
5.7.2.1 FTP_TRP.1/Admin Trusted Path (Refinement)
FTP_TRP.1/Admin Trusted Path
FTP_TRP.1.1/Admin The TSF shall be capable of using [SSH, IPsec] to provide a communication path
between itself and authorized remote Administrators that is logically distinct from other
communication paths and provides assured identification of its end points and protection of the
communicated data from disclosure and provides detection of modification of the channel data.
FTP_TRP.1.2/Admin The TSF shall permit remote Administrators to initiate communication via the
trusted path.
FTP_TRP.1.3/Admin The TSF shall require the use of the trusted path for initial Administrator
authentication and all remote administration actions.
5.8 Packet Filtering (FPF)
5.8.1 Packet Filtering Rules (FPF_RUL_EXT)
5.8.1.1 FPF_RUL_EXT.1 Rules for Packet Filtering
FPF_RUL_EXT.1 Rules for Packet Filtering24
FPF_RUL_EXT.1.1 The TSF shall perform Packet Filtering on network packets processed by the TOE.
FPF_RUL_EXT.1.2 The TSF shall allow the definition of Packet Filtering rules using the following
network protocol fields:
• IPv4 (RFC791)
o Source address
o Destination Address
o Protocol
• IPv6 (RFC2460)
o Source address
o Destination Address
23
In accordance with [MOD_VPNGW]
24
In accordance with [MOD_VPNGW]
Security Target for Junos OS 22.2R1 for MX Series with MX-SPC3 Juniper Networks, Inc.
Version 1.1 Page 37 of 67
o Next Header (Protocol)
• TCP (RFC793)
o Source Port
o Destination Port
• UDP (RFC768)
o Source Port
o Destination Port
FPF_RUL_EXT.1.3 The TSF shall allow the following operations to be associated with Packet Filtering
rules: permit and drop with the capability to log the operation.
FPF_RUL_EXT.1.4 The TSF shall allow the Packet Filtering rules to be assigned to each distinct
network interface.
FPF_RUL_EXT.1.5 The TSF shall process the applicable Packet Filtering rules (as determined in
accordance with FPF_RUL_EXT.1.5) in the following order: Administrator-defined.
FPF_RUL_EXT.1.6 The TSF shall drop traffic if a matching rule is not identified.
Security Target for Junos OS 22.2R1 for MX Series with MX-SPC3 Juniper Networks, Inc.
Version 1.1 Page 38 of 67
6 Security Assurance Requirements
82. The TOE security assurance requirements are taken from [CPP_ND] , together with the
refinements documented in [CPP_ND] Section 7, as listed in Table 5 below.
Assurance Class Assurance Component
Security Target (ASE) Conformance claims (ASE_CCL.1)
Extended components definition (ASE_ECD.1)
ST introduction (ASE_INT.1)
Security objectives for the operational environment (ASE_OBJ.1)
Stated security requirements (ASE_REQ.1)
Security Problem Definition (ASE_SPD.1)
TOE summary specification (ASE_TSS.1)
Development (ADV) Basic functional specification (ADV_FSP.1)
Guidance documents (AGD) Preparative procedures (AGD_PRE.1)
Operational user guidance (AGD_OPE.1)
Life cycle support (ALC) Labelling of the TOE (ALC_CMC.1)
TOE CM coverage (ALC_CMS.1)
Tests (ATE) Independent testing – conformance (ATE_IND.1)
Vulnerability assessment (AVA) Vulnerability survey (AVA_VAN.1)
Table 5 Security Assurance Requirements
Security Target for Junos OS 22.2R1 for MX Series with MX-SPC3 Juniper Networks, Inc.
Version 1.1 Page 39 of 67
7 TOE Summary Specification
7.1 Protected communications
83. Local console access is gained by connecting an RJ-45 cable between the console port on the
appliance and a workstation with a serial connection client.
7.1.1 Algorithms and zeroization
84. All FIPS-approved cryptographic functions implemented by the secure network appliance are
implemented in the following libraries:
• Junos OS 22.2R1 – QAT MX-SPC3 (for IPsec)
• Junos OS 22.2R1 – Quicksec (for IKE Daemon)
• Junos OS 22.2R1 - OpenSSL (for SSH and the PKI daemons, and DRBG for all daemons)
• Junos OS 22.2R1 - OpenSSH (for SSH Daemon)
• Junos OS 22.2R1 – LibMD (MGD daemon)
• Junos OS 22.2R1 - Kernel (for Veriexec and DRBG)
85. All random number generation by the TOE is performed in accordance with NIST Special
Publication 800-90 using HMAC_DRBG implemented in the OpenSSL library (FCS_RBG_EXT.1.1).
Additionally, SHA (256,512) is implemented in the LibMD library which is used for password
hashing by Junos’ MGD daemon.
86. The network appliance is to be operated with FIPS mode enabled.
87. Table 6 lists the cryptographic algorithms implemented by the TOE. It specifies the
corresponding algorithm standards and supported configuration parameters.
HW
Module
Crypto
Module/
Library
Usage
FIPS PUB
Algorithm, Mode,
Keysize, Function,
Hashing, Usage
SFRs Supported
Certificate
Number
SPU:
Data
Plane
QAT MX-
SPC3
IPSec
Daemon
FIPS 197,
SP 800-
38D
AES-GCM (128, 192,
256)
(Encrypt, Decrypt,
AEAD)
FCS_COP.1/DataEncryption A3569
FIPS 197,
SP 800-
38A
AES-CBC (128, 192,
256)
(Encrypt, Decrypt)
FCS_COP.1/DataEncryption A3569
FIPS 180-4 SHS: SHA (1, 256,
512)
Byte Oriented
(Message Digest
Generation)
FCS_COP.1/Hash A3569
FIPS 198-1 HMAC-SHA (1, 256,
512)
Byte Oriented
(Message
Authentication)
FCS_COP.1/KeyedHash A3569
SPU:
Control
Plane
Quicksec IKE
Daemon
FIPS 197,
SP 800-
38A
AES-CBC (128, 192,
256)
(Encrypt, Decrypt)
FCS_COP.1/DataEncryption A4386
FIPS 197,
SP 800-
38D
AES-GCM (128, 256)
(Encrypt, Decrypt,
AEAD)
FCS_COP.1/DataEncryption A4386
Security Target for Junos OS 22.2R1 for MX Series with MX-SPC3 Juniper Networks, Inc.
Version 1.1 Page 40 of 67
HW
Module
Crypto
Module/
Library
Usage
FIPS PUB
Algorithm, Mode,
Keysize, Function,
Hashing, Usage
SFRs Supported
Certificate
Number
FIPS 180-4 SHS: SHA (256, 384,
512)
Byte Oriented
(Message Digest
Generation)
FCS_COP.1/Hash A4386
FIPS 198-1 HMAC-SHA (256,
384)
FCS_COP.1/KeyedHash A4386
SP800-135 IKE v1/v2 KDF ( SHA-
256, SHA-384)
FCS_CKM.2 A4386
RE:
Control
Plane
Quicksec All
Daemon
SP 800-
90A
DRBG (HMAC-SHA-
256)
(Random Bit
Generation)
FCS_RBG_EXT.1 A4386
RE:
Control
Plane
QAT MX-
SPC3
Octeon –
IKED
Daemon
IKE
Daemon
FIPS 186-4 RSA PKCS1_V1_5
(n=2048 (SHA 256),
n=4096 (SHA 256))
(SigGen, SigVer)
FCS_COP.1/SigGen A3945
FIPS 186-4 ECDSA (P-256 w/
SHA-256)
ECDSA (P-384 w/
SHA-384)
ECDSA(P-521
w/SHA-512)
(SigGen, SigVer,
KeyGen for ECDH)
FCS_COP.1/SigGen
FCS.CKM.1/IKE
FCS.CKM.2
A3945
SP 800-
56A Rev. 3
KAS-SSC (Group 14,
19, 20, 21, 24).
FCS.CKM.2 A3945
RE:
Control
Plane
OpenSSL SSH
Daemon
and PKI
Daemon
FIPS 197,
SP800-
38A
AES-CBC/CTR (128,
192, 256)
(Encrypt, Decrypt)
FCS_COP.1/DataEncryption A3693
FIPS 180-4 SHS: SHA (1, 256,
384, 512)
Byte Oriented
(Message Digest
Generation,
KDF Primitive)
FCS_COP.1/Hash A3693
FIPS 198-1 HMAC-SHA (1, 256,
512)
Byte Oriented
(Message
Authentication
DRBG Primitive)
FCS_COP.1/KeyedHash A3693
FIPS 186-4 RSA PKCS1_V1_5
(n=2048 (SHA-256),
n=4096 (SHA-256))
(SigGen, SigVer)
FCS_COP.1/SigGen A3693
FIPS 186-4 RSA X931
(n=2048 (SHA-256),
n=4096 (SHA-256))
(KeyGen)
FCS_CKM.1/ND
FCS_CKM.1/IKE
A3693
FIPS 186-4 ECDSA [P-256 (SHA-
256)], [P-384 (SHA-
384)], [P-521 (SHA-
512)]
(SigGen, SigVer,
KeyGen)
FCS_COP.1/SigGen
FCS_CKM.1/ND
A3693
Security Target for Junos OS 22.2R1 for MX Series with MX-SPC3 Juniper Networks, Inc.
Version 1.1 Page 41 of 67
HW
Module
Crypto
Module/
Library
Usage
FIPS PUB
Algorithm, Mode,
Keysize, Function,
Hashing, Usage
SFRs Supported
Certificate
Number
SP 800-56
A Rev. 3
KAS-SSC (Group 14,
19, 20, 21)
FCS_CKM.2 A3610
RE:
Control
Plane
OpenSSL All
daemons
SP 800-
90A
DRBG (HMAC-SHA-
2-256)
(Random Bit
Generation)
FCS_RBG_EXT.1 A3693
RE:
Control
Plane
OpenSSH SSH
daemon
SP 800-
135
CVL SSH v2 KDF
(SHA 1, SHA-256,
SHA-384)
(Key Derivation)
FCS_CKM.2 A3368
and
A3693
RE:
Control
Plane
Libmd - MGD
Daemon,
Password
Hashing
FIPS 180-4 SHS: SHA (1, 256)
Byte Oriented
(Message Digest
Generation)
FCS_COP.1/Hash A3367
FIPS 198-1 HMAC-SHA (256)
Byte Oriented
Message Digest
Generation)
FCS_COP.1/KeyedHash A3367
RE:
Control
Plane
Kernel Veriexec,
kernel
DRBG
SP800-
90A
DRBG (HMAC-SHA-
2-256)
(Random Bit
Generation)
FCS_RBG_EXT.1 A3354
FIPS 198-1 HMAC-SHA (1, 256)
Byte Oriented
(Message
Authentication,
DRBG Primitive)
FCS_COP.1/KeyedHash A3354
FIPS 180-4 SHS: SHA (1, 256)
Byte Oriented
(Message Digest
Generation)
FCS_COP.1/Hash A3354
Table 6 Cryptographic Services
88. Asymmetric keys are generated in accordance with NIST SP 800-56A and FIPS PUB 186-4 for IKE
with IPSec. The TOE complies with section 5.6 of NIST SP 800-56A regarding asymmetric key pair
generation. The TOE implements all of the "shall" and "should" requirements and none of the
"shall not" or "should not" from FIPS PUB 186-4 Appendix B3 and B4. (FCS_CKM.1/IKE)
89. Asymmetric keys are also generated in accordance with FIPS PUB 186-4 Appendix B.3 for RSA
Schemes and Appendix B.4 for ECC Schemes for SSH communications. The TOE implements
Diffie-Hellman group 14, using the modulus and generator specified by Section 3 of RFC3526.
(FCS_CKM.2, FCS_CKM.1/ND).
90. The following table relates cryptographic algorithms to the protocols by the TOE. The TOE acts as
both sender and recipient for IPsec and only as the server for SSH in the supported protocols
listed in Table 7.
Security Target for Junos OS 22.2R1 for MX Series with MX-SPC3 Juniper Networks, Inc.
Version 1.1 Page 42 of 67
Protocol Key Exchange Auth Cipher Integrity
IKEv1
Group 14 (modp 2048)
Group 15 (mod 3072)
Group 16 (mod 4096)
Group 19 (P-256)
Group 20 (P-384)
Group 21 (P-521)
Group 24 (modp 2048)
RSA 2048,
RSA 4096
ECDSA P-256
ECDSA P-384
Pre-Shared Key
AES CBC 128
AES CBC 192
AES CBC 256
AES GCM 128
AES GCM 256
SHA-256
SHA-384
SHA-512
IKEv2
Group 14 (modp 2048)
Group 15 (mod 3072)
Group 16 (mod 4096)
Group 19 (P-256)
Group 20 (P-384)
Group 21 (P-521)
Group 24 (modp 2048)
RSA 2048,
RSA 4096
ECDSA P-256
ECDSA P-384
Pre-Shared Key
AES CBC 128
AES CBC 192
AES CBC 256
AES GCM 128
AES GCM 256
HMAC-SHA-256
HMAC-SHA-384
HMAC-SHA-512
IPsec ESP
IKEv1 with optional:
Group 14 (modp 2048)
Group 15 (mod 3072)
Group 16 (mod 4096)
Group 19 (P-256)
Group 20 (P-384)
Group 21 (P-521)
Group 24 (modp 2048)
IKEv1 AES CBC 128
AES CBC 192
AES CBC 256
AES GCM 128
AES GCM 192
AES GCM 256
HMAC-SHA-256-128
IKEv2 with optional:
Group 14 (modp 2048)
Group 15 (mod 3072)
Group 16 (mod 4096)
Group 19 (P-256)
Group 20 (P-384)
Group 21 (P-521)
Group 24 (modp 2048)
IKEv2 AES CBC 128
AES CBC 192
AES CBC 256
AES GCM 128
AES GCM 192
AES GCM 256
HMAC-SHA-256-128
SSHv2
DH Group 14 (modp 2048)
ECDH-sha2-nistp256
ECDH-sha2-nistp384
ECDH-sha2-nistp521
ECDSA P-256
ECDSA P-384
ECDSA P-521
ssh_rsa
AES CTR 128
AES CTR 256
AES CBC 128
AES CBC 256
HMAC-SHA-1
HMAC-SHA-256
HMAC-SHA-512
Table 7 Supported Protocols.
91. The integrity algorithm HMAC-SHA-1 uses key length 160 bits, message size of 128 bits and
output size 96 bits. HMAC-SHA-256 uses key length 256 bits, message size of 128 bits bits and
output size 128 bits. HMAC-SHA-384 uses key length 384 bits, message size 128 bits and output
size 192 bits.
92. The TOE acts as both sender and recipient for IPsec and only as the server for SSH in the
supported protocols listed in Table 7. The TOE implements Diffie-Hellman group 14, using the
modulus and generator specified by Section 3 of RFC3526. (FCS_CKM.2)
93. Zeroization of the critical security parameters is handled as stated in Table 9 (FCS_CKM.4).
94. Junos OS does not provide a CLI interface to permit the viewing of keys. Cryptographic keys are
protected through the enforcement of kernel-level file access rights, limiting access to the
contents of cryptographic key containers to processes with cryptographic rights or shell users
Security Target for Junos OS 22.2R1 for MX Series with MX-SPC3 Juniper Networks, Inc.
Version 1.1 Page 43 of 67
with root permission25
. Encrypted or obfuscated passwords can be viewed by Security
Administrators using the CLI command ‘request system decrypt password’. (FPT_SKP_EXT.1)
7.1.2 Random Bit Generation
95. Junos OS performs random bit generation in accordance with NIST Special Publication 800-90
using HMAC_DRBG, SHA-256. The primary noise source of the RBG is based on timestamps
associated with software interrupts.
7.1.3 SSH
96. Junos OS supports and enforces Trusted Channels that protect the communications between the
TOE and a remote audit server from unauthorized disclosure or modification. It also supports
Trusted Paths between itself and remote administrators so that the contents of administrative
sessions are protected against unauthorized disclosure or modification. (FTP_ITC.1,
FTP_TRP.1/Admin)
97. Junos OS provides an SSH server to support Trusted Channels using SSHv2 protocol which
ensures the confidentiality and integrity of communication with the remote audit server. Export
of audit information to a secure, remote server is achieved by setting up an event trace monitor
that sends event log messages by using NETCONF over SSH to the remote system event logging
server. The remote audit server initiates the connection. The SSHv2 protocol ensures that the
data transmitted over a SSH session cannot be disclosed or altered by using the encryption and
integrity mechanisms of the protocol with the FIPS cryptographic module. (FTP_ITC.1,
FCS_SSHS_EXT.1)
98. The Junos OS SSH Server also supports Trusted Paths using SSHv2 protocol which ensures the
confidentiality and integrity of user sessions. The encrypted communication path between Junos
OS SSH Server and a remote administrator is provided by the use of an SSH session. Remote
administrators of Junos OS initiate communication to the Junos CLI through the SSH tunnel
created by the SSH session. Assured identification of Junos OS is guaranteed by using public key
based authentication for SSH. The SSHv2 protocol ensures that the data transmitted over a SSH
session cannot be disclosed or altered by using the encryption and integrity mechanisms of the
protocol with the FIPS cryptographic module. If desired, an additional layer of protection can be
afforded to the trusted path by using IPSec to encapsulate the SSH connection.
(FTP_TRP.1/Admin, FCS_SSHS_EXT.1)
99. The Junos OS SSH server is implemented in accordance with RFCs 4251, 4252, 4253, 4254, 5656
and 6668. Junos OS provides assured identification of the Junos OS appliance though public key
authentication and supports password-based authentication by administrative users (Security
Administrator) for SSH connections. The following table identifies conformance to the SSH
related RFCs:
25
Security Administrators do not have root permission in shell.
Security Target for Junos OS 22.2R1 for MX Series with MX-SPC3 Juniper Networks, Inc.
Version 1.1 Page 44 of 67
RFC Summary TOE implementation of Security
RFC 4251 The Secure Shell
(SSH) Protocol
Architecture
Host Keys: The TOE uses an ECDSA Host Key for SSH v2, with a
key size of 256 bits or greater, which is generated on initial
setup of the TOE. It can be de-configured via the CLI and the key
will be deleted and thus unavailable during connection
establishment. This key is randomly generated to be unique to
each TOE instance. The TOE presents the client with its public
key and the client matches this key against its known_hosts list
of keys. When a client connects to the TOE, the client will be
able to determine if the same host key was used in previous
connections, or if the key is different (per the SSHv2 protocol).
Junos OS also supports RSA-based key establishment schemes
with a key size of 2048 bits.
Policy Issues: The TOE implements all mandatory algorithms and
methods. The TOE can be configured to accept public-key based
authentication and/or password-based authentication. The TOE
does not require multiple authentication mechanisms for users.
The TOE allows port forwarding and sessions to clients. The TOE
has no X11 libraries or applications and X11 forwarding is
prohibited.
Confidentiality: The TOE does not accept the “none” cipher. It
supports AES-CBC-128, AES-CBC-256, AES-CTR-128, AES-CTR-256
encryption algorithms for protection of data over SSH and uses
keys generated in accordance with “ssh-rsa”, “ecdsa-sha2-
nistp256”, “ecdsa-sha2-nistp384” or “ecdsa-sha2-nistp521” to
perform public-key based device authentication. For ciphers
whose blocksize >= 16, the TOE rekeys every (2^32-1) bytes. The
client may explicitly request a rekeying event as a valid
SSHv2message at any time and the TOE will honor this request.
Re-keying of SSH session keys can be configured using the
sshd_config knob. The data-limit must be between 51200 and
4294967295 (2^32-1) bytes and the time-limit must be between
1 and 1440 minutes. In the evaluated deployment the time-limit
must be set within 1 and 60 minutes.
Denial of Service: When the SSH connection is brought down,
the TOE does not attempt to re-establish it.
Ordering of Key Exchange Methods: Key exchange is performed
only using one of the supported key exchange algorithms, which
are ordered as follows: ecdh-sha2-nistp256, ecdh-sha2-nistp384,
ecdh-sha2-nistp521 (all specified in RFC 5656), diffie-hellman-
group14-sha1 (specified in RFC 4253).
Debug Messages: The TOE sshd server does not support debug
messages via the CLI.
End Point Security: The TOE permits port forwarding.
Proxy Forwarding: The TOE permits proxy forwarding.
X11 Forwarding: The TOE does not support X11 forwarding.
Security Target for Junos OS 22.2R1 for MX Series with MX-SPC3 Juniper Networks, Inc.
Version 1.1 Page 45 of 67
RFC Summary TOE implementation of Security
RFC 4252 The Secure Shell
(SSH) Authentication
Protocol
Authentication Protocol: The TOE does not accept the “none”
authentication method. The TOE implements a timeout period
of 30seconds for authentication of the SSHv2 protocol and
provides a limit of three failed authentication attempts before
sending a disconnect to the client.
Authentication Requests: The TOE does not accept
authentication if the requested service does not exist. The TOE
does not allow authentication requests for a non-existent
username to succeed – it sends back a disconnect message as it
would for failed authentications and hence does not allow
enumeration of valid usernames. The TOE denies “none”
authentication method and replies with a list of permitted
authentication methods.
Public Key Authentication Method: The TOE supports public key
authentication for SSHv2 session authentication. The SSH client
authenticates the identity of the SSH server using a local
database associating each host name with its corresponding
public key. Authentication succeeds if the correct private key is
used. The TOE does not require multiple authentications (public
key and password) for users.
Password Authentication Method: The TOE supports password
authentication. Expired passwords are not supported and
cannot be used for authentication.
Host-Based Authentication: The TOE does not support the
configuration of host-based authentication methods.
RFC 4253 The Secure Shell
(SSH) Transport
Layer Protocol
Encryption: The TOE offers the following for encryption of SSH
sessions: aes128-cbc and aes256-cbc, aes128-ctr, aes256-ctr.
The TOE permits negotiation of encryption algorithms in each
direction. The TOE does not allow the “none” algorithm for
encryption.
Maximum Packet length: Packets greater than 256Kbytes in an
SSH transport connection are dropped and the connection is
terminated by Junos OS.
Data Integrity: The TOE permits negotiation of HMAC-SHA1 in
each direction for SSH transport.
Key Exchange: The TOE supports diffie-hellman-group14-sha1.
Key Re-Exchange: The TOE performs a re-exchange when
SSH_MSG_KEXINIT is received.
Security Target for Junos OS 22.2R1 for MX Series with MX-SPC3 Juniper Networks, Inc.
Version 1.1 Page 46 of 67
RFC Summary TOE implementation of Security
RFC 4254 Secure Shell (SSH)
Connection Protocol
Multiple channels: The TOE assigns each channel a number (as
detailed in RFC 4251, see above).
Data transfers: The TOE supports a maximum window size of
256K bytes for data transfer.
Interactive sessions: The TOE only supports interactive sessions
that do NOT involve X11 forwarding.
Forwarded X11 connections: This is not supported in the TOE.
Environment variable passing: The TOE only sets variables once
the server process has dropped privileges.
Starting shells/commands: The TOE supports starting one of
shell, application program or command (only one request per
channel). These will be run in the context of a channel, and will
not halt the execution of the protocol stack.
Window dimension change notices: The TOE will accept
notifications of changes to the terminal size (dimensions) from
the client.
Port forwarding: This is fully supported by the TOE.
RFC5656 SSH ECC Algorithm
Integration
ECDH Key Exchange: The support key exchange methods
specified in this RFC are ecdh-sha2-nistp256 or ecdh-sha2-
nistp384 and ecdh-sha2-nistp521. The client matches the key
against its known_hosts list of keys.
Hashing: Junos OS supports cryptographic hashing via the SHA-
256 algorithm, provided it has a message digest size of 256
bits.Required Curves: All required curves are implemented:
ecdh-sha2-nistp256, ecdh-sha2-nistp384 and ecdh-sha2-
nistp521. None of the Recommended Curves are supported as
they are not included in [CPP_ND].
RFC 6668 sha2-Transport Layer
Protocol
Data Integrity Algorithms: Both the recommended and optional
algorithm hmac-sha2-256 and hmac-sha2-512 are implemented
for SSH transport.
Table 8 SSH RFC conformance
100. Certificates are stored in non-volatile flash memory. Access to flash memory requires
administrator credentials. A certificate may be loaded via command line (FIA_X.509_EXT.1).
7.1.4 IPsec
101. The TOE is conformant to RFC 4301 (FCS_IPSEC_EXT.1.1) and supports IPsec in tunnel mode
(FCS_IPSEC_EXT.1.3). IPsec is used for VPN communications between the TOE and IPsec peers in
tunnel mode (FCS_ITC.1/VPN), to protect audit log data between the TOE and the audit server
(FTP_ITC.1). IPsec can also be used for tunnelling the SSH traffic in the establishment of a trusted
path for authenticating the Administrator of the TOE (FTP_TRP.1/Admin).
102. By default, the TOE denies all traffic through the MX devices. An implicit default security policy
exists that denies all packets. Source IP address and network mask
• Destination IP address and network mask
• Protocol
• Source port
• Destination port
• Action: permit, deny, drop silently, log
Security Target for Junos OS 22.2R1 for MX Series with MX-SPC3 Juniper Networks, Inc.
Version 1.1 Page 47 of 67
103. Each packet is compared against entries in the security policy ruleset in sequential order until
one is found that matches the specification in the policy, or until the end of the rule set is
reached, in which case the implicit default policy is implemented, and the packet is discarded.
(FCS_IPSEC_EXT.1.2, supported by FPF_RUL_EXT.1.1, FPF_RUL_EXT.1.3, FPF_RUL_EXT.1.4,
FPF_RUL_EXT.1.6, FPF_RUL_EXT.1.7)
104. The TOE supports AES-GCM-128, AES-GCM-192 and AES-GCM-256, and AES-CBC-128, AES-CBC-
192 or AES-CBC-256 using HMAC SHA-256 for ESP protection. (FCS_IPSEC_EXT.1.4)
105. IKEv1 and IKEv2 are implemented. IKEv1 as defined in RFCs 2407, 2408, 2409, RFC 4109 and RFC
4868 for hash functions; IKEv2 as defined in RFCs 5996 (with no support for NAT traversal) and
RFC 4868 for hash functions. IKEv1 aggressive mode is not supported. (FCS_IPSEC_EXT.1.5)
106. The TOE supports AES-CBC-128, AES-CBC-192, AES-CBC-256, AES-GCM-128 and AES-GCM-256 for
payload protection in IKEv1 and IKEv2. (FCS_IPSEC_EXT.1.6)
107. In the evaluated configuration, the TOE permits configuration of the IKE and IPsec lifetime
exchanges for customer VPN tunnels in terms of length of time (180 to 86400 seconds)
(FCS_IPSEC_EXT.1.7) or (180 to 28800 seconds) FCS_IPSEC_EXT.1.8)
108. The following CLI command configure the lifetime: (FCS_IPSEC_EXT.1.7, FCS_IPSEC_EXT.1.8)
set security ipsec proposal <name> lifetime-seconds <seconds>
109. The TOE supports Diffie-Hellman Groups 14, 19, 20 and 24. In the IKEv1 phase 1 and phase 2
exchanges, the TOE and peer will agree on the best DH group both can support. When the TOE
receives an IKE proposal, it will select the first DH group that matches the acceptable DH groups
configured in the TOE (one or more of DH Groups 14, 19, 20 or 24) and the negotiation will fail if
there is no match. Similarly, when the peer initiates the IKE protocol, the TOE will select the first
match from the IKE proposal sent by the peer and the negotiation fails if no acceptable match is
found. (FCS_IPSEC_EXT.1.11)
110. The TOE uses HMAC DRBG with SHA-256 for the generation of DH exponents and nonces in the
IKE key exchange protocol of length 224 bits (for DH Group 14), 256 bits (for DH Groups 19 and
24) and 384 bits (for DH Group 20). (FCS_IPSEC_EXT.1.9, FCS_IPSEC_EXT.1.10)
111. The TOE supports both RSA and ECDSA for use with X.509v3 certificates that conform to RFC
4945 and pre-shared Keys for IPsec support. (FCS_IPSEC_EXT.1.13)
112. The TOE ensures that the strength of the symmetric algorithm (128, 192 or 256 bits) negotiated
to protect the IKEv1 Phase 1, IKEv2 IKE_SA connection is greater than or equal to the strength of
the symmetric algorithm negotiated to protect the IKEv1 Phase 2, IKEv2 CHILD_SA connection.
(FCS_IPSEC_EXT.1.12)
113. The TOE uses pre-shared keys for IPSec. The TOE accepts ASCII pre-shared or bit-based keys of 1
to 255 characters (and their binary equivalent) that may contain upper and lower case letters,
numbers, and special characters (that include: “!”, “@”, “#”, “$”, “%”, “^”, “&”, “*”, “(“, and “)”.
The TOE accepts pre-shared text keys and converts the text string into an authentication value as
per RFC 2409 for IKEv1 or RFC 4306 for IKEv2, using the PRF that is configured as the hash
algorithm for the IKE exchanges. (FIA_PSK_EXT.1).
114. The TOE uses X.509 certificates as defined in RFC 5280.
115. To generate a Certificate Request, the administrator uses the CLI command
request security pki generate-certificate-request
116. and supplies the following values:
• Certificate-id – The internal identifier string for this certificate
Security Target for Junos OS 22.2R1 for MX Series with MX-SPC3 Juniper Networks, Inc.
Version 1.1 Page 48 of 67
• Domain-name
• Email address
• IP address
• Subject (DC=<Domain component>,CN=<Common-Name>,OU=<Organizational-Unit-
name>,O=<Organization-name>,SN=<Serial-
Number>,L=<Locality>,ST=<state>,C=<Country>)
• Filename – The local file in which to store the certificate signing request
(FIA_X509_EXT.3)
117. To validate certificates, the TOE extracts the subject, issuer, subjects public key, signature,
basicConstraints and validity period fields. If any of those fields is not present, the validation
fails. The issuer is looked up in the PKI database. If the issuer is not present, or if the issuer
certificate does not have the CA:true flag in the basicConstraints section, the validation fails. The
TOE verifies the validity of the signature. If the signature is not valid, the validation fails. It then
confirms that the current date and time is within the valid time period specified in the
certificate. The TOE also extracts the extendedKeyUsage field and verifies the value represents
that for the Code Signing purpose (id-kp 3 with OID 1.3.6.1.5.5.7.3.3).
118. If the TOE is configured to perform a revocation check using CRL (as specified in RFC 5280
Section 6.3) and the CRL fails to download, there are two possible outcomes: If the TOE is
configured with the option to skip CRL checking on download failure enabled, then the
certificate shall be considered as having passed the validation. If the TOE is configured with the
option to skip CRL checking on download failure disabled, then the certificate is considered to
have failed validation.
119. The TOE validates a certificate path by building a chain of (at least 3) certificates based upon
issuer and subject linkage, validating each according the certificate validation procedure
described above. If any certificate in the chain fails validation, the validation fails as a whole. A
self-signed certificate is not required to be at the root of the certificate chain.
120. The TOE determines if a certificate is a CA certificate by requiring the CA:true flag to be present
in the basicConstraints section. (FIA_X509_EXT.1.1/Rev)
121. The TOE requires that the configured IKE identity of the local and remote endpoints to match
the contents of the certificate associated with a SA endpoint. The TOE permits the identity to be
expressed as distinguished name, fully qualified domain name (FQDN), user FQDN or IP address.
If either certificate does not validate, or the contents do not match the configured identity, then
the SA will not be established.
122. The PKI daemon on an MX Series device validates all X509 certificates received from VPN peers
during the IKE negotiation. If the TSF cannot establish a connection to determine the validity of a
certificate, the SA will not be established unless the administrator of the TOE has explicitly
configured the TOE to disable the CRL check in case the connection can not be established.
(FIA_X509_EXT.1/Rev, FIA_X509_EXT.2, FIA_PSK_EXT.1, FIA_X509_EXT.3)
123. For public key-based authentication of IPsec connections, Junos OS validates the X.509
certificates by extracting the subject, issuer, signature, basicConstraints and validity period
fields. If any of those fields is not present, the validation fails. The issuer is looked up in the PKI
database. If the issuer CA is not present, or if the issuer certificate does not have the CA:true flag
in the basicConstraints section, the validation fails. Junos OS verifies the validity of the signature.
If the signature is not valid, the validation fails. It then confirms that the current date and time is
within the valid time period specified in the certificate. (FIA_X509_EXT.1/Rev, FIA_X509_EXT.2
Security Target for Junos OS 22.2R1 for MX Series with MX-SPC3 Juniper Networks, Inc.
Version 1.1 Page 49 of 67
124. Junos OS generates Certificate Request Messages as specified in RFC 2986 when validating
certificates for IPsec connections. Device-specific information, Common Name, Organization,
Organizational Unit, Country and public key details are provided in the CSR. Junos OS validates
the chain of certificates from the Root CA when the CA Certificate Response is received.
(FIA_X509_EXT.3).
7.2 Administrator Authentication
125. Junos OS enforces binding between human users and subjects. The Security Administrator26
is
responsible for provisioning user accounts, and only the Security Administrator can do so.
(FMT_SMR.2)
126. Junos users are configured under “system login user” and are exported to the password
database ‘/var/etc/master.passwd’. A Junos user is therefore an entry in the password database.
Each entry in the password database has fields corresponding to the attributes of “system login
user”, including username, (obfuscated) password and login class.
127. The internal architecture supporting Authentication includes an active process, associated linked
libraries and supporting configuration data. The Authentication process and library are
• login
• PAM Library module
128. Following TOE initialization, the login process is listening for a connection at the local console.
This ‘login’ process can be accessed through either direct connection to the local console or
following successful establishment of a remote management connection over SSH, when a login
prompt is displayed.
129. This login process identifies and authenticates the user using PAM operations. The login process
does two things; it first establishes that the requesting user is whom they claim to be and second
provides them with an interactive Junos Command interactive command line interface (CLI).
130. The SSH daemon supports public key authentication by looking up a public key in an authorized
keys file located in the directory ‘.ssh’ in the user’s home directory (i.e. ‘~/.ssh/’) and this
authentication method will be attempted before any other if the client has a key available
(FIA_UIA_EXT.1). The SSH daemon will ignore the authorized keys file if it or the directory ‘.ssh’
or the user’s home directory are not owned by the user or are writeable by anyone else.
131. For password authentication, login interacts with a user to request a username and password to
establish and verify the user’s identity. The username entered by the administrator at the
username prompt is reflected to the screen, but no feedback to screen is provided while the
entry made by the administrator at the password prompt until the Enter key is pressed
(FIA_UAU.7). Login uses PAM Library calls for the actual verification of this data. The password is
hashed and compared to the stored value, and success/failure is indicated to login,
(FIA_UIA_EXT.1). PAM is used in the TOE support authentication management, account
management, session management and password management. Login primarily uses the session
management and password management functionality offered by PAM.
132. The retry-options can be configured to specify the action to be taken if the administrator fails to
enter valid username/password credentials for password authentication when attempting to
authenticate via remote access. The retry-options are applied following the first failed login
attempt for a given username (FIA_AFL.1). The length of delay (5-10 seconds) after each failed
attempt is specified by the backoff-factor, and the increase of the delay for each subsequent
failed attempt is specified by the backoff-threshold (1-3). The tries-before-disconnect sets the
maximum number of times (1-10) the administrator is allowed to enter a password to attempt
26
The Security Administrator role is detailed in Sec. 7.6
Security Target for Junos OS 22.2R1 for MX Series with MX-SPC3 Juniper Networks, Inc.
Version 1.1 Page 50 of 67
to log in to the device through SSH before the connection is disconnected. The lockout-period
sets the amount of time in minutes before the administrator can attempt to log in to the device
after being locked out due to the number of failed login attempts (1-43,200 minutes). It is also
possible for another administrator to “unlock” the account of administrator whose account has
been locked for a period of time following failed authentication attempts. Even when an account
is blocked for remote access to the TOE, an administrator is always able to login locally through
the serial console and the administrator can attempt authentication via remote access after the
maximum timeout period of 24 hours.
133. The TOE requires users to provide unique identification and authentication data
(passwords/public key) before any access to the system is granted. Prior to authentication, the
only Junos OS managed responses provided to the administrator are (FIA_UAU_EXT.2):
• Negotiation of SSH session
• Display of the access banner
• ICMP echo responses.
134. Authentication data for fixed password authentication is a case-sensitive, alphanumeric value.
The password has a minimum length of 10 characters and maximum length of 20 characters, and
must contain characters from at least two different character sets (upper, lower, numeric,
punctuation), and can be up to 20 ASCII characters in length (control characters are not
recommended). Any standard ASCII, extended ASCII and Unicode characters can be selected
when choosing a password. (FIA_PMG_EXT.1)
135. Locally stored authentication credentials are protected (FPT_APW_EXT.1):
• The passwords are stored in obfuscated form using HMAC-SHA1.
• Authentication data for public key-based authentication methods are stored in a directory
owned by the user (and typically with the same name as the user). This directory contains
the files ‘.ssh/authorized_keys’ and ‘.ssh/authorized_keys2’ which are used for SSH public
key authentication.
136. Junos enables Security Administrators to configure an access banner provided with the
authentication prompt. The banner can provide warnings against unauthorized access to the
TOE as well as any other information that the Security Administrator wishes to communicate.
(FTA_TAB.1)
137. User sessions (local and remote) can be terminated by users (FTA_SSL.4). The administrative
user can logout of the existing session by typing exit to exit the CLI admin session and the Junos
OS makes the current contents unreadable after the admin initiates the termination. No user
activity can take place until the user re-identifies and authenticates.
138. The Security Administrator can set the TOE so that a user session is terminated after a period of
inactivity. (FTA_SSL_EXT.1, FTA_SSL.3) For each user session Junos OS maintains a count of clock
cycles (provided by the system clock) since last activity. The count is reset each time there is
activity related to the user session. When the counter reaches the number of clock cycles
equating to the configured period of inactivity the user session is locked out.
139. Junos OS overwrites the display device and makes the current contents unreadable after the
local interactive session is terminated due to inactivity, thus disabling any further interaction
with the TOE. This mechanism is the inactivity timer for administrative sessions. The Security
Administrator can configure this inactivity timer on administrative sessions after which the
session will be logged out.
Security Target for Junos OS 22.2R1 for MX Series with MX-SPC3 Juniper Networks, Inc.
Version 1.1 Page 51 of 67
7.3 Correct Operation
140. Junos OS runs the following set of self-tests during power on to check the correct operation of
the Junos OS firmware (FPT_TST_EXT.1):
• Power on test – determines the boot-device responds, and performs a memory size check to
confirm the amount of available memory.
• File integrity test –verifies integrity of all mounted signed packages, to assert that system
files have not been tampered with. To test the integrity of the firmware, the fingerprints of
the executables and other immutable files are regenerated and validated against the SHA1
fingerprints contains in the manifest file.
• Crypto integrity test – checks integrity of major CSPs, such as SSH hostkeys and iked
credentials, such as Cas, CERTS, and various keys.
• Authentication error – verifies that veriexec is enabled and operates as expected using
/opt/sbin/kats/cannot-exec.real.
• Kernel, libmd, OpenSSL, QuickSec, SSH, QAT MX-SPC3 – verifies correct output from known
answer tests for appropriate algorithms.
141. Juniper Networks devices run only binaries supplied by Juniper Networks. Within the package,
each Junos OS firmware image includes fingerprints of the executables and other immutable
files. Junos firmware will not execute any binary without validating a fingerprint. This feature
protects the system against unauthorized firmware and activity that might compromise the
integrity of the device. These self-tests ensure that only authorized executables are allowed to
run thus ensuring the correct operation of the TOE.
142. In the event of a transiently corrupt state or failure condition, the system will panic; the event
will be logged and the system restarted, having ceased to process network traffic. When the
system restarts, the system boot process does not succeed without passing all applicable self-
tests. This automatic recovery and self-test behavior, is discussed in Chapter 11 of [ECG].
143. When any self-test fails, the device halts in an error state. No command line input or traffic to
any interface is processed. The device must be power cycled to attempt to return to operation.
This self-test behavior, is discussed in [ECG]. (FPT_FLS.1, FPT_TST_EXT.1, FPT_TST_EXT.3)
7.4 Trusted Update
144. Security Administrators are able to query the current version of the TOE firmware using the CLI
command “show version”(FPT_TUD_EXT.1) and, if a new version of the TOE firmware is
available, initiate an update of the TOE firmware. Junos OS does not provide partial updates for
the TOE, customers requiring updates must migrate to a subsequent release. Updates are
downloaded and applied manually (there is no automatic updating of the Junos OS).
(FPT_TUD_EXT.1, FMT_SMF.1/ND, FMT_MOF.1/ManualUpdate,)
145. The installable firmware package includes the full Junos OS firmware. No partial updates are
supported. The installable software packages have a digital signature that is checked when the
Security Administrator attempts to install the package. The signature of the complete package is
verified at the beginning of the installation process before the package is expanded. If signature
verification fails, an error message is displayed and the package is not installed.
146. The Junos OS kernel maintains a set of fingerprints (SHA1 digests) for executable files and other
files which should be immutable, as described in Section 7.3. The manifest file is signed using the
Juniper package signing key and is verified by the TOE using the public key (stored on the TOE
filesystem in clear, protected by filesystem access rights). ECDSA (P-256) with SHA-256 is used
for digital signature package verification.
Security Target for Junos OS 22.2R1 for MX Series with MX-SPC3 Juniper Networks, Inc.
Version 1.1 Page 52 of 67
147. The fingerprint loader will only process a manifest for which it can verify the signature. Without
a valid digital signature an executable cannot be run. When the command is issued to install an
update, the manifest file for the update is verified and stored, and each executable/immutable
file is verified before it is executed. If any of the fingerprints in an update are not correctly
verified, the TOE uses the last known verified image.
148. A certificate may be loaded via command line and is stored in SSD. Access to flash memory
requires administrator credentials. Control on access to the trust store holding the X509v3
certificates can be controlled using standard Junos permissions settings. Each top-level CLI
command and each configuration statement have an access privilege level associated with them
and users can execute only those commands and configure and view only those statements for
which they have access privileges. The access privileges for each login class are defined by one or
more permission flags. For each login class, the use of operational and configuration mode
commands that would otherwise be permitted or not allowed by a privilege level specified in the
permissions statement can be explicitly denied or allowed. Cryptographic keys are protected
through the enforcement of kernel-level file access rights, limiting access to the contents of
cryptographic key containers to processes with cryptographic rights. The TOE does not provide a
CLI interface to permit the viewing of keys. Passwords used for authentication can be viewed by
Security Administrators using the CLI command ‘request system decrypt password’
(FIA_X.509_EXT.1/Rev, FMT_MTD.1/CoreData).
149. Junos OS verifies the validity of the signature. If the signature is not valid, the validation fails. If
the signature is valid the update process proceeds. (FCS_COP.1/SigGen, FPT_TUD_EXT.1,)
7.5 Audit
150. Junos OS creates and stores audit records for the following events (the detail of content
recorded for each audit event is detailed in Table 4 (FAU_GEN.1/ND). Auditing is implemented
using syslog.
• Start-up and shut-down of the audit functions
• Administrative login and logout
• Configuration is committed
• Configuration is changed (includes all management activities of TSF data)
• Generating/import of, changing, or deleting of cryptographic keys (see below for more
detail)
• Resetting passwords
• Starting and stopping services
• All use of the identification and authentication mechanisms
• Unsuccessful login attempts limit is met or exceeded
• Any attempt to initiate a manual update
• Result of the update attempt (success or failure)
• The termination of a local/remote/interactive session by the session locking mechanism
• Initiation/termination/failure of the SSH trusted channel to syslog server
• Initiation/termination/failure of the SSH trusted path with Admin
• Initiation/termination/failure of an IPsec trusted channel, including Session
Establishment with peer
Security Target for Junos OS 22.2R1 for MX Series with MX-SPC3 Juniper Networks, Inc.
Version 1.1 Page 53 of 67
• Session establishment with CA
• Application of rules configured with the ‘log’ operation by the packet filtering function
• Indication of packets dropped due to too much network traffic by the packet filtering
function
151. In addition the following management activities of TSF data are recorded:
• configure the access banner;
• configure the session inactivity time before session termination;
• configure the authentication failure parameters for FIA_AFL.1;
• Ability to configure audit behaviour;
• configure the cryptographic functionality;
• configure thresholds for SSH rekeying;
• re-enable an Administrator account;
• set the time which is used for time-stamps.
152. The detail of what events are to be recorded by syslog are determined by the logging level
specified the “level” argument of the “set system syslog” CLI command. To ensure
compliance with the requirements the audit knobs detailed in [ECG] must be configured.
153. As a minimum, Junos OS records the following with each log entry:
• date and time of the event and/or reaction
• type of event and/or reaction
• subject identity (where applicable)
• the outcome (success or failure) of the event (where applicable).
154. In order to identify the key being operated on, the following details are recorded for all
administrative actions relating to cryptographic keys (generating, importing, changing and
deleting keys):
• PKID – certificate id will be recorded when generating or deleting a key pair
• IKE SPI – IP address of the initiator and responder recorded, together with the SPI, will be
recorded when generating a key pair. The IP address of the initiator and responder will
provide the unique link to the key identifier (SPI) of the key that has been destroyed in the
session termination
• SSH session keys– key reference provided by process id
• SSH keys created for outbound trusted channel to external syslog server
• SSH keys imported for outbound trusted channel to external syslog server
• SSH key configured for SSH public key authentication –the hash of the public key that is to be
used for authentication is recorded in syslog
155. For SSH (ephemeral) session keys the PID is used as the key reference to relate the key
generation and key destruction audit events. The key destruction event is recorded as a session
disconnect event. For example, key generation and key destruction events for a single SSH
session key would be reflected by records similar to the following:
Security Target for Junos OS 22.2R1 for MX Series with MX-SPC3 Juniper Networks, Inc.
Version 1.1 Page 54 of 67
156. Sep 27 15:09:36 yeti sshd[6529]: Accepted publickey for root from 10.163.18.165 port 45336
ssh2: RSA SHA256:l1vri77TPQ4VaupE2NMYiUXPnGkqBWIgD5vW0OuglGI
157. Sep 27 15:09:40 yeti sshd[6529]: Received disconnect from 10.163.18.165 port 45336:11:
disconnected by user
158. Sep 27 15:09:40 yeti sshd[6529]: Disconnected from 10.163.18.165 port 45336
159. SSH keys generated for outbound trusted channels are uniquely identified in the audit record by
the public key filename and fingerprint. For example:
160. Sep 27 23:36:49 yeti ssh-keygen [67873]: Generated SSH key file /root/.ssh/id_rsa.pub with
fingerprint SHA256:g+7lsR7x4lQb1JT8Q3scfb2sOl8lyccojGdmkmw4dwM
161. SSH keys imported for use in establishing outbound trusted channels are uniquely identified in
the audit record by the hash of the key imported and the username importing (to which the key
will be bound).
162. It should be noted that SSH keys used for trusted channels are NOT deleted by mgd when SSH is
de-configured. Hence, the only time SSH keys used for trusted channels are deleted is when a
“request vmhost zeroize” action is performed and the whole appliance is zeroized (which by
definition cannot be recorded)
163. All events recorded by syslog are timestamped. The clock function of Junos OS provides a source
of date and time information for the appliance, used in audit timestamps, which is maintained
using the hardware Time Stamp Counter as the clock source. (FAU_GEN.2, FPT_STM_EXT.1)
164. Syslog can be configured to store the audit logs locally (FAU_STG_EXT.1), and optionally to send
them to one or more syslog log servers via Netconf over SSH (FAU_STG.1,
FMT_MOF.1/Functions). Local audit log are stored in /var/log/ in the underlying filesystem. Only
a Security Administrator can read log files, or delete log and archive files through the CLI
interface or through direct access to the filesystem having first authenticated as a Security
Administrator. The syslogs are automatically deleted locally according to configurable limits on
storage volume. The default maximum size is 1Gb. The default maximum size can be modified by
the user, using the “size” argument for the “set system syslog” CLI command.
165. The Junos OS defines an active log file and a number of “archive” files (10 by default, but
configurable from 1 to 1000). When the active log file reaches its maximum size, the logging
utility closes the file, compresses it, and names the compressed archive file ‘logfile.0.gz’. The
logging utility then opens and writes to a new active log file. When the new active log file
reaches the configured maximum size, ‘logfile.0.gz’ is renamed ‘logfile.1.gz’, and the active log
file is closed, compressed, and renamed ‘logfile.0.gz’. When the maximum number of archive
files is reached and when the size of the active file reaches the configured maximum size, the
contents of the oldest archived file are deleted so the current active file can be archived.
166. A 1Gb syslog file takes approximately 0.25Gb of storage when archived. Syslog files can acquire
complete storage allocated to /var filesystem, which is platform specific. However, when the
filesystem reaches 92% storage capacity an event is raised to the administrator but the eventd
process (being a privileged process) still can continue using the reserved storage blocks. This
allows the syslog to continue storing events while the administrator frees the storage. If the
administrator does not free the storage in time and the /var filesystem storage becomes
exhausted a final entry is recorded in the log reporting “No space left on device” and logging is
terminated. The appliance continues to operate in the event of exhaustion of audit log storage
space.
Security Target for Junos OS 22.2R1 for MX Series with MX-SPC3 Juniper Networks, Inc.
Version 1.1 Page 55 of 67
7.6 Management
167. Accounts assigned to the Security Administrator role are used to manage Junos OS in accordance
with [CPP_ND]. 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 Junos OS in accordance
with the requirements of [CPP_ND].(FMT_SMR.2)
168. The TOE provides user access either through the system console or remotely over the Trusted
Path using the SSHv2 protocol. Users are required to provide unique identification and
authentication data before any access to the system is granted, as detailed in Section 7.2 above.
(FMT_SMR.2, FMT_SMF.1/ND)
169. The Security Administrator has the capability to:
• Administer the TOE locally via the serial ports on the physical device or remotely over an SSH
connection.
• Initiate a manual update of TOE firmware (FMT_MOF.1/ManualUpdate):
o Query currently executing version of TOE firmware (FPT_TUD_EXT.1)
o Verify update using digital signature (FPT_TUD_EXT.1)
• Manage Functions:
o Transmission of audit data to an external IT entity, including Start/stop and modify
the behaviour of the trusted communication channel to external syslog server
(netconf over SSH) and the trusted path for remote Administrative sessions (SSH)
(FMT_MOF.1/Functions, FMT_MOF.1/Services, FMT_SMF.1/ND)
o Configuring the packet filtering tules of the TOE (FMT_SMF.1/VPN)
o Handling of audit data, including setting limits of log file size
(FMT_MOF.1/Functions)
• Manage TSF data (FMT_MTD,1/CoreData)
o Create, modify, delete administrator accounts, including configuration of
authentication failure parameters
o Reset administrator passwords
o Re-enable an Administrator account (FIA_AFL.1);
• Manage crypto keys for IPSec as used in tunnel mode for implementing the VPN as described
in Sect. 7.1.4. The Critical Security Parameters and the cryptographic keys used by the TOE
are detailed in Table 9 and Table 10. (FMT_MTD.1/CryptoKeys)
Table 9 Critical Security Parameters
Name Generation Import/
Export
Establishment Storage Zeroisation Use & related keys
HMAC
DRBG V
value
Internal to the HMAC
DRBG by calling the
HMAC_DRBG_Updat
e fuction using the
seed
(entropy||nonce||pe
rsonalization), and
current V value
(initially a constant)
Not entered
or output
from module
No SSP
establishm
ent
method
involved
Plaintext:
RAM
Power
cycle
The value V of outlen bits, which is
updated each time another outlen
bits of output are produced
A critical value of the internal
state of DRBG
Security Target for Junos OS 22.2R1 for MX Series with MX-SPC3 Juniper Networks, Inc.
Version 1.1 Page 56 of 67
HMAC
DRBG
Key
value
Internal to the HMAC
DRBG by calling the
HMAC_DRBG_Updat
e fuction using the
seed
(entropy||nonce||pe
rsonalization), and
current Key value
(initially a constant)
Not entered
or output
from module
No SSP
establishm
ent
method
involved
Plaintext:
RAM
Power
cycle
The current value of key. The
outlen-bit Key, which is updated at
least once each time that the
DRBG mechanism generates
pseudorandom bits.
A critical value of the internal
state of DRBG
HMAC
DRBG
Entropy
Input
Kernel HMAC DRBG
(for user-land
instances), Entropy
sources (for kernel
instance)
Not entered
or output
from module
No SSP
establishm
ent
method
involved
Plaintext:
RAM
Power
cycle
A critical value of the internal
state of DRBG
HMAC
DRBG
Seed
Internally using the
seed(entropy||nonce
||personalization)
Not entered
or output
from module
No SSP
establishm
ent
method
involved
Plaintext:
RAM
Power
cycle
Seed material used to seed or
reseed the HMAC DRBG
DH
Shared
Secret
Internally as part of
DH key exchange
Not entered
or output
from module
SP800-
56Arev3
compliant
KAS
DH groups
for IKE: 14,
15,16, 19,
20, 21 and
24.
DH groups
for SSH:
groups 14,
19, 20, 21
Plaintext:
RAM
Power
cycle or
explicit
delete
command
Shared DH value computed from
the ephemeral DH key-pairs as
part of IKE and SSH and used to
derive session keys.
SSH PHK SSH-KeyGen tool
(Uses OpenSSL
EC_KEY_generate_ke
y and
rsa_builtin_keygen
API)
Random Number
generation Alg:
HMAC DRBG, SP800-
133Rev2, Section 5.2.
Not entered
or output
from module
No SSP
establishm
ent
method
involved
Plaintext:
Persistent
Zeroize
Command
SSH-2 Private Host Key: 1st time
SSH is configured the ECDSA
NID_X9_62_prime256v1 (NIST
Curve P-256) and RSA 2048 host
keys are generated.
Used to Identify the host.
SSH DH Internally generated
using HMAC DRBG
(part of DH
exchange), SP800-
133Rev2, Section 5.2.
Not entered
or output
from module
SP800-
56Arev3
compliant
KAS
DH groups
14, 19,20
and 21
Plaintext:
RAM
Power
cycle or
explicit
delete
command
SSH Diffie-Hellman private
component. Ephemeral Diffie-
Hellman private key used in SSH
DH groups 14, 19,20 and 21
SSH-
SEKs
During the SSH
handshake.
Encryption/Macs:
SSHv2 KDF
Key Exchange
Random Number
generation Alg:
HMAC DRBG, SP800-
133Rev2, Section 5.2.
Not entered
or output
from module
SP800-
56Arev3
compliant
KAS
Plaintext:
RAM
Power
cycle or
explicit
delete
command
Session keys used with SSH-2.
Encryption: AES 128, 192, 256,
MACs: HMAC SHA-2-256, HMAC-
SHA1, HMAC SHA2-512
Key Exchange:
DH (L=20148, N=2047)
ECDH NIST Curve P-256, NIST
Curve P-384, NIST Curve P-521
IKE-PSK N/A Input
Plaintext or
Encrypted:
No SSP
establishm
ent
Plaintext:
RAM
Zeroize;
explicit
delete
Pre-Shared Key used to
authenticate IKE connections.
Security Target for Junos OS 22.2R1 for MX Series with MX-SPC3 Juniper Networks, Inc.
Version 1.1 Page 57 of 67
Entered via
SSH or
console
Output:
Encrypted
method
involved
command
IKE-Priv Generated externally
to the module
Input:
Plaintext or
Encrypted
.
No SSP
establishm
ent
method
involved
Plaintext: RAM Zeroize;
explicit
delete
command
IKE Private Key. RSA 2048, RSA
4096 ECDSA P-256, ECDSA P-521
or ECDSA P-384
IKE-
SKEYID
Established using
DH/ECDH.
NA-Not
entered or
output from
module
SP800-
56Arev3
compliant
KAS
Plaintext:
RAM
Power cycle or
explicit delete
command
IKE SKEYID. IKE secret used to
derive IKE and IPsec ESP session
keys.
IKE-SEKs IKE KDF Not entered
or output
from module
No SSP
establishm
ent method
involved
Plaintext:
RAM
Power cycle or
explicit delete
command
IKE Session Keys: IKE Session
Encryption Key: AES; IKE Session
Integrity Key: HMAC
ESP-SEKs IKE KDF Not entered
or output
from module
No SSP
establishm
ent
method
involved
Plaintext:
RAM
Power
cycle or
explicit
delete
command
IPSec ESP Session Keys: IKE Session
Encryption Key: AES; IKE Session
Integrity Key: HMAC
IKE-DH-
PRI
Internally using
HMAC DRBG, SP800-
133Rev2, Sect. 5.2.
Not entered
or output
from module
SP800-
56Arev3
compliant
KAS
DH groups
for IKE: 14,
15,16, 19,
20, 21 and
24.
Plaintext:
RAM
Power cycle or
explicit delete
command
IKE Diffie-Hellman private
component. Ephemeral Diffie-
Hellman private key used in IKE
HA-IKE-
PSK
N/A Input
Plaintext or
Encrypted:
Entered via
SSH or
console
Output:
Encrypted
No SSP
establishm
ent
method
involved
Plaintext:
RAM
Zeroize
and
explicit
delete
command
Pre-Shared Key used to
authenticate IKE connection for
the HA Link.
HA-IKE-
Priv
Generated externally
to the module
Input:
Plaintext or
Encrypted
.
No SSP
establishm
ent
method
involved
Plaintext:
RAM
Zeroize
and
explicit
delete
command
IKE Private Key. RSA 2048, RSA
4096 ECDSA P-256, ECDSA P-521
or ECDSA P-384 for HA Link Traffic
HA-IKE-
SKEYID
Established using
DH/ECDH.
Not entered
or output
from module
SP800-
56Arev3
compliant
KAS
Plaintext:
RAM
Power
cycle or
explicit
delete
command
IKE SKEYID. IKE secret used to
derive IKE and IPsec ESP session
keys for HA Link traffic.
HA-IKE-
SEKs
IKE KDF Not entered
or output
from module
No SSP
establishm
ent
method
involved
Plaintext:
RAM
Power
cycle or
explicit
delete
command
IKE Session Keys for HA Link: IKE
Session Encryption Key: AES; IKE
Session Integrity Key: HMAC
HA-ESP-
SEKs
IKE KDF Not entered
or output
from module
No SSP
establishm
ent
method
involved
Plaintext:
RAM
Power
cycle or
explicit
delete
command
IPSec ESP Session Keys for HA Link:
IKE Session Encryption Key: AES;
IKE Session Integrity Key: HMAC
HA-IKE-
DH-PRI
Internally using
HMAC DRBG, SP800-
Not entered
or output
SP800-
56Arev3
Plaintext:
RAM
Power
cycle or
IKE Diffie-Hellman private
component. Ephemeral Diffie-
Security Target for Junos OS 22.2R1 for MX Series with MX-SPC3 Juniper Networks, Inc.
Version 1.1 Page 58 of 67
Table 10 Cryptographic parameters
Name Generation Import/
Export
Establishment Storage Zeroisation Use & related keys
SSH-PUB SSH-KeyGen tool
(Uses OpenSSL
EC_KEY_generate_k
ey and
rsa_builtin_keygen
API)
Random Number
generation Alg:
HMAC DRBG
Entry: N/A
Output:
Plaintext
during SSH
session
establishmen
t
N/A Plaintext:
Persistent
Zeroize
Command
SSH-2 Public Host Key:
1st time SSH-2 is configured the ECDSA
and RSA keys are generated.
Used to Identify the host.
Auth-
User Pub
Externally generated Entry:
Manual
entry
N/A Plaintext:
Persistent
Zeroize
Command
User Authentication Public Keys:
ECDSA and RSA public keys
Used to authenticate users to the
module.
Auth-CO
Pub
Externally generated Entry:
Manual
N/A Plaintext:
Persistent
Zeroize
Command
CO Authentication Public Keys:
Used to authenticate users to the
module. ECDSA P256, P-384
Root-CA Externally generated Loaded at
manufacture
time.
N/A Persistent Zeroize
Command
JuniperRootCA:
ECDSA prime256v1 X.509 V3 or
prime384v1 X.509 V3 Certificate
Used to verify the validity of the
PackagCA.
Package-
CA
Externally generated Loaded at
manufacture
time.
N/A Plaintext:
Persistent
Zeroize
Command
ECDSA prime256v1 X.509 V3
Certificate
133Rev2, Section 5.2. from module compliant
KAS
DH groups
for IKE: 14,
15,16, 19,
20, 21 and
24.
explicit
delete
command
Hellman private key used in IKE for
HA Link
HMAC
key
Internally using
HMAC DRBG, SP800-
133Rev2, Section 6.1.
Not entered
or output
from module
No SSP
establishm
ent
method
involved
Plaintext:
RAM
Power cycle or
explicit delete
command
The libMD HMAC keys: message
digest for hashing password and
critical function test.
CO-PW Password is
externally generated,
password hash is
internally generated
Entry: Manual
entry, manual
key entry test
will be used.
Output:
Password
hash can be
viewed by
the CO.
No SSP
establishm
ent
method
involved
Non-
plaintext:
Persistent
(Password
Hash)
Zeroize
and
explicit
delete
command
Password used to authenticate the
CO.
User-PW Password is
externally generated,
password hash is
internally generated
Entry: Manual
entry, manual
key entry test
will be used.
Output:
Password
hash can be
viewed by
the CO.
No SSP
establishm
ent
method
involved
Non-
plaintext:
Persistent
(Password
Hash)
Zeroize
and
explicit
delete
command
Password used to authenticate the
User.
Security Target for Junos OS 22.2R1 for MX Series with MX-SPC3 Juniper Networks, Inc.
Version 1.1 Page 59 of 67
Certificate that holds the public
key of the signing key that was
used to generate all the signatures
used on the packages and
signatures lists.
SSH-DH-
PUB
Internally generated
using HMAC DRBG
(part of DH
exchange)
N/A SP800-
56Arev3
compliant
KAS
DH groups
14, 19,20
and 21
Plaintext:
RAM
Reboot &
session
terminatio
n
SSH DH and ECDH Public Keys: Used
with SSH-2 for key establishment:
IKE-PUB Generated externally
to the module
Input:
Plaintext or
Encrypted
N/A Plaintext:
RAM
Zeroize;
explicit
delete
command
IKE Public Keys:
RSA 2048, RSA 4096 ECDSA P-256,
ECDSA P-521 or ECDSA P-384
IKE-DH-
PUB
Internally generated
using HMAC DRBG
N/A SP800-
56Arev3
compliant
KAS
DH groups
for IKE: 14,
15,16, 19,
20, 21 and
24.
Plaintext:
RAM
Reboot &
session
terminatio
n
IKE DH Public Keys:
Used with IKE for key establishment:
HA-IKE-
PUB
Generated externally Input:
Plaintext or
Encrypted
N/A Plaintext:
RAM
Zeroize
and explicit
delete
command
IKE Public Keys for HA link:
RSA 2048, RSA 4096 ECDSA P-256,
ECDSA P-521 or ECDSA P-384
HA-IKE-
DH-PUB
Internally generated
using HMAC DRBG
N/A SP800-
56Arev3
compliant
KAS
DH groups
for IKE: 14,
15,16, 19,
20, 21 and
24.
Plaintext:
RAM
Reboot &
session
terminatio
n
IKE DH Public Keys for HA link:
Used with IKE for key establishment:
• Perform management functions (FMT_SMF.1/ND, FMT_SMF.1/VPN):
o Configure the access banner (FTA_TAB.1)
o Configure the session inactivity time before session termination or locking, including
termination of session when serial console cable is disconnected (FTA_SSL_EXT.1,
FTA_SSL.3)
o Ability to import X.509v3 certificates (FCS_IPSEC_EXT.1)
o Manage cryptographic functionality (FCS_SSHS_EXT.1), including:
▪ ssh ciphers
▪ hostkey algorithm
▪ key exchange algorithm
▪ hashed message authentication code
▪ thresholds for SSH rekeying
o Set the system time (FPT_STM_EXT.1)
Security Target for Junos OS 22.2R1 for MX Series with MX-SPC3 Juniper Networks, Inc.
Version 1.1 Page 60 of 67
o Ability to configure the VPN-associated cryptographic functionality
(FCS_COP.1/DataEncryption, FCS_CKM.1.1/IKE, FCS_IPSEC_EXT.1);
o Ability to configure the IPsec functionality (FCS_IPSEC_EXT.1), including
configuration of IKE lifetime-seconds (within range 180 to 8640027
, with default
value of 180 seconds), IPsec lifetime-seconds (within range 180 to 86400, with
default value of 28800 seconds28
), and ability to configure the reference identifier
for the peer;
o Ability to enable, disable, determine and modify behavior, and configure all other
VPN-associated security functions of the TOE identified in [MOD_VPNGW]
(FPF_RUL_EXT.1, FCS_COP.1/DataEncryption, FCS_CKM.1.1/IKE, FCS_IPSEC_EXT.1);
o Manage the packet filtering rules and VPN configuration (FMT_SMF.1/VPN)
170. Detailed topics on the secure management of Junos OS are discussed in [ECG].
7.7 Packet Filtering
171. The boot sequence of the TOE appliances also aids in establishing the securing domain and
preventing tampering or bypass of security functionality. This includes ensuring the packet
filtering rules cannot be bypassed during the boot sequence of the TOE. The following steps list
the boot sequence for the TOE:
• BIOS hardware and memory checks
• Loading and initialization of the FreeBSD Kernel OS
• FIPS self-tests and firmware integrity tests are executed
• The init utility is started (mounts file systems, sets up network cards to communicate on
the network, and generally starts all the processes that usually are run on a FreeBSD
system at startup)
• Daemon programs such as Internet Service Daemon (INETD), Routing Protocol Daemon
(RPD), Syslogd are started; Routing and forwarding tables are initialized
• Management Daemon (or MGD) is loaded, allowing access to management interface
• Physical interfaces are active
172. Once the interfaces are brought up, they will start to receive and send packets based on the
current configuration (or not receive or send any packets if they have not been previously
configured). Interfaces are brought up only after successful loading of kernel and Information
Flow subsystems, and these interfaces cannot send or receive packets unless previously
configured by an Administrator. Since the Management Daemon is not loaded until after the
kernel and INETD are initialized, no modification to the security attributes can be made by a user
or process other than via the management process.
173. The trusted and untrusted network connection interfaces on the security appliance are not
enabled until all of the components on the appliance are fully initialized; power-up tests are
successful and ready to enforce the configured security policies. In this manner, the TOE ensures
that Administrators are appropriately authorized when they exercise management commands
and any network traffic is always subject to the configured information flow policies.
174. The INETD module provides internet services for the TOE. The module listens on designated
ports used by internet services such as FTP. When a TCP or UDP packet arrives with a particular
27
180 to 86400 seconds is a range of 3 minutes to 24 hours.
28
28800 seconds is 8 hours.
Security Target for Junos OS 22.2R1 for MX Series with MX-SPC3 Juniper Networks, Inc.
Version 1.1 Page 61 of 67
destination port number, INETD launches the appropriate server program (e.g., SSHD) to handle
the connection.
175. The TOE is configured to associate network interfaces to IP subnets. Source IP addresses are
then associated with the network interface.
176. Junos is composed of a number of separate executables, or daemons. If a failure occurs in the
“flow” daemon (flowd) causing it to halt, no packet processing will occur, and no packets will be
forwarded. A failure in another daemon will not prevent the flow daemon from enforcing the
policy rule set.
177. The Information Flow subsystem is responsible for processing the arriving packets from the
network to the TOE's network interface. Based on Administrator-configured policy, interface and
zone information, the packet flows through the various modules of the Information Flow
subsystem. Rules within policies are processed in an Administrator-defined order when network
traffic flows through the TOE network interfaces. By default, the TOE behavior is to deny packets
when there is no rule match unless another required condition allows the network traffic If a
security risk is found in the packet. The packet does not continue to the next module for
processing. If the packet is not dropped by a given module, the interrupt handling routine calls
the function for the next relevant module. In case of an interface getting overwhelmed, packets
are dropped. This is recorded by the SNMP mibs as well as a log. When an interface gets
overwhelmed with CPU utilization 99% then packets are dropped with syslog record as 'CPU
Utilization greater than 99, expect packet loss'.
178. The Information Flow subsystem consists of the following modules:
• IP Classification Module
• Attack Detection Module
• Session Lookup Module
• Security Policy Module
• Session Setup Module
• Inetd Module
• Rdp Module
179. The IP Classification module retrieves information from packets received on the network
interface device, classifies packets into several categories, saves classification information in
packet processing context, and provides other modules with that information for assisting
further processing.
180. The Attack Detection module provides inline attack detection such as IP Spoofing for the security
appliance. This module monitors arriving traffic, performs predefined attack detection services
(prevents attacks), and issues actions when an attack is found.
181. The Session Lookup module performs lookups in the session table which is used for all interfaces
based on the information in incoming packets. Specifically, the lookup is based on the exact
match of source IP address and port, destination IP address and port, protocol attributes (e.g.,
SYN, ACK, RST, and FIN), and egress/ingress zone. The input is passed to the module as a set of
parameters from the Attack Detection module via a function call. The module returns matching
wing if a match is found and 0 otherwise. Sessions are removed when terminated.
182. The Session Setup module is only available for packets that do not match current established
sessions. It is activated after the Session Lookup module. If packet has a matched session, it will
skip the session setup module and proceed to the Security Policy module, and other modules.
Security Target for Junos OS 22.2R1 for MX Series with MX-SPC3 Juniper Networks, Inc.
Version 1.1 Page 62 of 67
Eventually if the packet is not destined for the TOE, the Network interface will pass the traffic
out of the appliance.
183. The Security Policy module examines traffic passing through the TOE (via Session Setup module)
and determines if the traffic can pass based on administrator-configured access policies. The
Security Policy module will deny packets when there is no policy match unless another policy
allows the traffic.
184. The Session Setup module performs the auditing of denied packets. If there is a policy to
specifically deny traffic, traffic matching this deny policy is dropped and logged in traffic log. If
there is no policy to deny traffic, traffic that does not match any policy is dropped and not
logged. In either case, Session Setup module does not create any sessions for denied traffic.
Sessions are created for allowed traffic.
185. The INETD module provides internet services for the TOE. The module listens on designated
ports used by internet services such as FTP. When a TCP or UDP packet arrives with a particular
destination port number, INETD launches the appropriate server program (e.g., SSHD) to handle
the connection.
186. The RPD (Routing Protocol Daemon) module provides the implementations and algorithms for
the routing protocols and route calculations. The primary goal of the RPD is to create and
maintain the Routing Information Base (RIB), which is a database of routing entries. Each routing
entry consists of a destination address and some form of next hop information. RPD module
maintains the internal routing table and properly distributes routes from the routing table to
Kernel subsystem used for traffic forwarding at the Network interface.
187. The TOE performs network traffic filtering on network packets using the following network
traffic protocols and network fields conforming to the described RFCs:
PROTOCOL/RFC FIELDS
Internet Control Message Protocol version 4 (ICMPv4)
RFC 792 (ICMPv4)
Type
Code
Internet Control Message Protocol version 6 (ICMPv6)
RFC 4443 (ICMPv6)
Type
Code
Internet Protocol (IPv4)
RFC 791 (IPv4)
Source address
Destination Address
Transport Layer
Protocol
Internet Protocol version 6 (IPv6)
RFC 2460 (IPv6)
Source address
Destination Address
Transport Layer
Protocol
Transmission Control Protocol (TCP)
RFC 793 (TCP)
Source port
Destination port
User Datagram Protocol (UDP)
RFC 768 (UDP)
Source port
Destination port
Table 11 Traffic Filtering RFCs
188. Conformance to these RFCs is demonstrated by protocol compliance testing by the product QA
team.
189. The TOE allows permit, deny, and log operations to be associated with rules and these rules can
be assigned to distinct network interfaces and applied in an administrator-defined order. By
default the MX devices drop traffic that do not match a configured rule. (FPF_RUL_EXT.1)
Security Target for Junos OS 22.2R1 for MX Series with MX-SPC3 Juniper Networks, Inc.
Version 1.1 Page 63 of 67
8 Rationales
8.1 SFR dependency analysis
190. The dependencies between SFRs implemented by the TOE are satisfied as demonstrated in
[CPP_ND] Appendix E.1.
Security Functional
Requirement
Dependency Rationale
FAU_GEN.1/ND FPT_STM.1 FPT_STM_EXT.1 included (which is
hierarchic to FPT_STM.1)
FAU_GEN.2 FAU_GEN.1
FIA_UID.1
FAU_GEN.1 Included
Satisfied by FIA_UIA_EXT.1, which
specifies the relevant Administrator
identification timing
FAU_STG_EXT.1 FAU_GEN.1
FTP_ITC.1
FAU_GEN.1 included
FTP_ITC.1 included
FAU_STG.1 FAU_GEN.1 FAU_GEN.1 Included
FCS_CKM.1/ND FCS_CKM.2 or FCS_COP.1
FCS_CKM.4
FCS_CKM.2 included
FCS_CKM.4 included
FCS_CKM.1/IKE FCS_CKM.2 or FCS_COP.1
FCS_CKM.4
FCS_CKM.2 included
FCS_CKM.4 included
FCS_CKM.2 FTP_ITC.1 or FTP_ITC.2 or
FCS_CKM.1
FCS_CKM.4
FCS_CKM.1 included (also FTP_ITC.1 as
a secure channel that could be used for
import)
FCS_CKM.4 included
FCS_CKM.4 FTP_ITC.1 or FTP_ITC.2 or
FCS_CKM.1
FCS_CKM.1 included (also FTP_ITC.1 as
a secure channel that could be used for
import)
FCS_COP.1/DataEncryption FTP_ITC.1 or FTP_ITC.2 or
FCS_CKM.1
FCS_CKM.4
FCS_CKM.1 included (also FTP_ITC.1 as
a secure channel that could be used for
import)
FCS_CKM.4 included
FCS_COP.1/SigGen FTP_ITC.1 or FTP_ITC.2 or
FCS_CKM.1
FCS_CKM.4
FCS_CKM.1 included (also FTP_ITC.1 as
a secure channel that could be used for
import)
FCS_CKM.4 included
FCS_COP.1/Hash FTP_ITC.1 or FTP_ITC.2 or
FCS_CKM.1
FCS_CKM.4
FCS_CKM.1 included (also FTP_ITC.1 as
a secure channel that could be used for
import)
FCS_CKM.4 included
FCS_COP.1/KeyedHash FTP_ITC.1 or FTP_ITC.2 or
FCS_CKM.1
FCS_CKM.4
FCS_CKM.1 included (also FTP_ITC.1 as
a secure channel that could be used for
import)
FCS_CKM.4 included
FCS_RBG_EXT.1 None n/a
Security Target for Junos OS 22.2R1 for MX Series with MX-SPC3 Juniper Networks, Inc.
Version 1.1 Page 64 of 67
Security Functional
Requirement
Dependency Rationale
FCS_IPSEC_EXT.1 FCS_CKM.1
FCS_CKM.2
FCS_COP.1/DataEncryption
FCS_COP.1/SigGen
FCS_COP.1/Hash
FCS_COP.1/KeyedHash
FCS_RBG_EXT.1
FCS_CKM.1 included
FCS_CKM.2 included
FCS_COP.1/DataEncryption included
FCS_COP.1/SigGen included
FCS_COP.1/Hash included
FCS_COP.1/KeyedHash included
FCS_RBG_EXT.1 included
FCS_SSHS_EXT.1 FCS_CKM.1
FCS_CKM.2
FCS_COP.1/DataEncryption
FCS_COP.1/SigGen
FCS_COP.1/Hash
FCS_COP.1/KeyedHash
FCS_RBG_EXT.1
FCS_CKM.1 included
FCS_CKM.2 included
FCS_COP.1/DataEncryption included
FCS_COP.1/SigGen included
FCS_COP.1/Hash included
FCS_COP.1/KeyedHash included
FCS_RBG_EXT.1 included
FIA_AFL.1 FIA_UAU.1 Satisfied by FIA_UIA_EXT.1, which
specifies the relevant Administrator
authentication
FIA_PMG_EXT.1 None n/a
FIA_UIA_EXT.1 FTA_TAB.1 FTA_TAB.1 included
FIA_UAU_EXT.2 None n/a
FIA_UAU.7 FIA_UAU.1 Satisfied by FIA_UIA_EXT.1, which
specifies the relevant Administrator
authentication
FIA_X509_EXT.1/Rev None n/a
FIA_X509_EXT.2 None n/a
FIA_X509_EXT.3 FCS_CKM.1 Cryptographic
Key Generation
FCS_CKM.1/ND included
FIA_PSK_EXT.1 None n/a
FMT_MOF.1/ManualUpdate FMT_SMR.1
FMT_SMF.1
FMT_SMR.2 included
FMT_SMF.1/ND included
FMT_MOF.1/Services FMT_SMR.1
FMT_SMF.1
FMT_SMR.2 included
FMT_SMF.1/ND, FMT_SMF.1/VPN
included
FMT_MOF.1/Functions FMT_SMR.1
FMT_SMF.1
FMT_SMR.2 included
FMT_SMF.1/ND included
FMT_MTD.1/CoreData FMT_SMR.1
FMT_SMF.1
FMT_SMR.2 included
FMT_SMF.1/ND included
FMT_MTD.1/CryptoKeys FMT_SMR.1
FMT_SMF.1
FMT_SMR.2 included
FMT_SMF.1/ND included
FMT_SMF.1/ND None n/a
FMT_SMF.1/VPN None n/a
FMT_SMR.2 FIA_UID.1 Satisfied by FIA_UIA_EXT.1, which
specifies the relevant Administrator
authentication
FPT_SKP_EXT.1 None n/a
FPT_APW_EXT.1 None n/a
FPT_TST_EXT.1 None n/a
FPT_TST_EXT.3 None n/a
Security Target for Junos OS 22.2R1 for MX Series with MX-SPC3 Juniper Networks, Inc.
Version 1.1 Page 65 of 67
Security Functional
Requirement
Dependency Rationale
FPT_TUD_EXT.1 FCS_COP.1/SigGen or
FCS_COP.1/Hash
FCS_COP.1/SigGen
FPT_STM.EXT.1 None n/a
FPT_FLS.1/SelfTest None n/a
FTA_SSL_EXT.1 FIA_UID.1 Satisfied by FIA_UIA_EXT.1, which
specifies the relevant Administrator
authentication
FTA_SSL.3 None n/a
FTA_SSL.4 None n/a
FTA_TAB.1 None n/a
FTP_ITC.1 None n/a
FTP_TRP.1/Admin None n/a
FPF_RUL_EXT.1 None n/a
Table 12 SFR Dependency Analysis
Security Target for Junos OS 22.2R1 for MX Series with MX-SPC3 Juniper Networks, Inc.
Version 1.1 Page 66 of 67
9 Glossary
AES Advanced Encryption Standard
ANSI American National Standards Institute
API Application Program Interface
BGP Border Gateway Protocol
cPP collaborative Protection Profile
CCM Counter with Cipher Block Chaining-Message Authentication Code
CFP C Form-factor Pluggable
CM Configuration Management
CSP Critical security parameter
DFA Deterministic Finite Automaton
DES Data Encryption Standard
DH Diffie Hellman
EAL Evaluation Assurance Level
ECC Elliptic Curve Cryptography
ECDSA Elliptic Curve Digital Signature Algorithm
ESP Encapsulating Security Payload
FFC Finite Field Cryptography
FIPS Federal Information Processing Standard
FTP File Transfer Protocol
PIM Gigabit-Backplane PIM
HA High Availability
HMAC Keyed-Hash Authentication Code
I&A Identification and Authentication
ICMP Internet Control Message Protocol
ID Identification
IETF Internet Engineering Task Force
IKE Internet Key Exchange
IOC I/O (Input/Output) Cards
IP Internet Protocol
IPsec Internet Protocol Security
IPsec ESP Internet Protocol Security Encapsulating Security Payload
IPv6 Internet Protocol Version 6
IPX Internetwork Packet Exchange
ISAKMPInternet Security Association and Key Management Protocol
IS-IS Intermediate System-to-Intermediate System
ISO International Organization for Standardization
IT Information Technology
JET Junos Extension toolkit. Control plane APIs for Junos.
KAS Key Agreement Scheme
Junos Juniper Operating System
LDP Label Distribution Protocol
MAC Mandatory Access Control
MIC Modular Interface Cards
MPC Modular Port Concentrator
MRE Medium Robustness Environment
NAT Network Address Translation
NDcPP Network Device collaborative Protection Profile
NTP Network Time Protocol
OSI Open Systems Interconnect
Security Target for Junos OS 22.2R1 for MX Series with MX-SPC3 Juniper Networks, Inc.
Version 1.1 Page 67 of 67
OSP Organizational Security Policy
OSPF Open Shortest Path First
PAM Pluggable Authentication Module
PFE Packet Forwarding Engine
PFEP Linux process that manages the PFE. Also referred to as forwarding daemon.
PIC/PIM Physical Interface Card/Module
PKI Public Key Infrastructure
POE Power over Ethernet
PP Protection Profile
PRNG Pseudo Random Number Generator
QSFP Quad SFP
RE Routing Engine
RFC Request for Comment
RIP Routing Information Protocol
RNG Random Number Generator
RSA Rivest, Shamir, Adelman
SA Security Association
SCB Switch Control Board
SCEP Simple Certificate Enrollment Protocol
SFP Small Form-factor Pluggable
SFR Security Functional Requirement
SHA Secure Hash Algorithm
SNMP Simple Network Management Protocol
SPC Services Processing Card
SPU Services Processing Units
SRX5k SRX models 5400, 5600 and 5800
SSC Shared Secret Computation
SSD Solid State Drive
SSH Secure Shell
SSL Secure Sockets Layer
ST Security Target
TCP/IP Transmissions Control Protocol/ Internet Protocol
TOE Target of Evaluation
TSF TOE Security Functionality
TSFI TSF interfaces
UDP User Datagram Protocol
VPN Virtual Private Network
VDSL Very-high-bit-rate Digital Subscriber Line
XFP 10 Gigabit SFP