ASSURANCE ACTIVITY REPORT JUNOS 12.3 X48-D30 FOR SRX XLR PLATFORMS

Transcription

1 PAGE 1 OF 66 ASSURANCE ACTIVITY REPORT JUNOS 12.3 X48-D30 FOR SRX XLR PLATFORMS Reference EFS-T042-AAR Status Released Version 1.1 Release Date 17 January 2017 Author Dan Pitcher Customer Juniper Networks, Inc. Approved By X Signatory

2 ASSURANCE ACTIVITY REPORT -JUNOS 12.3 X48-D30 FOR SRX XLR PLATFORMS PAGE 2 OF 66 Table of Contents 1 Introduction Overview Evaluation details ST configuration control identifiers TOE Configuration References Requirements Evaluation Evidence Copyright statement Protection Profile SFR assurance activities Security Audit (FAU) FAU_GEN.1(1) Audit data generation FAU_GEN.1(2) Audit data generation (IPS) FAU_GEN.2 User identity association FAU_STG_EXT.1 External audit trail storage Cryptographic support (FCS) FCS_CKM.1(1) Cryptographic key generation (for asymmetric keys) FCS_CKM_EXT.4 Cryptographic key zeroization FCS_COP.1(1) Cryptographic operation (for data encryption/decryption) FCS_COP.1(2) Cryptographic operation (for cryptographic signature) FCS_COP.1(3) Cryptographic operation (for cryptographic signature) FCS_COP.1(4) Cryptographic operation (for cryptographic hashing) FCS_COP.1(5) Cryptographic operation (for keyed-hash message authentication) FCS_RBG_EXT.1 Extended cryptographic operation (random bit generation) FCS_SSH_EXT.1 Explicit SSH FCS_IPSEC_EXT.1 Extended: Internet Protocol Security (IPSec) Communications User Data Protection (FDP) FDP_RIP.2 Full residual information protection Identification and Authentication (FIA) FIA_PMG_EXT.1 Password management FIA_UAU_EXT.2 Extended: Password-based authentication mechanism FIA_UIA_EXT.1 User identification and authentication FIA_UAU.7 Protected authentication feedback FIA_PSK_EXT.1 Extended: Pre-shared key composition Security management (FMT) FMT_MTD.1 Management of TSF data (for general TSF data) FMT_SMF.1(1) Specification of management functions FMT_SMF.1(2) Specification of management functions FMT_SMR.2 Restrictions on security roles Protection of the TSF (FPT) FPT_SKP_EXT.1 Extended: Protection of TSF data (for reading of all symmetric keys) FPT_APW_EXT.1 Extended: Protection of administrator passwords... 30

3 ASSURANCE ACTIVITY REPORT -JUNOS 12.3 X48-D30 FOR SRX XLR PLATFORMS PAGE 3 OF FPT_STM.1 Reliable time stamps FPT_TUD_EXT.1 Extended: Trusted update FPT_TST_EXT.1 Extended: TSF testing TOE access (FTA) FTA_SSL_EXT.1 TSF-initiated session locking FTA_SSL.3 TSF-initiated termination FTA_SSL.4 User-initiated termination FTA_TAB.1 Default TOE access banners Trusted path/channels (FTP) FTP_ITC.1 Inter-TSF trusted channel (prevention of disclosure) FTP_TRP.1 Trusted path Stateful traffic/packet filtering (FFW and FPF) FFW_RUL_EXT.1 Stateful firewall filtering Intrusion prevention system (IPS) IPS_NTA_EXT.1 Network traffic analysis IPS_IPB_EXT.1 IP blocking IPS_SBD_EXT.1 Signature-based IPS functionality IPS_ABD_EXT.1 Anomaly-based IPS functionality Protection Profile SAR assurance activities Development (ADV) Basic functional specification (ADV_FSP.1) documentation (AGD) Operational user guidance (AGD_OPE.1) Preparative procedures (AGD_PRE.1) Lifecycle support (ALC) Labelling of the TOE (ALC_CMC.1) TOE CM coverage (ALC_CMS.1) (ATE) Independent testing conformance (ATE_IND.1) Vulnerability assessment (AVA) Vulnerability survey (AVA_VAN.1)... 65

4 ASSURANCE ACTIVITY REPORT -JUNOS 12.3 X48-D30 FOR SRX XLR PLATFORMS PAGE 4 OF 66 1 INTRODUCTION 1.1 Overview This report documents the Common Criteria NDPP + FWEP + IPSEP evaluation of the Juniper Networks, Inc. Junos 12.3 X48-D30 for SRX XLR Platforms (Junos 12.3 X48-D30) product. 1.2 Evaluation details Developer Sponsor Evaluator Scheme Task ID Juniper Networks, Inc Innovation Way, Sunnyvale, CA 94089, USA Juniper Networks, Inc. BAE Systems Lab - AISEF Level 1, 14 Childers Street, Canberra ACT 2601, Australia AISEP EFS-T ST configuration control identifiers ST Title Junos 12.3 X48-D30 for SRX XLR Platforms ST Version/Date Version 1.1, 17 January TOE Configuration TOE Name TOE Version Junos 12.3 X48-D30 for SRX XLR Platforms (Junos 12.3 X48-D30) 12.3 X48-D References Requirements [1] Common Criteria for Information Technology Security Evaluation, Part 1: Introduction and general model, Version 3.1, Revision 4 [2] Common Criteria for Information Technology Security Evaluation, Part 2: Security functional components, Version 3.1, Revision 4 [3] Common Criteria for Information Technology Security Evaluation Part 3: Security assurance components, version 3.1 Revision 4 [4] Common Methodology for Information Technology Security Evaluation, Evaluation methodology, Version 3.1, Revision 4 [5] Security Requirements for Network Devices (NDPP), Version 1.1, 08 June 2012 [6] Security Requirements for Network Devices (NDPP) Errata #3, 3 November 2014 [7] Network Device Protection Profile (NDPP) Extended Package Stateful Traffic Filter Firewall (FWEP), Version 1.0, 19 December 2011 [8] Network Device Protection Profile (NDPP) Extended Package for Intrusion Prevention Systems (IPSEP), Version 1.0, 26 June Evaluation Evidence [9] Security Target - Junos 12.3 X48-D30 for SRX XLR Platforms (NDPP, TFFWEP, IPSEP), Version 1.1, 17-Jan-17 [10] Junos OS Common Criteria and Junos Evaluated Configuration Guide for SRX Series Security Devices, Release 12.3X48-D30, 28-Jul-16

5 ASSURANCE ACTIVITY REPORT -JUNOS 12.3 X48-D30 FOR SRX XLR PLATFORMS PAGE 5 OF 66 [11] Junos OS CLI User Guide, Release 12.3, 13-Jun-16 [12] Junos OS Installation and Upgrade Guide, Release 12.3, 17-Jun-16 [13] Junos OS System Basics: Getting Started Configuration Guide, Release 12.3, 10- Jun-16 [14] Junos OS Intrusion Detection and Prevention Feature Guide for Security Devices, Release 12.3X48-D10, 12-Jan-16 [15] Junos 12.3 X48 for SRX Series Platforms SRX Annex, Version 1.0, 17- Jan-17 [16] Junos 12.3 X48 for SRX Series Platforms SRX IPS Supplement, Version 1.0, 17-Jan-17 [17] Junos 12.3 X48 for SRX Series Platforms SRX Running Processes, Version 1.0, 17-Jan-17 [18] Seeding of the Kernel in SRX Series Appliances running Junos 12.3 X48 D30, Version 0.2, 15-Sep Copyright statement This document contains information protected by copyright. BAE Systems Applied Intelligence Pty Ltd (ABN ). The material in this document may not be commercialised without prior written permission from BAE Systems Applied Intelligence.

6 ASSURANCE ACTIVITY REPORT -JUNOS 12.3 X48-D30 FOR SRX XLR PLATFORMS PAGE 6 OF 66 2 PROTECTION PROFILE SFR ASSURANCE ACTIVITIES This section of the AAR defines each of the SFRs specified in the ST (Ref. [9]), their corresponding assurance activities and the evaluator s findings in each case. 2.1 Security Audit (FAU) FAU_GEN.1(1) Audit data generation The evaluator shall check the administrative guide and ensure that it lists all of the auditable events and provides a format for audit records. Each audit record format type must be covered, along with a brief description of each field. The evaluator shall check to make sure that every audit event type mandated by the PP is described and that the description of the fields contains the information required in FAU_GEN1.2, and the additional information specified in Table 1. The evaluator shall also make a determination of the administrative actions that are relevant in the context of this PP. The evaluator shall examine the administrative guide and make a determination of which administrative commands, including subcommands, scripts, and configuration files, are related to the configuration (including enabling or disabling) of the mechanisms implemented in the TOE that are necessary to enforce the requirements specified in the PP. The evaluator shall document the methodology or approach taken while determining which actions in the administrative guide are security relevant with respect to this PP. The evaluator may perform this activity as part of the activities associated with ensuring the AGD_OPE guidance satisfies the requirements. The Common Criteria Evaluated Configuration Guide and other associated guidance documents together provide examples of the auditable events and their corresponding audit records. Audit records are provided by the TOE in the following format (also see Chapter 11 of the CCECG): <date> <time> <system name> <process>: <event> All configuration/commands presented in the Evaluated Configuration Guide are considered relevant to the secure configuration of the TOE and the mechanisms necessary to enforce the requirements of the PP and associated EP. For all other guidance documentation, the evaluators determined that, while the guidance covers the whole breadth of functionality provided by the TOE (a substantial amount of which is not included in the scope of this evaluation), the chapter and section headings used allow for easy identification of which information and configuration data is pertinent to the functionality provided by the PP/EPs.

7 ASSURANCE ACTIVITY REPORT -JUNOS 12.3 X48-D30 FOR SRX XLR PLATFORMS PAGE 7 OF 66 The evaluator shall test the TOE s ability to correctly generate audit records by having the TOE generate audit records for the events listed in table 1 and administrative actions. This should include all instances of an event--for instance, if there are several different I&A mechanisms for a system, the FIA_UIA_EXT.1 events must be generated for each mechanism. The evaluator shall test that audit records are generated for the establishment and termination of a channel for each of the cryptographic protocols contained in the ST. If HTTPS is implemented, the test demonstrating the establishment and termination of a TLS session can be combined with the test for an HTTPS session. For administrative actions, the evaluator shall test that each action determined by the evaluator above to be security relevant in the context of this PP is auditable. When verifying the test results, the evaluator shall ensure the audit records generated during testing match the format specified in the administrative guide, and that the fields in each audit record have the proper entries. Throughout the testing performed, the evaluators examined the TOE to determine whether audit log entries for all auditable events were generated. The evaluators confirmed that all auditable events are generated. The evaluators confirmed that audit entries were generated for the firewall rules for permit, deny and log. The evaluators confirmed that, in the scenario when the TOE is subjected to more traffic than the interfaces are able to handle, that the TOE automatically drops all received packets until the overwhelming traffic ceases and audits these events appropriately FAU_GEN.1(2) Audit data generation (IPS) The evaluator shall verify that the describes how the TOE can be configured to log IPS data associated with applicable policies. The evaluator shall verify that the describes what (similar) IPS event types the TOE will combine into a single audit record along with the conditions (e.g., thresholds and time periods) for so doing. The shall also describe to what extent (if any) that may be configurable. The TOE generates event logs when a firewall or IPS also referred to as Intrusion Detection and Prevention (IDP) in the Junos OS literature rules are triggered. Event logging can be configured on a rule-by-rule basis when defining individual firewall and IPS policies. Because of the nature of IDP event logs, log generation often happens in bursts and can generate a much larger volume of messages during an attack. To manage the volume of log messages, Junos supports log suppression, which suppresses multiple instances of the same log occurring from the same or similar sessions over the same period of time. IDP log suppression is enabled by default and can be customized based on configurable attributes: Source/destination addresses; Number of log occurrences after which log suppression begins; Maximum number of logs that log suppression can operate on; Time after which suppressed logs are reported. Suppressed logs are reported as single log entry containing the count of occurrences.

8 ASSURANCE ACTIVITY REPORT -JUNOS 12.3 X48-D30 FOR SRX XLR PLATFORMS PAGE 8 OF 66 The evaluator shall verify that the operational guidance describes how to configure the TOE to result in applicable IPS data logging. The evaluator shall verify that the operational guidance provides instructions for any configuration that may be done in regard to logging similar events (e.g., setting thresholds, defining time windows, etc.). Chapter 12 (Configuring Network Attacks) of the Evaluated Configuration Guide and Chapter 12 (Monitoring Device Events by Configuring IDP Logging) of the IDP Feature Guide provide guidance to administrators regarding the composition of IDP policies and the configuration of logging. Test 1: The evaluator shall test that the interfaces used to configure the IPS polices yield expected IPS data in association with the IPS policies. A number of IPS policy combination and ordering scenarios need to be configured and tested by attempting to pass both allowed and anomalous network traffic matching configured IPS policies in order to trigger all required IPS events. The evaluators performed a variety of tests that exercised all required IPS events. The evaluators confirmed that the behaviour of the TOE and the data generated by the TOE were consistent with expectations FAU_GEN.2 User identity association FAU_STG_EXT.1 External audit trail storage The evaluator shall examine the to ensure it describes the amount of audit data that are stored locally; what happens when the local audit data store is full; and how these records are protected against unauthorized access. The evaluator shall examine the to ensure it describes the means by which the audit data are transferred to the external audit server, and how the trusted channel is provided. The TOE 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. The maximum value that can be specified for the size of a log file is 1GB. These defaults maximum sizes can be modified by the user.

9 ASSURANCE ACTIVITY REPORT -JUNOS 12.3 X48-D30 FOR SRX XLR PLATFORMS PAGE 9 OF 66 Syslog can be configured to store the audit logs locally, or to send them to one or more syslog log servers (via IPSec ). When the TOE is configured to direct syslog traffic to an external syslog server via a IPSec, a VPN tunnel is initiated from the TOE immediately upon configuration commit and communications from TOE to the syslog server is encrypted and integrity protected. Audit records are sent to the syslog server periodically as configured by the Administrator The evaluator shall examine the operational guidance to determine that it describes the relationship between the local audit data and the audit data that are sent to the audit log server (for TOEs that are not acting as an audit log server). The evaluator shall examine the operational guidance to ensure it describes how to establish the trusted channel to the audit server, as well as describe any requirements on the audit server (particular audit server protocol, version of the protocol required, etc.), as well as configuration of the TOE needed to communicate with the audit server. Chapter 8 of the Evaluated Configuration Guide indicates that: When the device running Junos OS is set up for an external syslog server, the TOE forwards copies of local logs to the external syslog server and retains local copies of all logs when the TOE is configured in event log mode. In stream log mode, all logs except traffic logs are stored locally and can be forwarded to an external syslog server, whereas traffic logs can only be forwarded to an external syslog server. The evaluator shall establish a session between the TOE and the audit server according to the configuration guidance provided. The evaluator shall then examine the traffic that passes between the audit server and the TOE during several activities of the evaluator s choice designed to generate audit data to be transferred to the audit server. The evaluator shall observe that these data are not able to be viewed in the clear during this transfer, and that they are successfully received by the audit server. The evaluator shall record the particular software (name, version) used on the audit server during testing The evaluators configured and established an IPsec tunnel between itself and a remote audit server. The evaluators then performed a number of events to generate audit traffic. The evaluators confirmed that this traffic was not sent in the clear. The evaluators examined the syslog on the audit server and confirmed that the audit entries were received from the TOE. The audit server was configured using Strongswan version U5.4.0 and the default rsyslogd installation provided with Kali Linux

10 ASSURANCE ACTIVITY REPORT -JUNOS 12.3 X48-D30 FOR SRX XLR PLATFORMS PAGE 10 OF Cryptographic support (FCS) FCS_CKM.1(1) Cryptographic key generation (for asymmetric keys) In order to show that the TSF complies with A and/or B, depending on the selections made, the evaluator shall ensure that the contains the following information: The shall list all sections of the appropriate standard(s) to which the TOE complies. For each applicable section listed in the, for all statements that are not "shall" (that is, "shall not", "should", and "should not"), if the TOE implements such options it shall be described in the. If the included functionality is indicated as "shall not" or "should not" in the standard, the shall provide a rationale for why this will not adversely affect the security policy implemented by the TOE; and For each applicable section of A and B (as selected), any omission of functionality related to "shall" or should statements shall be described. Any TOE-specific extensions, processing that is not included in the documents, or alternative implementations allowed by the documents that may impact the security requirements the TOE is to enforce shall be described The TOE complies with section 6 of NIST SP B regarding RSA 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 Appendix B3 and B4. The evaluator shall use the key pair generation portions of "The FIPS Digital Signature Algorithm Validation System (DSA2VS)", "The FIPS Elliptic Curve Digital Signature Algorithm Validation System (ECDSA2VS)", and "The RSA Validation System (RSA2VS)" as a guide in testing the requirement above, depending on the selection performed by the ST author. This will require that the evaluator have a trusted reference implementation of the algorithms that can produce test vectors that are verifiable during the test. The key generation implementations used by the TOE have been given the following CAVP certificate numbers: #909, #912, #913, #914, #915, #916, #917, #1099, #1100, #1101, #1102, #1103, #1104 and # FCS_CKM_EXT.4 Cryptographic key zeroization

11 ASSURANCE ACTIVITY REPORT -JUNOS 12.3 X48-D30 FOR SRX XLR PLATFORMS PAGE 11 OF 66 The evaluator shall check to ensure the describes each of the secret keys (keys used for symmetric encryption), private keys, and CSPs used to generate key; when they are zeroized (for example, immediately after use, on system shutdown, etc.); and the type of zeroization procedure that is performed (overwrite with zeros, overwrite three times with random pattern, etc.). If different types of memory are used to store the materials to be protected, the evaluator shall check to ensure that the describes the zeroization procedure in terms of the memory in which the data are stored (for example, "secret keys stored on flash are zeroized by overwriting once with zeros, while secret keys stored on the internal hard drive are zeroized by overwriting three times with a random pattern that is changed before each write"). Table 7-2, provided in Section 7.2 of the Security Target (Ref. [9]), lists each of the keys/csps used by the TOE. Each key is listed by name/purpose and is accompanied by a description, how and where within the TOE the key is stored and a description of the method used to destroy the key FCS_COP.1(1) Cryptographic operation (for data encryption/decryption) The evaluator shall use tests appropriate to the modes selected in the above requirement from "The Advanced Encryption Standard Algorithm Validation Suite (AESAVS)", "The XTS-AES Validation System (XTSVS)", The CMAC Validation System (CMACVS)", "The Counter with Cipher Block Chaining- Message Authentication Code (CCM) Validation System (CCMVS)", and "The Galois/Counter Mode (GCM) and GMAC Validation System (GCMVS)" (these documents are available from as a guide in testing the requirement above. This will require that the evaluator have a reference implementation of the algorithms known to be good that can produce test vectors that are verifiable during the test. The AES implementation used by the TOE has been given the CAVP certificate numbers: #4056, #4066, #4067, #4068, #4069 and # FCS_COP.1(2) Cryptographic operation (for cryptographic signature)

12 ASSURANCE ACTIVITY REPORT -JUNOS 12.3 X48-D30 FOR SRX XLR PLATFORMS PAGE 12 OF 66 The evaluator shall use the signature generation and signature verification portions of "The Digital Signature Algorithm Validation System (DSA2VS), "The Elliptic Curve Digital Signature Algorithm Validation System (ECDSA2VS), and "The RSA Validation System (RSAVS (for 186-2) or RSA2VS (for 186-3)) as a guide in testing the requirement above. The Validation System used shall comply with the conformance standard identified in the ST (i.e., FIPS PUB or FIPS PUB 186-3). This will require that the evaluator have a reference implementation of the algorithms known to be good that can produce test vectors that are verifiable during the test. The RSA implementation used by the TOE has been given the CAVP certificate numbers: #2197, #2198, #2199, #2200, #2201 and # FCS_COP.1(3) Cryptographic operation (for cryptographic signature) The evaluator shall use the signature generation and signature verification portions of "The Digital Signature Algorithm Validation System (DSA2VS), "The Elliptic Curve Digital Signature Algorithm Validation System (ECDSA2VS), and "The RSA Validation System (RSAVS (for 186-2) or RSA2VS (for 186-3)) as a guide in testing the requirement above. The Validation System used shall comply with the conformance standard identified in the ST (i.e., FIPS PUB or FIPS PUB 186-3). This will require that the evaluator have a reference implementation of the algorithms known to be good that can produce test vectors that are verifiable during the test. The ECDSA implementation used by the TOE has been given the CAVP certificate numbers: #909, #912, #913, #914, #915, #916 and # FCS_COP.1(4) Cryptographic operation (for cryptographic hashing) The evaluator shall use "The Secure Hash Algorithm Validation System (SHAVS)" as a guide in testing the requirement above. This will require that the evaluator have a reference implementation of the algorithms known to be good that can produce test vectors that are verifiable during the test. The SHA implementation used by the TOE has been given the CAVP certificate numbers: #3342, #3343, #3349, #3350, #3351, #3352 and # FCS_COP.1(5) Cryptographic operation (for keyed-hash message authentication)

13 ASSURANCE ACTIVITY REPORT -JUNOS 12.3 X48-D30 FOR SRX XLR PLATFORMS PAGE 13 OF 66 The evaluator shall use "The Keyed-Hash Message Authentication Code (HMAC) Validation System (HMACVS)" as a guide in testing the requirement above. This will require that the evaluator have a reference implementation of the algorithms known to be good that can produce test vectors that are verifiable during the test. The HMAC implementation used by the TOE has been given the CAVP certificate numbers: #2647, #2648, #2653, #2654, #2655, #2656 and # FCS_RBG_EXT.1 Extended cryptographic operation (random bit generation) The evaluator shall confirm that the operational guidance contains appropriate instructions for configuring the RBG functionality. The RBG utilised by the TOE is non-configurable by users of the TOE. As such, no guidance is provided to meet this requirement. The evaluator shall perform 15 trials for the RBG implementation. If the RBG is configurable, the evaluator shall perform 15 trials for each configuration. The DRBG implementation used by the TOE has been given the CAVP certificate number # FCS_SSH_EXT.1 Explicit SSH FCS_SSH_EXT FCS_SSH_EXT.1.2 The evaluator shall check to ensure that the contains a description of the public key algorithms that are acceptable for use for authentication, that this list conforms to FCS_SSH_EXT.1.5, and ensure that password-based authentication methods are also allowed. The TOE uses SSH_RSA and SSH-ECDSA as its public key algorithms for authentication, as well as password-based authentication.

14 ASSURANCE ACTIVITY REPORT -JUNOS 12.3 X48-D30 FOR SRX XLR PLATFORMS PAGE 14 OF 66 The evaluator shall, for each public key algorithm supported, show that the TOE supports the use of that public key algorithm to authenticate a user connection. Any configuration activities required to support this test shall be performed according to instructions in the operational guidance. Using the operational guidance, the evaluator shall configure the TOE to accept password-based authentication, and demonstrate that a user can be successfully authenticated to the TOE over SSH using a password as an authenticator. The evaluators configured the TOE to use both ECDSA and password-based authentication for SSH connections. The evaluators were able to successfully authenticate with the TOE using both methods FCS_SSH_EXT.1.3 The evaluator shall check that the describes how large packets in terms of RFC 4253 are detected and handled. Packets greater than bytes in an SSH transport connection are dropped and the connection is terminated by the TOE. The SSH daemon maintains a byte buffer for incoming packet processing, adding to the buffer in 1K increments. If the accumulated data for a packet exceeds the buffer size, the packet is dropped, the accumulator buffer is reset to zero and a log message indicating that the packet was dropped is created. The evaluator shall demonstrate that if the TOE receives a packet larger than that specified in this component, that packet is dropped. The evaluators used scapy to generate a packet larger than the size specified in the requirement. The evaluators sent the packet to the TOE as part of an SSH session. The evaluators confirmed that the TOE dropped the packet FCS_SSH_EXT.1.4 The evaluator shall check the description of the implementation of this protocol in the to ensure that optional characteristics are specified, and the encryption algorithms supported are specified as well. The evaluator shall check the to ensure that the encryption algorithms specified are identical to those listed for this component. The TOE supports AES-CBC-128 and AES-CBC-256 encryption algorithms for SSH transport. The evaluator shall check the operational guidance to ensure that it contains instructions on configuring the TOE so that SSH conforms to the description in the (for instance, the set of algorithms advertised by the TOE may have to be restricted to meet the requirements). Chapter 3 of the Evaluated Configuration Guide specifies how an administrator may configure the warning/consent banner presented at login and how to configure the SSH daemon to run in an NDPP-compliant setup (such as supported algorithms and key exchange methods).

15 ASSURANCE ACTIVITY REPORT -JUNOS 12.3 X48-D30 FOR SRX XLR PLATFORMS PAGE 15 OF 66 The evaluator shall establish a SSH connection using each of the encryption algorithms specified by the requirement. It is sufficient to observe (on the wire) the successful negotiation of the algorithm to satisfy the intent of the test. The evaluators successfully connected to the TOE using both AES-128-CBC and AES-256- CBC as the encryption algorithms for SSH FCS_SSH_EXT FCS_SSH_EXT.1.6 The evaluator shall check the to ensure that it lists the supported data integrity algorithms, and that that list corresponds to the list in this component. The data integrity algorithms used in SSH transport connection are HMAC-SHA1, HMAC- SHA1-96, as required by RFC4253, and HMAC-SHA2-256, AND HMAC-SHA2-512 as recommended by RFC6668 The evaluator shall check the operational guidance to ensure that it contains instructions to the administrator on how to ensure that only the allowed data integrity algorithms are used in SSH connections with the TOE (specifically, that the none MAC algorithm is not allowed). When operating in the FIPS-CC configuration mode (as required for the evaluated configuration), the TOE automatically restricts the permitted algorithms to those that are specified in the Security Target. The Evaluated Configuration Guide (Ref. [10]) provides administrators with the commands necessary to configure the integrity algorithm used for SSH connections. The evaluator shall establish a SSH connection using each of the integrity algorithms specified by the requirement. It is sufficient to observe (on the wire) the successful negotiation of the algorithm to satisfy the intent of the test. The evaluators successfully connected to the TOE using HMAC-SHA1-96 as the integrity algorithm for SSH FCS_SSH_EXT.1.7 If this capability is hard-coded into the TOE, the evaluator shall check the to ensure that this is stated in the discussion of the SSH protocol. Key exchange is done using diffie-hellman-group14-sha1 as per RFC4253 and ecdh-sha2- nistp256, ecdh-sha2-nistp384 as per RFC5656.

16 ASSURANCE ACTIVITY REPORT -JUNOS 12.3 X48-D30 FOR SRX XLR PLATFORMS PAGE 16 OF 66 The evaluator shall ensure that operational guidance contains configuration information that will allow the security administrator to configure the TOE so that all key exchanges for SSH are performed using DH group 14 and any groups specified from the selection in the ST. When operating in the FIPS-CC configuration mode (as required for the evaluated configuration), the TOE automatically restricts the permitted key exchange methods to those that are specified in the Security Target. The Evaluated Configuration Guide (Ref. [10]) provides administrators with the commands necessary to configure the key exchange methods used for SSH connections. The evaluator shall attempt to perform a diffie-hellman-group1-sha1 key exchange, and observe that the attempt fails. For each allowed key exchange method, the evaluator shall then attempt to perform a key exchange using that method, and observe that the attempt succeeds. The evaluators attempted to connect to the TOE using DH Group 1 for the key exchange method. The TOE denied this connection attempt. The evaluators attempted to connect to the TOE using DH Group 14 for the key exchange method. The TOE permitted this connection attempt FCS_IPSEC_EXT.1 Extended: Internet Protocol Security (IPSec) Communications FCS_IPSEC_EXT.1.1 The evaluator shall examine the operational guidance to verify it instructs the Administrator how to construct entries into the SPD that specify a rule for DISCARD, BYPASS and PROTECT. Chapter 6 (Configuring Security Flow Policies) of the Evaluated Configuration Guide provides administrators with guidance and CLI examples for configuring security flow policies that contain each of the reactions listed above.

17 ASSURANCE ACTIVITY REPORT -JUNOS 12.3 X48-D30 FOR SRX XLR PLATFORMS PAGE 17 OF 66 The evaluator uses the operational guidance to configure the TOE and platform to carry out the following tests: 1. Test 1: The evaluator shall configure the SPD such that there is a rule for DISCARD, BYPASS, PROTECT. The selectors used in the construction of the rule shall be different such that the evaluator can send in three network packets with the appropriate fields in the packet header that each packet will match one of the three rules. The evaluator observes via the audit trail, and packet captures that the TOE exhibited the expected behavior: appropriate packet was dropped, allowed through without modification, was encrypted by the IPsec implementation; and 2. Test 2: The evaluator shall devise two equal SPD entries with alternate operations BYPASS and PROTECT. The entries should then be deployed in two distinct orders and in each case the evaluator shall ensure that the first entry is enforced in both cases by generating applicable packets and using packet capture and logs for confirmation. 3. Test 3: The evaluator shall repeat the procedure above, except that the two entries should be devised where one is a subset of the other (e.g., a specific address vs. a network segment). Again, the evaluator should test both orders to ensure that the first is enforced regardless of the specificity of the rule. The evaluators configured a number of security policies to test the DISCARD, BYPASS and PROTECT functionality of the TOE. The evaluators confirmed that the TOE reacted as expected and that appropriate audit log entries were generated. As the TOE does not permit the creation of distinct BYPASS/PROTECT rules, BYPASS/REJECT was used in place to demonstrate the ordering of rules. The evaluators confirmed that the TOE enforces security policies in the order defined by the administrator. The evaluators repeated the previous test using a subset-based configuration. The evaluators confirmed that the TOE enforced the rules in the order defined by the administrator FCS_IPSEC_EXT.1.2 The TOE supports tunnel mode only. The evaluator checks the to ensure it states that the VPN can be established to operate in tunnel mode and/or transport mode (as selected). The evaluator shall confirm that the operational guidance contains instructions on how to configure the connection in each mode selected. Per the ST, the TOE supports main mode only for IPsec connections. Chapter 7 of the Evaluated Configuration Guide (Configuring VPNs) provides numerous configuration examples and guidance to administrators on how to include main mode as part of an IPsec VPN configuration.

18 ASSURANCE ACTIVITY REPORT -JUNOS 12.3 X48-D30 FOR SRX XLR PLATFORMS PAGE 18 OF 66 The evaluator shall perform the following test(s) based on the selections chosen: 1. Test 1 (conditional): If tunnel mode is selected, the evaluator uses the operational guidance to configure the TOE to operate in tunnel mode and also configures a IPsec Peer to operate in tunnel mode. The evaluator configures the TOE and the IPsec Peer to use any of the allowable cryptographic algorithms, authentication methods, etc. to ensure an allowable SA can be negotiated. The evaluator shall then initiate a connection from the client to connect to the IPsec Peer. The evaluator observes (for example, in the audit trail and the captured packets) that a successful connection was established using the tunnel mode. 2. Test 2 (conditional): If transport mode is selected, the evaluator uses the operational guidance to configure the TOE to operate in transport mode and also configures a IPsec Peer to operate in transport mode. The evaluator configures the TOE and the IPsec Peer to use any of the allowed cryptographic algorithms, authentication methods, etc. to ensure an allowable SA can be negotiated. The evaluator then initiates a connection from the TOE to connect to the IPsec Peer. The evaluator observes (for example, in the audit trail and the captured packets) that a successful connection was established using the transport mode. The evaluators configured the TOE to establish an IPsec connection between itself and a peer using tunnel mode. The evaluator confirmed that the IPsec tunnel was established as configured and that the associated audit logs were generated FCS_IPSEC_EXT.1.3 The evaluator shall examine the to verify that the provides a description of how a packet is processed against the SPD and that if no rules are found to match, that a final rule exists, either implicitly or explicitly, that causes the network packet to be discarded. By default, the TOE denies all traffic through an SRX Series device. In fact, an implicit default security policy exists that denies all packets. You can change this behavior by configuring a standard security policy that permits certain types of traffic. The implicit default policy can be changed to permit all traffic with the 'set security policies defaultpolicy' command; however, this is not recommended. The evaluator checks that the operational guidance provides instructions on how to construct the SPD and uses the guidance to configure the TOE for the following tests. Chapter 7 of the Evaluated Configuration Guide (Configuring VPNs) provides numerous configuration examples and guidance.

19 ASSURANCE ACTIVITY REPORT -JUNOS 12.3 X48-D30 FOR SRX XLR PLATFORMS PAGE 19 OF 66 The evaluator shall configure the SPD such that it has entries that contain operations that DISCARD, BYPASS, and PROTECT network packets. The evaluator may use the SPD that was created for verification of FCS_IPSEC_EXT.1.1. The evaluator shall construct a network packet that matches a BYPASS entry and send that packet. The evaluator should observe that the network packet is passed to the proper destination interface with no modification. The evaluator shall then modify a field in the packet header; such that it no longer matches the evaluator-created entries (there may be a TOE created final entry that discards packets that do not match any previous entries). The evaluator sends the packet, and observes that the packet was not permitted to flow to any of the TOE s interfaces. The evaluators configured a number of traffic policies that met the requirements of this test. The evaluators sent traffic through the TOE that matched the BYPASS rule and confirmed that the TOE allowed the traffic to pass with no modification. The evaluators then constructed a junk packet that did not match any of the policies in place. The evaluators confirmed that the default-last-deny-and-log policy was enforced and the TOE automatically dropped and logged the traffic flow FCS_IPSEC_EXT.1.4 The evaluator shall examine the to verify that the symmetric encryption algorithms selected (along with the SHA-based HMAC algorithm, if AES-CBC is selected) are described. If selected, the evaluator ensures that the SHAbased HMAC algorithm conforms to the algorithms specified in FCS_COP.1(4) Cryptographic Operations (for keyed-hash message authentication. The TOE supports AES-GCM-128 and AES-GCM-256, and AES-CBC-128 or AES-CBC-256 using HMAC SHA-1 and SHA-256. Keyed-hash algorithms including HMAC-SHA1-96, HMAC-SHA can be configured for AES-CBC. The evaluator checks the operational guidance to ensure it provides instructions on how to configure the TOE to use the algorithms selected by the ST author. Chapter 7 (Configuring VPNs) of the Evaluated Configuration Guide provides a number of examples for both IPsec and IKE policy configuration. While the examples provided use default algorithms, the configuration syntax to select the other algorithms selected are provided. The evaluator shall configure the TOE as indicated in the operational guidance configuring the TOE to using each of the selected algorithms, and attempt to establish a connection using ESP. The connection should be successfully established for each algorithm. The evaluators configured the TOE to use each of the supported algorithms. The evaluators confirmed that, in each instance, a connection was established using ESP FCS_IPSEC_EXT.1.5 The evaluator shall examine the to verify that IKEv1 and/or IKEv2 are implemented. 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 mandatory support for NAT traversal as specified in section 2.23) and RFC 4868 for hash functions.

20 ASSURANCE ACTIVITY REPORT -JUNOS 12.3 X48-D30 FOR SRX XLR PLATFORMS PAGE 20 OF 66 The evaluator shall check the operational guidance to ensure it instructs the administrator how to configure the TOE to use IKEv1 and/or IKEv2 (as selected), and uses the guidance to configure the TOE to perform NAT traversal for the following test if IKEv2 is selected. Chapter 7 (Configuring VPNs) of the Evaluated Configuration Guide provides a number of examples for both IPsec and IKE policy configuration. These examples use IKEv1, but additional commands are also provided for administrators to configure the TOE to use IKEv2 instead. The evaluator shall configure the TOE/platform so that it will perform NAT traversal processing as described in the and RFC 5996, section The evaluator shall initiate an IPsec connection and determine that the NAT is successfully traversed. The evaluators configured a network environment such that NAT traversal was required for the establishment of an IPsec connection. The evaluators confirmed that the connection was established and NAT successfully traversed FCS_IPSEC_EXT.1.6 The evaluator shall ensure the identifies the algorithms used for encrypting the IKEv1 and/or IKEv2 payload, and that the algorithms AES- CBC-128, AES-CBC-256 are specified, and if others are chosen in the selection of the requirement, those are included in the discussion. The TOE supports AES-CBC-128, AES-CBC-256, AES-GCM-128 and AES-GCM-256 for payload protection in IKEv1 and IKEv2. The evaluator ensures that the operational guidance describes the configuration of the mandated algorithms, as well as any additional algorithms selected in the requirement. The guidance is then used to configure the TOE to perform the following test for each ciphersuite selected. Chapter 7 (Configuring VPNs) of the Evaluated Configuration Guide provides a number of examples for both IPsec and IKE policy configuration. While the examples provided uses aes-128-cbc as the encryption algorithm, the guidance indicates the values use if AES-256- CBC, AES-GCM-128 or AES-GCM-256 is to be used. The evaluator shall configure the TOE to use the ciphersuite under test to encrypt the IKEv1 and/or IKEv2 payload and establish a connection with a peer device, which is configured to only accept the payload encrypted using the indicated ciphersuite. The evaluator will confirm the algorithm was that used in the negotiation. The evaluators configured both the TOE and peer device to use AES-CBC-128 algorithm only for payload encryption. The evaluators confirmed, via TOE and peer output, that the connection was established and AES-128-CBC was the only algorithm used for payload encryption FCS_IPSEC_EXT.1.7 The evaluator shall examine the to ensure that, in the description of the IPsec protocol supported by the TOE, it states that aggressive mode is not used for IKEv1 Phase 1 exchanges, and that only main mode is used. It may be that this is a configurable option. In the evaluated configuration, the TOE permits only main mode to be configured for IKEv1 Phase 1 exchanges. There is no option to configure aggressive mode

21 ASSURANCE ACTIVITY REPORT -JUNOS 12.3 X48-D30 FOR SRX XLR PLATFORMS PAGE 21 OF 66 If the mode requires configuration of the TOE prior to its operation, the evaluator shall check the operational guidance to ensure that instructions for this configuration are contained within that guidance. Chapter 7 (Configuring VPNs) of the Evaluated Configuration Guide provides a number of examples for both IPsec and IKE policy configuration. All IKEv1 examples provided utilise main mode only. The evaluator shall configure the TOE as indicated in the operational guidance, and attempt to establish a connection using an IKEv1 Phase 1 connection in aggressive mode. This attempt should fail. The evaluator should then show that main mode exchanges are supported. This test is not applicable if IKEv1 is not selected above in the FCS_IPSEC_EXT.1.5 protocol selection. The evaluators configured the IPsec peer to attempt to establish an IKEv1 Phase 1 connection using aggressive mode. The TOE rejected this connection attempt. The evaluators established an IKEv1 connection between the TOE and a peer device. TOE and peer output confirmed that the connection was established using main mode FCS_IPSEC_EXT.1.8 The evaluator verifies that the values for SA lifetimes can be configured and that the instructions for doing so are located in the operational guidance. If time-based limits are supported, the evaluator ensures that the values allow for Phase 1 SAs values for 24 hours and 8 hours for Phase 2 SAs. Currently there are no values mandated for the number of packets or number of bytes, the evaluator just ensures that this can be configured if selected in the requirement. The following commands can be used to configure Phase 1 lifetimes in seconds or kilobytes: set security ike proposal <name> lifetime seconds <value> (180 to 86,400) set security ike proposal <name> lifetime kilobytes <value> (64 to 1,048,576) The following commands can be used to configure Phase 2 lifetimes in seconds or kilobytes: set security ike proposal <name> lifetime seconds <value> (180 to 86,400) set security ike proposal <name> lifetime kilobytes <value> (64 to 1,048,576)

22 ASSURANCE ACTIVITY REPORT -JUNOS 12.3 X48-D30 FOR SRX XLR PLATFORMS PAGE 22 OF 66 Each of the following tests shall be performed for each version of IKE selected in the FCS_IPSEC_EXT.1.5 protocol selection: 1. Test 1 (Conditional): The evaluator shall configure a maximum lifetime in terms of the # of packets (or bytes) allowed following the operational guidance. The evaluator shall establish an SA and determine that once the allowed # of packets (or bytes) through this SA is exceeded, the connection is closed. 2. Test 2 (Conditional): The evaluator shall construct a test where a Phase 1 SA is established and attempted to be maintained for more than 24 hours before it is renegotiated. The evaluator shall observe that this SA is closed or renegotiated in 24 hours or less. If such an action requires that the TOE be configured in a specific way, the evaluator shall implement tests demonstrating that the configuration capability of the TOE works as documented in the operational guidance. 3. Test 3 (Conditional): The evaluator shall perform a test similar to Test 1 for Phase 2 SAs, except that the lifetime will be 8 hours instead of 24. The evaluators configured maximum lifetimes in terms of bytes. The evaluators sent traffic through the IPsec tunnel and confirmed that, once the defined limit of bytes was met, the TOE closed and re-established the connection. The evaluators configured the TOE to enforce a Phase 1 SA lifetime of 24 hours. The evaluators confirmed that, after 24 hours, the connection was re-negotiated. The evaluators configured the TOE to enforce a Phase 2 SA lifetime of 8 hours. The evaluators confirmed that, after 8 hours, the connection was re-negotiated FCS_IPSEC_EXT.1.9 The evaluator shall check to ensure that the DH groups specified in the requirement are listed as being supported in the. If there is more than one DH group supported, the evaluator checks to ensure the describes how a particular DH group is specified/negotiated with a peer. 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 is no acceptable match is found. For each supported DH group, the evaluator shall test to ensure that all IKE protocols can be successfully completed using that particular DH group. The evaluators configured the TOE and an IPsec peer to use each supported Diffie-Hellman group. The evaluators confirmed that groups 14, 19, 20 and 24 were supported and that the connection was successfully established FCS_IPSEC_EXT.1.10