Security Target RUGGEDCOM ROS v4.2.2.F Reference Guide 08/2018 RC1407-EN-01 Introduction 1 Conformance Claims 2 Security Problem 3 Security Objectives for the Operational Environment 4 Extended Components 5 Security Requirements 6 TOE Summary Specification 7 Conformance Claims Rationale 8 Acronyms and Terms 9 Reference Guide ii Copyright © 2018 Siemens Canada Ltd Dissemination or reproduction of this document, or evaluation and communication of its contents, is permitted. Disclaimer Of Liability Siemens has verified the contents of this document against the hardware and/or software described. However, deviations between the product and the documentation may exist. Siemens shall not be liable for any errors or omissions contained herein or for consequential damages in connection with the furnishing, performance, or use of this material. The information given in this document is reviewed regularly and any necessary corrections will be included in subsequent editions. We appreciate any suggested improvements. We reserve the right to make technical improvements without notice. Registered Trademarks RUGGEDCOM™ and ROS™ are trademarks of Siemens Canada Ltd. Other designations in this manual might be trademarks whose use by third parties for their own purposes would infringe the rights of the owner. Third Party Copyrights Siemens recognizes the following third party copyrights: • Copyright © 2004 GoAhead Software, Inc. All Rights Reserved. Open Source RUGGEDCOM ROS contains Open Source Software. For license conditions, refer to the associated License Conditions document. Security Information Siemens provides products and solutions with industrial security functions that support the secure operation of plants, machines, equipment and/or networks. They are important components in a holistic industrial security concept. With this in mind, Siemens' products and solutions undergo continuous development. Siemens recommends strongly that you regularly check for product updates. For the secure operation of Siemens products and solutions, it is necessary to take suitable preventive action (e.g. cell protection concept) and integrate each component into a holistic, state-of-the-art industrial security concept. Third-party products that may be in use should also be considered. For more information about industrial security, visit https://www.siemens.com/industrialsecurity. To stay informed about product updates as they occur, sign up for a product-specific newsletter. For more information, visit https:// support.automation.siemens.com. Contacting Siemens Address Siemens Canada Ltd Industry Sector 300 Applewood Crescent Concord, Ontario Canada, L4K 5C7 Telephone Toll-free: 1 888 264 0006 Tel: +1 905 856 5288 Fax: +1 905 856 1995 E-mail ruggedcom.info.i-ia@siemens.com Web https://www.siemens.com/ruggedcom Reference Guide Table of Contents iii Table of Contents Chapter 1 Introduction ..................................................................................................... 1 1.1 Purpose ........................................................................................................................................ 1 1.2 Security Target and TOE References ............................................................................................... 2 1.3 Product Overview ......................................................................................................................... 2 1.4 TOE Overview ............................................................................................................................... 3 1.4.1 Management ..................................................................................................................... 3 1.4.2 TOE Environment ............................................................................................................... 3 1.5 TOE Description ............................................................................................................................ 4 1.5.1 Physical Scope ................................................................................................................... 4 1.5.1.1 TOE Hardware and Software .................................................................................... 5 1.5.1.2 Guidance Documentation ........................................................................................ 7 1.5.2 Logical Scope .................................................................................................................... 8 1.5.2.1 Security Audit ......................................................................................................... 8 1.5.2.2 Cryptographic Support ............................................................................................. 9 1.5.2.3 Identification and Authentication ............................................................................. 9 1.5.2.4 Security Management .............................................................................................. 9 1.5.2.5 Protection of the TSF ............................................................................................... 9 1.5.2.6 TOE Access ........................................................................................................... 10 1.5.2.7 Trusted Path/Channels ........................................................................................... 10 1.5.3 Excluded Functionality ...................................................................................................... 10 1.5.4 Scope of Evaluation ......................................................................................................... 11 Chapter 2 Conformance Claims ....................................................................................... 13 Chapter 3 Security Problem ............................................................................................. 15 3.1 Threats ....................................................................................................................................... 15 3.1.1 Communications with the Network Device ......................................................................... 15 3.1.1.1 Unauthorized Administrator Access ......................................................................... 16 3.1.1.2 Weak Cryptography ............................................................................................... 16 3.1.1.3 Untrusted Communication Channels ....................................................................... 17 3.1.1.4 Weak Authentication Endpoints .............................................................................. 17 3.1.2 Valid Updates .................................................................................................................. 18 Table of Contents Reference Guide iv 3.1.2.1 Update Compromise .............................................................................................. 18 3.1.3 Audited Activity ............................................................................................................... 18 3.1.3.1 Undetected Activity ............................................................................................... 19 3.1.4 Administrator and Device Credentials and Data .................................................................. 19 3.1.4.1 Security Functionality Compromise ......................................................................... 19 3.1.4.2 Password Cracking ................................................................................................ 20 3.1.5 Device Failure .................................................................................................................. 20 3.1.5.1 Security Functionality Failure ................................................................................. 20 3.2 Assumptions ............................................................................................................................... 21 3.2.1 Physical Protection ........................................................................................................... 21 3.2.2 Limited Functionality ........................................................................................................ 21 3.2.3 No Thru Traffic Protection ................................................................................................. 21 3.2.4 Trusted Administrator ....................................................................................................... 22 3.2.5 Regular Updates ............................................................................................................... 22 3.2.6 Admin Credentials Secure ................................................................................................. 22 3.2.7 Residual Information ........................................................................................................ 22 3.3 Organizational Security Policies .................................................................................................... 23 3.3.1 Access Banner .................................................................................................................. 23 Chapter 4 Security Objectives for the Operational Environment ....................................... 25 4.1 Physical ...................................................................................................................................... 25 4.2 No General Purpose .................................................................................................................... 25 4.3 No Thru Traffic Protection ........................................................................................................... 25 4.4 Trusted Admin ............................................................................................................................ 26 4.5 Updates ...................................................................................................................................... 26 4.6 Admin Credentials Secure ............................................................................................................ 26 4.7 Residual Information ................................................................................................................... 26 Chapter 5 Extended Components .................................................................................... 27 5.1 Extended TOE Security Functional Components ............................................................................. 27 5.1.1 Class FAU: Security Audit .................................................................................................. 28 5.1.1.1 FAU_STG_EXT: Protected Audit Event Storage .......................................................... 28 5.1.2 Class FCS: Cryptographic Support ...................................................................................... 29 5.1.2.1 FCS_RBG_EXT: Random Bit Generation .................................................................... 29 5.1.2.2 FCS_HTTPS_EXT.1 HTTPS Protocol ........................................................................... 30 5.1.2.3 FCS_SSHS_EXT.1 SSH Server Protocol ...................................................................... 31 5.1.2.4 FCS_TLSS_EXT TLS Server Protocol .......................................................................... 33 5.1.3 Class FIA: Identification and Authentication ........................................................................ 34 5.1.3.1 FIA_PMG_EXT: Password Management .................................................................... 34 Reference Guide Table of Contents v 5.1.3.2 FIA_UIA_EXT: User Identification and Authentication ................................................ 35 5.1.3.3 FIA_UAU_EXT: Password-based Authentication Mechanism ....................................... 36 5.1.3.4 FIA_X509_EXT: Authentication Using X.509 Certificates ........................................... 37 5.1.4 Class FPT: Protection of the TSF ........................................................................................ 39 5.1.4.1 FPT_SKP_EXT: Protection of TSF Data ...................................................................... 40 5.1.4.2 FPT_APW_EXT: Protection of Administrator Passwords .............................................. 40 5.1.4.3 FPT_TST_EXT: TSF Testing ...................................................................................... 41 5.1.4.4 FPT_TUD_EXT: Trusted Update ............................................................................... 42 5.1.4.5 FPT_STM_EXT: Reliable Time Stamps ....................................................................... 43 5.1.5 Class FTA: TOE Access ...................................................................................................... 44 5.1.5.1 FTA_SSL_EXT: TSF-initiated Session Locking ............................................................. 45 5.2 Extended TOE Security Assurance Components ............................................................................. 46 Chapter 6 Security Requirements .................................................................................... 47 6.1 Security Assurance Requirements ................................................................................................. 47 6.2 Conventions ............................................................................................................................... 48 6.3 Security Functional Requirements ................................................................................................ 48 6.3.1 Class FAU: Security Audit .................................................................................................. 50 6.3.2 Class FCS: Cryptographic Support ...................................................................................... 53 6.3.3 Class FIA: Identification and Authentication ........................................................................ 57 6.3.4 Class FMT: Security Management ...................................................................................... 60 6.3.5 Class FPT: Protection of the TSF ........................................................................................ 61 6.3.6 Class FTA: TOE Access ...................................................................................................... 63 6.3.7 Class FTP: Trusted Path/Channels ....................................................................................... 64 Chapter 7 TOE Summary Specification ............................................................................ 65 7.1 TOE Security Functionality ........................................................................................................... 65 7.1.1 Security Audit .................................................................................................................. 67 7.1.2 Cryptographic Support ...................................................................................................... 68 7.1.3 Identification and Authentication ...................................................................................... 71 7.1.4 Security Management ...................................................................................................... 73 7.1.5 Protection of the TSF ........................................................................................................ 75 7.1.6 TOE Access ...................................................................................................................... 77 7.1.7 Trusted Path/Channels ...................................................................................................... 77 Chapter 8 Conformance Claims Rationale ........................................................................ 79 8.1 Variance Between the PP and this ST ............................................................................................ 79 8.2 Security Assurance Requirements Rationale .................................................................................. 79 Table of Contents Reference Guide vi 8.3 Dependency Rationale ................................................................................................................. 79 Chapter 9 Acronyms and Terms ...................................................................................... 83 9.1 Acronyms ................................................................................................................................... 83 9.2 Terms ........................................................................................................................................ 85 Reference Guide Chapter 1 Introduction Purpose 1 Introduction This section identifies the Security Target (ST), Target of Evaluation (TOE), and the organization of the ST. The TOE is the Siemens Canada Ltd (Siemens) RUGGEDCOM ROS (Rugged Operating System) v4.2.2.F and will hereafter be referred to as the TOE. The TOE is a proprietary operating system designed for the RUGGEDCOM M2100F, M2200F, M969F, RSG2100F, RSG2100PF, RSG2200F, RSG2300F, RSG2300PF, RSG2488F, RS400F, RS416F, RS416PF, RS900F, RS900GF, RS900GPF, and RS940GF switches developed and built by Siemens. These RUGGEDCOM switches are designed specifically to withstand harsh environmental conditions including temperature and humidity extremes, shock, vibration, and electromagnetic interference. The ruggedized switches, equipped with RUGGEDCOM ROS, provide Ethernet switching capabilities for customer networks in virtually any environment. CONTENTS • Section 1.1, “Purpose” • Section 1.2, “Security Target and TOE References” • Section 1.3, “Product Overview” • Section 1.4, “TOE Overview” • Section 1.5, “TOE Description” Section 1.1 Purpose This ST is divided into nine sections, as follows: • Chapter 1, Introduction – Provides a brief summary of the ST contents and describes the organization of other sections within this document. It also provides an overview of the TOE security functionality and describes the physical and logical scope for the TOE as well as the ST and TOE references. • Chapter 2, Conformance Claims – Provides the identification of any Common Criteria (CC), Protection Profile (PP), and Evaluation Assurance Level (EAL) package claims. It also identifies whether the ST contains extended security requirements. • Chapter 3, Security Problem – Describes the threats, organizational security policies, and assumptions that pertain to the TOE and its environment • Chapter 4, Security Objectives for the Operational Environment – Identifies the security objectives that are satisfied by the TOE and its environment • Chapter 5, Extended Components – Identifies extended Security Functional Requirements (SFRs) and extended Security Assurance Requirements (SARs) that are not included in CC Part 2 or CC Part 3 • Chapter 6, Security Requirements – Presents the SARs met by the TOE ▫ Section 6.3, “Security Functional Requirements” – Presents the SFRs met by the TOE Chapter 1 Introduction Reference Guide 2 Security Target and TOE References • Chapter 7, TOE Summary Specification – Describes the security functions provided by the TOE that satisfy the security functional requirements and objectives • Chapter 8, Conformance Claims Rationale - Presents the rationale for the SFR dependencies as to their consistency, completeness, and suitability • Chapter 9, Acronyms and Terms – Defines the acronyms and terminology used within this ST Section 1.2 Security Target and TOE References Table 1 shows the ST and TOE references. Table 1: ST and TOE References ST Title Siemens Canada Ltd RUGGEDCOM ROS (Rugged Operating System) v4.2.2.F Security Target ST Version Version 1.3 ST Author Corsec Security, Inc. ST Publication Date August 13, 2018 TOE Reference Siemens RUGGEDCOM ROS v4.2.2.F running on the M2100F, M2200F, M969F, RSG2100F, RSG2100PF, RSG2200F, RSG2300F, RSG2300PF, RSG2488F, RS400F, RS416F, RS416PF, RS900F, RS900GF, RS900GPF, and RS940GF RUGGEDCOM switches CAVP Certificates See Section 7.1.2, “Cryptographic Support” Section 1.3 Product Overview The Product Overview provides a high-level description of this evaluation’s subject, Siemens RUGGEDCOM ROS running on the RUGGEDCOM switches. The following section, TOE Overview, provides the introduction to the parts of the overall product offering that are specifically being evaluated. RUGGEDCOM ROS may be deployed on any of the RUGGEDCOM switches listed in Section 1.5.1, “Physical Scope”. The RUGGEDCOM switches are highly configurable and can be customized with a number of different line module and power supply combinations. Customers choose a configuration that suits the targeted network and RUGGEDCOM assembles the RUGGEDCOM switches according to the specific configuration. The RUGGEDCOM switches are therefore able to operate in the most adverse conditions and are primarily deployed in power distribution, refineries, or traffic control systems. The RUGGEDCOM switches, equipped with the proprietary RUGGEDCOM ROS, provide switching capabilities for customer networks. Administrators provision and configure the switches using the management interfaces made available by RUGGEDCOM ROS described below in Section 1.4.1, “Management”. Reference Guide Chapter 1 Introduction TOE Overview 3 Section 1.4 TOE Overview The TOE Overview summarizes the usage and major security features of the TOE. The TOE Overview provides a context for the TOE evaluation by identifying the TOE type, describing the product, and defining the specific evaluated configuration. The TOE is a hardware and software TOE consisting of the RUGGEDCOM ROS running on the M2100F, M2200F, M969F, RSG2100F, RSG2100PF, RSG2200F, RSG2300F, RSG2300PF, RSG2488F, RS400F, RS416F, RS416PF, RS900F, RS900GF, RS900GPF, and RS940GF RUGGEDCOM switches. The purpose of the TOE is to provide Ethernet switching capabilities in a ruggedized enclosure for customer networks in virtually any environment. CONTENTS • Section 1.4.1, “Management” • Section 1.4.2, “TOE Environment” Section 1.4.1 Management Administrative access to the TOE is provided locally over the serial port and remotely over the Ethernet port(s). Administrators access the serial port using a terminal emulator over a direct serial connection to the RUGGEDCOM switch. The serial port provides access to a terminal-based menu system that includes the Command Line Interface (CLI), which is used for normal administrative operations. Administrators can also access the terminal-based menu remotely using SSH over an Ethernet connection. Administrators access a Web Graphical User Interface (web interface) using HTTPS over an Ethernet connection for normal administrative operations. Using SFTP, Administrators may remotely read and write configuration files; write the SSL server certificate, SSH host keys, and SSH user public keys; update the Certificate Authority (CA) truststore; and may remotely read the audit log (read- only access). Section 1.4.2 TOE Environment The TOE needs the following environmental components in order to function properly: • The cables and connectors that allow administrators and environmental components to communicate with the TOE • An audit server with autossh script installed that will securely receive the audit logs from the TOE • An OCSP server • A management workstation with a standards-compliant client web browser to access the web interface over HTTPS and the terminal-based menu using SSH • A firewall between the TOE and the external network, if connected to a public network The TOE is intended to be deployed in a secure data center that protects physical access to the TOE. The TOE is intended to be interconnected by a back-end private network that does not connect directly to external hosts. Chapter 1 Introduction Reference Guide 4 TOE Description Section 1.5 TOE Description This section primarily addresses the physical and logical components of the TOE that are included in the evaluation. CONTENTS • Section 1.5.1, “Physical Scope” • Section 1.5.2, “Logical Scope” • Section 1.5.3, “Excluded Functionality” • Section 1.5.4, “Scope of Evaluation” Section 1.5.1 Physical Scope Figure 1 illustrates the physical scope and the physical boundary of the overall solution and ties together all of the components of the TOE and the constituents of the TOE Environment. The TOE is composed of both the RUGGEDCOM switch hardware and the RUGGEDCOM ROS software. Figure 1: Physical TOE Boundary CONTENTS • Section 1.5.1.1, “TOE Hardware and Software” • Section 1.5.1.2, “Guidance Documentation” Reference Guide Chapter 1 Introduction TOE Hardware and Software 5 Section 1.5.1.1 TOE Hardware and Software The TOE is a hardware and software TOE. For the evaluated configuration, the TOE software (RUGGEDCOM ROS v4.2.2.F) were installed and run in the following TOE hardware configurations: Table 2: TOE Models Tested Configuration Model HW ID/CPU/Description Line Card Configuration 2x 10FL – Multimode, 850nm, ST, 2km 2x 100FX – Multimode, 1300nm, ST, 2km 2x 100FX – Singlemode, 1310nm, ST, 20km M2100F RSG2100v2 NXP ColdFire MCF5272 M2100FIPS-CC 2x 10/100TX – Micro-D 2x 10/100TX – RJ45 2x 10FL – Multimode, 850nm, ST, 2km 2x 100FX – Multimode, 1300nm, ST, 2km 2x 100FX – Singlemode, 1310nm, LC, 90km 2x 10/100TX – Micro-D 2x 10/100/1000TX – RJ45 RSG2100F RSG2100v2 NXP ColdFire MCF5272 RSG2100FIPS-CC 1x 1000SX – Multimode, 850nm, LC, 500m 2x 10/100TX – RJ45 2x 100FX – Multimode, 1300nm, ST, 2km 2x 100FX – Multimode, 1300nm, MTRJ, 2km 2x 100FX – Singleimode, 1310nm, SC, 90km 2x 1000LX – Singleimode, 1310nm, LC, 25km 1x 1000SX – Multimode, 850nm, LC, 500m 2x 10/100TX – Micro-D RSG2100PF RSG2100v2 NXP ColdFire MCF5272 RSG2100PFIPS-CC 2x 10/100TX – Micro-D 2x 10/100/1000TX – Micro-D 2x 1000SX – Multimode, 850nm, LC, 500m 2x 1000LX – Singlemode, 1310nm, LC, 25km 2x 10/100/1000TX – Micro-D M2200F RSG2200 NXP ColdFire MCF5272 M2200FIPS-CC 2x 10/100/1000TX – Micro-D 2x 10/100/1000TX – RJ45 2x 1000SX – Multimode, 850nm, LC, 500m 2x 1000LX – Singlemode, 1310nm, LC, 25 km 2x 1000SX – Multimode, 850nm, LC, 500m RSG2200F RSG2200 NXP ColdFire MCF5272 RSG2200FIPS-CC 1x 100FX – Multimode, 1300nm, MTRJ, 2km RSG2300F RSG2300 2x 10/100TX – RJ45 Chapter 1 Introduction Reference Guide 6 TOE Hardware and Software Model HW ID/CPU/Description Line Card Configuration 2x 100FX – Multimode, 1300nm, MTRJ, 2km 2x 1000SX – Multimode, 850nm, LC, 500m NXP ColdFire MCF5272 RSG2300FIPS-CC 2x 10/100/1000TX – RJ45 2x 10/100TX – RJ45 2x 10/100TX – RJ45 2x 1000SX – Multimode, 850nm, LC, 500m RSG2300PF RSG2300 NXP ColdFire MCF5272 RSG2300PFIPS-CC 2x 100FX – Multimode, 1300nm, MTRJ, 2km 4x 10/100/1000TX – RJ45 4x 10/100/1000TX – M12 X-Coded 4x 1000SX – Multimode, 850nm, LC, 500m 4x 1000SX – Multimode, 850nm, LC, 500m 4x 1000LX – Singlemode, 1310nm, LC, 25km 1x Precision Time Protocol (PTP) Module 2x 10/100/1000TX – RJ45 RSG2488F RSG2488v2 NXP PowerQUICC MPC8308 RSG2488FIPS-CC 2x 10/100/1000TX – M12 X-Coded 4x 10FL – Multimode, 850nm, ST, 2km 4x RS232/RS422/RS485 & IRIG-B DB9 4x RS232/RS422/RS485 & IRIG-B RJ45 2x 10/100TX – RJ45 1x IRIG-B in – BNC RS416F RSG416v2 NXP ColdFire MCF5272 RS416FIPS-CC 1x IRIG-B out – BNC (Slot 5 only) 4x 10FL – Multimode, 850nm, ST, 2km 4x RS232/RS422/RS485 & IRIG-B DB9 4x RS232/RS422/RS485 & IRIG-B RJ45 1x IRIG-B in – BNC 1x IRIG-B out – BNC (Slot 5 only) RS416PF RS416v2 NXP ColdFire MCF5272 RS416PFIPS-CC 2x 10/100TX – RJ45 100FX – Multimode, 1310nm, LC, 2km 1x 100FX – Singlemode, 1300nm, LC, 20km RS400F RS400 (40-00-0010 Rev C1) NXP ColdFire MCF5272 RS400FIPS-CC 4x RS232/RS422/RS485 – DB9 RS940GF RS940G (40-00-0097-000 Rev A) NXP ColdFire MCF5272 RS940GFIPS-CC 2x 1000SX – Multimode, 850nm, LC, 500m RS900GF RS900Gv2 NXP ColdFire MCF5272 2x 1000LX – Singlemode, 1310nm, LC, 25km Reference Guide Chapter 1 Introduction Guidance Documentation 7 Model HW ID/CPU/Description Line Card Configuration RS900FIPS-CC RS900GPF RS900GP NXP ColdFire MCF5272 RS900GFIPS-CC 2x 1000LX – Singlemode, 1310nm, SC, 25km 2x 100FX – Multimode, 1300nm, ST, 2km 1x 100FX – Singlemode, 1310nm, ST, 20km RS900F RS900v3, Fiber NXP ColdFire MCF5272 RS900FIPS-CC 1x 100FX – Multimode, 1300nm, SC, 2km M969F RS969 (v2, 40-00-0090) NXP ColdFire MCF5272 M969FIPS-CC 2x 1000SX – Multimode, 850nm, LC, 500m Table 2 lists the RUGGEDCOM switches evaluated configuration. The line models on each switch model are configurable and the tested configurations provide a sample of possible configurations. The line modules provide 10/100/1000BaseTX Ethernet, serial, and fiber interfaces that are used to send and receive user data. The line modules provide nothing more than the physical interface. Section 1.5.1.2 Guidance Documentation Table 3 lists the TOE Guidance Documentation to install, configure, and maintain the TOE. Table 3: Guidance Documentation Document Name Description Siemens RUGGEDCOM M2100F Installation Guide, 05/2018, RC1342-EN-1 Siemens RUGGEDCOM M2200F Installation Guide, 05/2018, RC1343-EN-1 Siemens RUGGEDCOM M969F Installation Guide, 05/2018, RC1349-EN-1 Siemens RUGGEDCOM RSG2100F Installation Guide, 05/2018, RC1344-EN-1 Siemens RUGGEDCOM RSG2200F Installation Guide, 05/2018, RC1346-EN-1 Siemens RUGGEDCOM RSG2100PF Installation Guide, 05/2018, RC1345-EN-1 Siemens RUGGEDCOM RSG2300F Installation Guide, 05/2018, RC1347-EN-1 Siemens RUGGEDCOM RSG2300PF Installation Guide, 05/2018, RC1348-EN-1 Siemens RUGGEDCOM RSG2488F Installation Guide, 05/2018, RC1351-EN-1 Siemens RUGGEDCOM RS400F Installation Guide, 05/2018, RC1341-EN-1 Siemens RUGGEDCOM RS416F Installation Guide, 05/2018, RC1354-EN-1 Siemens RUGGEDCOM RS416PF Installation Guide, 05/2018, RC1355-EN-1 Siemens RUGGEDCOM RS900GF Installation Guide, 05/2018, RC1352-EN-1 Siemens RUGGEDCOM RS900GPF Installation Guide, 05/2018, RC1353-EN-1 Siemens RUGGEDCOM RS900F Installation Guide, 05/2018, RC1350-EN-1 Siemens RUGGEDCOM RS940GF Installation Guide, 05/2018, RC1356-EN-1 Includes steps for the basic initialization and setup of the TOE. Siemens RUGGEDCOM ROS v4.2.2.F User Guide for RSG2100F, RSG2100PF, M2100F, 05/2018, RC1234-EN-1 Siemens RUGGEDCOM ROS v4.2.2.F User Guide for RSG2200F, M2200F, 05/2018, RC1235- EN-1 Siemens RUGGEDCOM ROS v4.2.2.F User Guide for RS969F, M969F, 05/2018, RC1233-EN-1 Contains detailed steps for how to properly configure and maintain the TOE. Chapter 1 Introduction Reference Guide 8 Logical Scope Document Name Description Siemens RUGGEDCOM ROS v4.2.2.F User Guide for RSG2300F, RSG2300PF, 05/2018, RC1236-EN-1 Siemens RUGGEDCOM ROS v4.2.2.F User Guide for RSG2488F, 05/2018, RC1237-EN-1 Siemens RUGGEDCOM ROS v4.2.2.F User Guide for RS400F, 05/2018, RC1300-EN-1 Siemens RUGGEDCOM ROS v4.2.2.F User Guide for RS416F, RS416PF, 05/2018, RC1228-EN-1 Siemens RUGGEDCOM ROS v4.2.2.F User Guide for RS900GF, 05/2018, RC1229-EN-1 Siemens RUGGEDCOM ROS v4.2.2.F User Guide for RS900GPF, 05/2018, RC1230-EN-1 Siemens RUGGEDCOM ROS v4.2.2.F User Guide for RS900F, 05/2018, RC1231-EN-1 Siemens RUGGEDCOM ROS v4.2.2.F User Guide for RS940GF, 05/2018, RC1232-EN-1 Siemens Canada Ltd RUGGEDCOM ROS (Rugged Operating System) v4.2.2.F Guidance Documentation Supplement v0.6 Contains information regarding specific configuration for the TOE evaluated configuration. Siemens RUGGEDCOM ROS Devices Security Policy, v0.14, August 16, 2017 Contains details on FIPS mode configurations and taper evidence validation. FAQ - "How to Implement Secure, Unattended Logging in ROS" Contains steps to setup and maintain secure audit logging on the TOE. Section 1.5.2 Logical Scope The logical boundary of the TOE will be broken down into the following security classes which are further described in Section 6.3, “Security Functional Requirements” and Chapter 7, TOE Summary Specification of this ST. The logical scope also provides the description of the security features of the TOE. The security functional requirements implemented by the TOE are usefully grouped under the following Security Function Classes: CONTENTS • Section 1.5.2.1, “Security Audit” • Section 1.5.2.2, “Cryptographic Support” • Section 1.5.2.3, “Identification and Authentication” • Section 1.5.2.4, “Security Management” • Section 1.5.2.5, “Protection of the TSF” • Section 1.5.2.6, “TOE Access” • Section 1.5.2.7, “Trusted Path/Channels” Section 1.5.2.1 Security Audit The TOE generates audit records for security-relevant actions of the authorized administrators accessing the TOE via the terminal-based menu and web interface. The TOE records the identity of the administrator responsible for the log event, where applicable. To remotely and securely backup the audit logs, an Administrator can configure the syslog server to call into the TOE and request audit log files be printed to the syslog server over an SSH connection. The connection to the audit server is secured using SSH. When logs are filled, the TOE overwrites in Reference Guide Chapter 1 Introduction Cryptographic Support 9 two possible ways: the oldest log record can be overwritten with the new log record or the oldest log file can be overwritten with the new log file. Section 1.5.2.2 Cryptographic Support The Cryptographic Support TOE Security Function (TSF) provides cryptographic functions to establish web interface sessions (secured with HTTPS) and terminal sessions (secured with SSH) between an administrator’s management workstation and the TOE. Cryptographic functions are also provided when the external audit server requests an SSH session with the TOE to protect the transfer of audit messages. Lastly, cryptographic functions are used to establish SFTP sessions to import keys and certificates. The cryptographic operations necessary to support this TSF are provided by Siemens’s proprietary cryptographic module (for list of CAVP Certificates see Section 7.1.2, “Cryptographic Support”). In addition, the TOE provides a variety of cryptographic algorithms for its own use. Keys are zeroized by overwriting with zeros. The TOE is limited by hardware on SSH rekeys. See Section 7.1.2, “Cryptographic Support” for more details. Section 1.5.2.3 Identification and Authentication The TOE provides functionality that requires administrators to verify their claimed identity. The Identification and Authentication TSF ensures that only authorized administrators can gain access to the configuration settings and management settings of the TOE. Administrators can only view the access banner prior to authenticating with a valid user name and password. The TOE requires administrators to use strong passwords. The TOE provides no feedback to Administrators when they are entering their passwords at the login prompt of the terminal-based menu for both direct serial remote SSH connections. The TOE does present feedback in the form of bullets (‘•’) over the web interface and in the form of an ‘x’ over the terminal interface. Administrators using password-based authentication are locked out after a configurable number of unsuccessful authentication attempts and must wait a configurable period of time before they are unlocked. The TOE can present a certificate to authenticate to external entities and this certificate and the trust anchor certificate are stored within a truststore. Certificate revocation status is verified on certificates uploaded to the TOE using an external OCSP server. Section 1.5.2.4 Security Management The TOE provides a web interface and a terminal-based menu for administrators to manage the security functions, configuration, and other features of the TOE. The security management function specifies user roles with defined access for the management of the TOE components. Updating the TOE, modifying the configuration file, configuring the access banner, setting the inactivity timeout, configuring authentication failure parameters, configuring time and re-enabling the Administrator account are all functions restricted to the Security Administrator. Section 1.5.2.5 Protection of the TSF The TOE invokes a set of self-tests each time the TOE is powered on to ensure that the TSF operates correctly. The TOE also provides a reliable timestamp for its own use. An Administrator can manually set the time for the TOE. A digital signature using an RSA public key is used to verify all software updates that are applied to the TOE. The Chapter 1 Introduction Reference Guide 10 TOE Access TOE prevents an administrator from reading the keys stored in the TOE. Passwords are stored in obfuscated form to prevent them from being read in plaintext. Section 1.5.2.6 TOE Access The TOE terminates local and remote management sessions after an administrator-configurable time period of inactivity. The TOE also provides administrator’s the capability to manually terminate the session prior to the inactivity timeout. After an administrator’s session is terminated, the administrator must log in again to regain access to TOE functionality. A login banner is displayed at the login screen of the web interface and prior to authentication over the terminal-based menu. Section 1.5.2.7 Trusted Path/Channels The cryptographic functionality of the TOE provides the TOE the ability to create trusted paths and trusted channels. The TOE implements a trusted channel using SSH between itself and a remote server in order to protect the audit logs as they are being sent. Additionally, the TOE provides trusted paths between administrators and the web interface via HTTPS and the terminal-based menu via SSH. The management communication channels between the TOE and a remote entity are distinct from network data communication channels and provide mutual identification and authentication. In addition, the communications are protected from modification and disclosure. Section 1.5.3 Excluded Functionality The following services were not part of the evaluated configuration and were not tested: • Virtual Local Area Network configuration • Port configuration • Broadcast Storm filtering • Quality of Service based on part, tag, MAC16, or IP type of service • Multiple Spanning Tree Protocol • Rapid Spanning Tree Protocol • Enhanced Rapid Spanning Tree Protocol The following services are present in the TOE but are excluded in this evaluation: • RADIUS • TACACS+ • RSH • Telnet • TFTP • ModBus management • Remote Syslog Reference Guide Chapter 1 Introduction Scope of Evaluation 11 • Management connections over SNMP15 v1, v2, and v3 • Management via HTTP • Network Time Protocol (NTP) time synchronization and service • RUGGEDCOM Discovery Protocol (RCDP) 1 • IP forwarding Section 1.5.4 Scope of Evaluation The evaluation is limited in scope to the secure management features described in collaborative Protection Profile for Network Devices v2.0 + Errata 20180314, 14-March-2018 (ND cPP) and detailed in Section 1.5.2, “Logical Scope”. 1 RCDP has been disabled and removed from all command and debugging interfaces. Chapter 1 Introduction Reference Guide 12 Scope of Evaluation Reference Guide Chapter 2 Conformance Claims 13 Conformance Claims This section provides the identification for any CC, Protection Profile (PP), Technical Decisions (TD), and EAL package conformance claims. Rationale is provided for any extensions or augmentations to the conformance claims. Rationale for CC and PP conformance claims can be found in Chapter 8, Conformance Claims Rationale. Table 4: CC and PP Conformance Common Criteria (CC) Identification and Conformance Common Criteria for Information Technology Security Evaluation, Version 3.1, Revision 4, September 2012; CC Part 2 extended; CC Part 3 conformant; PP claim to the Collaborative Protection Profile for Network Devices v2.0 + Errata 20180314, March 14, 2018 conformant; and no interpretations apply to the claims made in this ST. PP Identification Exact Conformance a to the collaborative Protection Profile for Network Devices, v2.0 + Errata 20180314. TD Conformance Conformance to TD0228, TD0259, TD0260, TD0262, TD0281, TD0290, TD0291, TD0321, and TD0324 are claimed. a Exact Conformance is a type of Strict Conformance such that the set of SFRs and the SPD/Objectives are exactly as presented within the accepted NDPP without changes. Chapter 2 Conformance Claims Reference Guide 14 Reference Guide Chapter 3 Security Problem Threats 15 Security Problem This section describes the security aspects of the environment in which the TOE will be used and the manner in which the TOE is expected to be employed. CONTENTS • Section 3.1, “Threats” • Section 3.2, “Assumptions” • Section 3.3, “Organizational Security Policies” Section 3.1 Threats The threats for the Network Device are grouped according to functional area of the device in the sections below. CONTENTS • Section 3.1.1, “Communications with the Network Device” • Section 3.1.2, “Valid Updates” • Section 3.1.3, “Audited Activity” • Section 3.1.4, “Administrator and Device Credentials and Data” • Section 3.1.5, “Device Failure” Section 3.1.1 Communications with the Network Device A network device communicates with other network devices and other network entities. The endpoints of this communication can be geographically and logically distant and may pass through a variety of other systems. The intermediate systems may be untrusted providing an opportunity for unauthorized communication with the network device or for authorized communication to be compromised. The security functionality of the network device must be able to protect any critical network traffic (administration traffic, authentication traffic, audit traffic, etc.). The communication with the network device falls into two categories: authorized communication and unauthorized communication. Authorized communication includes network traffic allowable by policy destined to and originating from the network device as it was designed and intended. This includes critical network traffic, such as network device administration and communication with an authentication or audit logging server, which requires a secure channel to protect the communication. The security functionality of the network device includes the capability to ensure that only authorized communications are allowed and the capability to provide a secure channel for critical Chapter 3 Security Problem Reference Guide 16 Unauthorized Administrator Access network traffic. Any other communication with the network device is considered unauthorized communication. (Network traffic traversing the network device but not ultimately destined for the device, e.g. packets that are being routed, are not considered to be “communications with the network device” – cf. Section 3.2.3, “No Thru Traffic Protection”.) The primary threats to network device communications addressed in this collaborative Protection Profile (cPP) focus on an external, unauthorized entity attempting to access, modify, or otherwise disclose the critical network traffic. A poor choice of cryptographic algorithms or the use of non-standardized tunneling protocols along with weak administrator credentials, such as an easily guessable password or use of a default password, will allow a threat agent unauthorized access to the device. Weak or no cryptography provides little to no protection of the traffic allowing a threat agent to read, manipulate and/or control the critical data with little effort. Non- standardized tunneling protocols not only limit the interoperability of the device but also lack the assurance and confidence standardization provides through peer review. CONTENTS • Section 3.1.1.1, “Unauthorized Administrator Access” • Section 3.1.1.2, “Weak Cryptography” • Section 3.1.1.3, “Untrusted Communication Channels” • Section 3.1.1.4, “Weak Authentication Endpoints” Section 3.1.1.1 Unauthorized Administrator Access 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. SFR Rationale: • The Administrator role is defined in FMT_SMR.2 and the relevant administration capabilities are defined in FMT_SMF.1 and FMT_MTD.1/CoreData • The actions allowed before authentication of an Administrator are constrained by FIA_UIA_EXT.1, and include the advisory notice and consent warning message displayed according to FTA_TAB.1 • The requirement for the Administrator authentication process is described in FIA_UAU_EXT.2 • Locking of Administrator sessions is ensured by FTA_SSL_EXT.1 (for local sessions), FTA_SSL.3 (for remote sessions), and FTA_SSL.4 (for all interactive sessions) • The secure channels used for remote Administrator connections is specified in FTP_TRP.1/Admin Section 3.1.1.2 Weak Cryptography 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. Reference Guide Chapter 3 Security Problem Untrusted Communication Channels 17 SFR Rationale: • Requirements for key generation and key distribution are set in FCS_CKM.1 and FCS_CKM.2 respectively Requirements for use of cryptographic schemes are set in FCS_COP.1/DataEncryption, FCS_COP.1/SigGen, FCS_COP.1/Hash, and FCS_COP.1/KeyedHash Requirements for random bit generation to support key generation and secure protocols (see SFRs resulting from T.UNTRUSTED_COMMUNICATION_CHANNELS) are set in FCS_RBG_EXT.1 Management of cryptographic functions is specified in FMT_SMF.1 Section 3.1.1.3 Untrusted Communication Channels Threat agents may attempt to target network devices that do not use standardized secure tunneling 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. SFR Rationale: • The general use of secure protocols for identified communication channels is described at the top level in FTP_ITC.1 and FTP_TRP.1/Admin; for distributed TOEs the requirements for inter-component communications are addressed by the requirements in FPT_ITT.1 • Requirements for the use of secure communication protocols are set for all the allowed protocols in FCS_HTTPS_EXT.1, FCS_SSHS_EXT.1, FCS_TLSS_EXT.1 • Optional and selection-based requirements for use of public key certificates to support secure protocols are defined in FIA_X509_EXT.1, FIA_X509_EXT.2, FIA_X509_EXT.3 Section 3.1.1.4 Weak Authentication Endpoints Threat agents may take advantage of secure protocols that use weak methods to authenticate the endpoints – e.g., 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. SFR Rationale: • The use of appropriate secure protocols to provide authentication of endpoints (as in the SFRs addressing T.UNTRUSTED_COMMUNICATION_CHANNELS) are ensured by the requirements in FTP_ITC.1 and FTP_TRP.1/ Admin; for distributed TOEs the authentication requirements for endpoints in inter-component communications are addressed by the requirements in FPT_ITT.1. Chapter 3 Security Problem Reference Guide 18 Valid Updates Section 3.1.2 Valid Updates Updating network device software and firmware is necessary to ensure that the security functionality of the network device is maintained. The source and content of an update to be applied must be validated by cryptographic means; otherwise, an invalid source can write its own firmware or software updates that circumvents the security functionality of the network device. Methods of validating the source and content of a software or firmware update by cryptographic means typically involve cryptographic signature schemes where hashes of the updates are digitally signed. Unpatched versions of software or firmware leave the network device susceptible to threat agents attempting to circumvent the security functionality using known vulnerabilities. Non-validated updates or updates validated using non-secure or weak cryptography leave the updated software or firmware vulnerable to threat agents attempting to modify the software or firmware to their advantage. CONTENTS • Section 3.1.2.1, “Update Compromise” Section 3.1.2.1 Update Compromise 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. SFR Rationale: • Requirements for protection of updates are set in FPT_TUD_EXT.1 Requirements for management of updates are defined in FMT_SMF.1 and (for manual updates) in FMT_MOF.1/ ManualUpdate Section 3.1.3 Audited Activity Auditing of network device activities is a valuable tool for administrators to monitor the status of the device. It provides the means for administrator accountability, security functionality activity reporting, reconstruction of events, and problem analysis. Processing performed in response to device activities may give indications of a failure or compromise of the security functionality. When indications of activity that impact the security functionality are not generated and monitored, it is possible for such activities to occur without administrator awareness. Further, if records are not generated and retained, reconstruction of the network and the ability to understand the extent of any compromise could be negatively affected. Additional concerns are the protection of the audit data that is recorded from alteration or unauthorized deletion. This could occur within the TOE or while the audit data is in transit to an external storage device. Note this cPP requires that the network device generate the audit data and have the capability to send the audit data to a trusted network entity (e.g., a syslog server). CONTENTS • Section 3.1.3.1, “Undetected Activity” Reference Guide Chapter 3 Security Problem Undetected Activity 19 Section 3.1.3.1 Undetected Activity 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 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. SFR Rationale: • Requirements for basic auditing capabilities are specified in FAU_GEN.1 and FAU_GEN.2, with timestamps provided according to FPT_STM_EXT.1 • Requirements for protecting audit records stored on the TOE are specified in FAU_STG.1 • Requirements for secure transmission of local audit records to an external IT entity via a secure channel are specified in FAU_STG_EXT.1 Section 3.1.4 Administrator and Device Credentials and Data A network device contains data and credentials which must be securely stored and must appropriately restrict access to authorized entities. Examples include the device firmware, software, configuration authentication credentials for secure channels, and administrator credentials. Device and administrator keys, key material, and authentication credentials need to be protected from unauthorized disclosure and modification. Furthermore, the security functionality of the device needs to require default authentication credentials, such as administrator passwords, be changed. Lack of secure storage and improper handling of credentials and data, such as unencrypted credentials inside configuration files or access to secure channel session keys, can allow an attacker to not only gain access to the network device but also compromise the security of the network through seemingly authorized modifications to configuration or through man-in-the-middle attacks. These attacks allow an unauthorized entity to gain access and perform administrative functions using the Security Administrator’s credentials and to intercept all traffic as an authorized endpoint. This results in difficulty in detection of security compromise and in reconstruction of the network, potentially allowing continued unauthorized access to administrator and device data. CONTENTS • Section 3.1.4.1, “Security Functionality Compromise” • Section 3.1.4.2, “Password Cracking” Section 3.1.4.1 Security Functionality Compromise Threat agents may compromise credentials and device data enabling continued access to the network device and its critical data. The compromise of credentials include replacing existing credentials with an attacker’s credentials, modifying existing credentials, or obtaining the administrator or device credentials for use by the attacker. SFR Rationale: • Protection of secret/private keys against compromise is specified in FPT_SKP_EXT.1 • Secure destruction of keys is specified in FCS_CKM.4 Chapter 3 Security Problem Reference Guide 20 Password Cracking • If (optionally) management of keys is provided by the TOE then this is specified in FMT_SMF.1, and confining this functionality to Security Administrators is required by FMT_MTD.1/CryptoKeys Section 3.1.4.2 Password Cracking 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. SFR Rationale: • Requirements for password lengths and available characters are set in FIA_PMG_EXT.1 • Protection of password entry by providing only obscured feedback is specified in FIA_UAU.7 • Actions on reaching a threshold number of consecutive password failures are specified in FIA_AFL.1 • Requirements for secure storage of passwords are set in FPT_APW_EXT.1. Section 3.1.5 Device Failure Security mechanisms of the network device generally build up from roots of trust to more complex sets of mechanisms. Failures could result in a compromise to the security functionality of the device. A network device self-testing its security critical components at both start-up and during run-time ensures the reliability of the device’s security functionality. CONTENTS • Section 3.1.5.1, “Security Functionality Failure” Section 3.1.5.1 Security Functionality Failure 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. SFR Rationale: • Requirements for running self-test(s) are defined in FPT_TST_EXT.1 Reference Guide Chapter 3 Security Problem Assumptions 21 Section 3.2 Assumptions This section describes the assumptions made in identification of the threats and security requirements for network devices. The network device is not expected to provide assurance in any of these areas, and as a result, requirements are not included to mitigate the threats associated. CONTENTS • Section 3.2.1, “Physical Protection” • Section 3.2.2, “Limited Functionality” • Section 3.2.3, “No Thru Traffic Protection” • Section 3.2.4, “Trusted Administrator” • Section 3.2.5, “Regular Updates” • Section 3.2.6, “Admin Credentials Secure” • Section 3.2.7, “Residual Information” Section 3.2.1 Physical Protection 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. [OE.PHYSICAL] Section 3.2.2 Limited Functionality 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). [OE.NO_GENERAL_PURPOSE] Section 3.2.3 No Thru Traffic Protection A standard/generic network device does not provide any assurance regarding the protection of traffic that traverses it. The intent is for the network device to protect data that originates on or is destined to the device itself, to include administrative data and audit data. Traffic that is traversing the network device, destined for Chapter 3 Security Problem Reference Guide 22 Trusted Administrator another network entity, is not covered by the ND cPP. It is assumed that this protection will be covered by cPPs for particular types of network devices (e.g, firewall). [OE.NO_THRU_TRAFFIC_PROTECTION] Section 3.2.4 Trusted Administrator 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. [OE.TRUSTED_ADMIN] Section 3.2.5 Regular Updates 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. [OE.UPDATES] Section 3.2.6 Admin Credentials Secure The administrator’s credentials (private key) used to access the network device are protected by the platform on which they reside. [OE.ADMIN_CREDENTIALS_SECURE] Section 3.2.7 Residual Information 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. [OE.RESIDUAL_INFORMATION] Reference Guide Chapter 3 Security Problem Organizational Security Policies 23 Section 3.3 Organizational Security Policies An organizational security policy (OSP) is a set of rules, practices, and procedures imposed by an organization to address its security needs. For the purposes of this cPP, a single policy is described in the section below. CONTENTS • Section 3.3.1, “Access Banner” Section 3.3.1 Access Banner 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. [FTA_TAB.1] Chapter 3 Security Problem Reference Guide 24 Access Banner Reference Guide Chapter 4 Security Objectives for the Operational Environment Physical 25 Security Objectives for the Operational Environment The following subsections describe objectives for the Operational Environment. CONTENTS • Section 4.1, “Physical” • Section 4.2, “No General Purpose” • Section 4.3, “No Thru Traffic Protection” • Section 4.4, “Trusted Admin” • Section 4.5, “Updates” • Section 4.6, “Admin Credentials Secure” • Section 4.7, “Residual Information” Section 4.1 Physical Physical security, commensurate with the value of the TOE and the data it contains, is provided by the environment. Section 4.2 No General Purpose 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. Section 4.3 No Thru Traffic Protection The TOE does not provide any protection of traffic that traverses it. It is assumed that protection of this traffic will be covered by other security and assurance measures in the operational environment. Chapter 4 Security Objectives for the Operational Environment Reference Guide 26 Trusted Admin Section 4.4 Trusted Admin TOE Administrators are trusted to follow and apply all guidance documentation in a trusted manner. Section 4.5 Updates 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. Section 4.6 Admin Credentials Secure The administrator’s credentials (private key) used to access the TOE must be protected on any other platform on which they reside. Section 4.7 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. Reference Guide Chapter 5 Extended Components Extended TOE Security Functional Components 27 Extended Components This section defines the extended SFRs and extended SARs met by the TOE. These requirements are presented following the conventions identified in Section 6.2, “Conventions”. This section contains the definitions for the extended requirements that are used in the cPP, including those used in Chapter 6, Security Requirements and Section 6.3, “Security Functional Requirements”. CONTENTS • Section 5.1, “Extended TOE Security Functional Components” • Section 5.2, “Extended TOE Security Assurance Components” Section 5.1 Extended TOE Security Functional Components This section specifies the extended SFRs for the TOE. The extended SFRs are organized by class. Table 5 identifies all extended SFRs implemented by the TOE. Table 5: Extended TOE Security Functional Requirements Name Description FAU_STG_EXT.1 Protected Audit Event Storage FCS_RBG_EXT.1 Random Bit Generation FCS_HTTPS_EXT.1 HTTPS Protocol FCS_SSHS_EXT.1 SSH Server FCS_TLSS_EXT.1 TLS Server Protocol FIA_PMG_EXT.1 Password Management FIA_UIA_EXT.1 User Identification and Authentication FIA_UAU_EXT.2 Password-based Authentication Mechanism FIA_X509_EXT.1/REV X.509 Certificate Validation FIA_X509_EXT.2 X.509 Certificate Authentication FIA_X509_EXT.3 X.509 Certificate Request FPT_SKP_EXT.1 Protection of TSF data (for reading of all symmetric keys) FPT_APW_EXT.1 Protection of Administrator Passwords FPT_STM_EXT.1 Reliable time stamps FPT_TST_EXT.1 TSF Testing Chapter 5 Extended Components Reference Guide 28 Class FAU: Security Audit Name Description FPT_TUD_EXT.1 Trusted Update FTA_SSL_EXT.1 TSF-initiated session locking CONTENTS • Section 5.1.1, “Class FAU: Security Audit” • Section 5.1.2, “Class FCS: Cryptographic Support” • Section 5.1.3, “Class FIA: Identification and Authentication” • Section 5.1.4, “Class FPT: Protection of the TSF” • Section 5.1.5, “Class FTA: TOE Access” Section 5.1.1 Class FAU: Security Audit Families in this class address the requirements for functions to implement security audit as defined in Chapter 2, Conformance Claims. CONTENTS • Section 5.1.1.1, “FAU_STG_EXT: Protected Audit Event Storage” Section 5.1.1.1 FAU_STG_EXT: Protected Audit Event Storage Family Behavior This component defines the requirements for the TSF to be able to securely transmit audit data between the TOE and an external IT entity. Component Leveling Figure 2: Protected Audit Event Storage Family Decomposition FAU_STG_EXT.1 Protected audit event storage requires the TSF to use a trusted channel implementing a secure protocol. Reference Guide Chapter 5 Extended Components Class FCS: Cryptographic Support 29 Management: FAU_STG_EXT.1 The following actions could be considered for the management functions in FMT: a. The TSF shall have the ability to configure the connection to the external IT entity Audit: FAU_STG_EXT.1 The following actions should be auditable if FAU_GEN Security audit data generation is included in the cPP/ST: a. No audit necessary FAU_STG_EXT.1 Protected Audit Event Storage Hierarchical to: No other components Dependencies: AU_GEN.1 Audit data generation FTP_ITC.1 Inter-TSF trusted channel • 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 • FAU_STG_EXT.1.2 The TSF shall be able to store generated audit data on the TOE itself • FAU_STG_EXT.1.3 The TSF shall [selection: drop new audit data, overwrite previous audit records according to the following rule: [assignment: rule for overwriting previous audit records], [assignment: other action]] when the local storage space for audit data is full Section 5.1.2 Class FCS: Cryptographic Support Families in this class address the requirements for functions to implement cryptographic functionality as defined in Chapter 2, Conformance Claims. CONTENTS • Section 5.1.2.1, “FCS_RBG_EXT: Random Bit Generation” • Section 5.1.2.2, “FCS_HTTPS_EXT.1 HTTPS Protocol” • Section 5.1.2.3, “FCS_SSHS_EXT.1 SSH Server Protocol” • Section 5.1.2.4, “FCS_TLSS_EXT TLS Server Protocol” Section 5.1.2.1 FCS_RBG_EXT: Random Bit Generation Family Behavior Components in this family address the requirements for random number / bit generation. This is a new family defined for the FCS Class. Chapter 5 Extended Components Reference Guide 30 FCS_HTTPS_EXT.1 HTTPS Protocol Component Leveling Figure 3: Random Bit Generation Family Decomposition FCS_RBG_EXT.1 Random Bit Generation requires random bit generation to be performed in accordance with selected standards and seeded by an entropy source. Management: FCS_RBG_EXT.1 The following actions could be considered for the management functions in FMT: a. There are no management activities foreseen Audit: FCS_RBG_EXT.1 The following actions should be auditable if FAU_GEN Security audit data generation is included in the cPP/ST: a. There are no auditable events foreseen FCS_RBG_EXT.1 Random Bit Generation Hierarchical to: No other components Dependencies: No dependencies • FCS_RBG_EXT.1.1 The TSF shall perform all deterministic random bit generation services in accordance with ISO/IEC 18031:2011 using [selection: Hash_DRBG (any), HMAC_DRBG (any), CTR_DRBG (AES)] • FCS_RBG_EXT.1.2 The deterministic RBG23 shall be seeded by at least one entropy source that accumulates entropy from [selection: [assignment: number of software-based sources] software-based noise source, [assignment: number of hardware-based sources] hardware-based noise source] with a minimum of [selection: 128 bits, 192 bits, 256 bits] of entropy at least equal to the greatest security strength, according to ISO/IEC 18031:2011, of the keys and CSP that it will generate Section 5.1.2.2 FCS_HTTPS_EXT.1 HTTPS Protocol Family Behavior Components in this family define the requirements for protecting remote management sessions between the TOE and a Security Administrator. This family describes how HTTPS will be implemented. This is a new family defined for the FCS Class. Reference Guide Chapter 5 Extended Components FCS_SSHS_EXT.1 SSH Server Protocol 31 Component Leveling Figure 4: HTTPS Protocol Family FCS_HTTPS_EXT.1 HTTPS requires that HTTPS be implemented according to RFC24 2818 and supports TLS. Management: FCS_HTTPS_EXT.1 The following actions could be considered for the management functions in FMT: a. There are no management activities foreseen Audit: FCS_HTTPS_EXT.1 The following actions should be auditable if FAU_GEN Security audit data generation is included in the cPP/ST: a. There are no auditable events foreseen FFCS_HTTPS_EXT.1 HTTPS Protocol Hierarchical to: No other components Dependencies: FCS_TLS_EXT.1 TLS Protocol • FCS_HTTPS_EXT.1.1 The TSF shall implement the HTTPS protocol that complies with RFC 2818 • FCS_HTTPS_EXT.1.2 The TSF shall implement the HTTPS protocol using TLS • FCS_HTTPS_EXT.1.3 If a peer certificate is presented, the TSF shall [selection: not establish the connection, request authorization to establish the connection, [assignment: other action]] if the peer certificate is deemed invalid Section 5.1.2.3 FCS_SSHS_EXT.1 SSH Server Protocol Family Behavior The component in this family addresses the ability for a server to offer SSH to protect data between a client and the server using the SSH protocol Chapter 5 Extended Components Reference Guide 32 FCS_SSHS_EXT.1 SSH Server Protocol Component Leveling Figure 5: SSH Server Protocol Family Decomposition FCS_SSHS_EXT.1 SSH Server requires that the server side of SSH be implemented as specified. Management: FCS_SSHS_EXT.1 The following actions could be considered for the management functions in FMT: a. There are no management activities foreseen Audit: FCS_SSHS_EXT.1 The following actions should be auditable if FAU_GEN Security audit data generation is included in the cPP/ST: a. Failure of SSH session establishment b. SSH session establishment c. SSH session termination FCS_SSHS_EXT.1 SSH Server Protocol Hierarchical to: No other components Dependencies: FCS_COP.1(1) Cryptographic operation (AES Data encryption/decryption) FCS_COP.1(2) Cryptographic operation (Signature Verification) FCS_COP.1(3) Cryptographic Operation (Hash Algorithm) • FCS_SSHS_EXT.1.1 The TSF shall implement the SSH protocol that complies with [RFC(s) [selection: 4251, 4252, 4253, 4254, 5647, 5656, 6187, 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 [assignment: number of bytes] 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: [assignment: encryption algorithms] • FCS_SSHS_EXT.1.5 The TSF shall ensure that the SSH public-key based authentication implementation uses [selection: ssh-rsa, ecdsa-sha2-nistp256] and [selection: ecdsa-sha2-nistp384, ecdsa-sha2-nistp521, x509v3-ecdsa-sha2-nistp256, x509v3-ecdsa-sha2-nistp384, x509v3-ecdsa-sha2-nistp521, no other public key algorithms] as its public key algorithm(s) and rejects all other public key algorithms Reference Guide Chapter 5 Extended Components FCS_TLSS_EXT TLS Server Protocol 33 • FCS_SSHS_EXT.1.6 The TSF shall ensure that the SSH transport implementation uses [assignment: : list of MAC algorithms] as its MAC algorithm(s) and rejects all other MAC algorithm(s) • FCS_SSHS_EXT.1.7 The TSF shall ensure that [assignment: list of key exchange methods] 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 no more than one gigabyte of transmitted data. After either of the thresholds are reached a rekey needs to be performed Section 5.1.2.4 FCS_TLSS_EXT TLS Server Protocol Family Behavior The component in this family addresses the ability for a server to use TLS to protect data between a client and the server using the TLS protocol Component Leveling Figure 6: TLS Server Protocol Family Decomposition FCS_TLSS_EXT.1 TLS Server requires that the server side of TLS be implemented as specified. Management: FCS_SSHS_EXT.1 The following actions could be considered for the management functions in FMT: a. There are no management activities foreseen Audit: FCS_TLSS_EXT.1 The following actions should be auditable if FAU_GEN Security audit data generation is included in the cPP/ST: a. Failure of TLS session establishment b. TLS session establishment c. TLS session termination FCS_TLSS_EXT.1 TLS Server Protocol Hierarchical to: No other components Dependencies: FCS_CKM.1 Cryptographic Key Generation Chapter 5 Extended Components Reference Guide 34 Class FIA: Identification and Authentication FCS_COP.1(1) Cryptographic operation (AES Data encryption/decryption) FCS_COP.1(2) Cryptographic operation (Signature Verification) FCS_COP.1(3) Cryptographic Operation (Hash Algorithm) FCS_RBG_EXT.1 Random Bit Generation • FCS_TLSS_EXT.1.1 The TSF shall implement [selection: TLS 1.2 (RFC 5246), TLS 1.1 (RFC 4346)] and reject all other TLS and SSL versions. The TLS implementation will support the following ciphersuites: ▫ [assignment: List of optional ciphersuites and reference to RFC in which each is defined] • FCS_TLSS_EXT.1.2 The TSF shall deny connections from clients requesting SSL 2.0, SSL 3.0, TLS 1.0 and [selection: TLS 1.1, TLS 1.2, none]. • FCS_TLSS_EXT.1.3 The TSF shall [selection: perform RSA key establishment with key size [selection: 2048 bits, 3072 bits, 4096 bits]; generate EC Diffie-Hellman parameters over NIST curves [selection: secp256r1, secp384r1, secp521r1] and no other curves; generate Diffie-Hellman parameters of size [selection: 2048 bits, 3072 bits]] Section 5.1.3 Class FIA: Identification and Authentication Families in this class address the requirements for functions to establish and verify a claimed user identity as defined in Chapter 2, Conformance Claims. CONTENTS • Section 5.1.3.1, “FIA_PMG_EXT: Password Management” • Section 5.1.3.2, “FIA_UIA_EXT: User Identification and Authentication” • Section 5.1.3.3, “FIA_UAU_EXT: Password-based Authentication Mechanism” • Section 5.1.3.4, “FIA_X509_EXT: Authentication Using X.509 Certificates” Section 5.1.3.1 FIA_PMG_EXT: Password Management Family Behavior The TOE defines the attributes of passwords used by administrative users to ensure that strong passwords and passphrases can be chosen and maintained. Component Leveling Figure 7: Password Management Family Decomposition Reference Guide Chapter 5 Extended Components FIA_UIA_EXT: User Identification and Authentication 35 FIA_PMG_EXT.1 Password management requires the TSF to support passwords with varying composition requirements, minimum lengths, maximum lifetime, and similarity constraints. Management: FIA_PMG_EXT.1 The following actions could be considered for the management functions in FMT: a. The ability to configure the password length Audit: FIA_PMG_EXT.1 The following actions should be auditable if FAU_GEN Security audit data generation is included in the cPP/ST: a. There are no auditable events foreseen FIA_PMG_EXT.1 Password Management Hierarchical to: No other components Dependencies: No dependencies • 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: [selection: “!”, “@”, “#”, “$”, “%”, “^”, “&”, “*”, “(”, “)”, [assignment: other characters]] b. Minimum password length shall be configurable to [assignment: minimum number of characters supported by the TOE] and [assignment: number of characters greater than or equal to 15] Section 5.1.3.2 FIA_UIA_EXT: User Identification and Authentication Family Behavior The TSF allows certain specified actions before the non-TOE entity goes through the identification and authentication process. Component Leveling Figure 8: User Identification and Authentication Family Decomposition FFIA_UIA_EXT.1 User Identification and Authentication requires administrators (including remote administrators) to be identified and authenticated by the TOE, providing assurance for that end of the communication path. It also ensures that every user is identified and authenticated before the TOE performs any mediated functions. Chapter 5 Extended Components Reference Guide 36 FIA_UAU_EXT: Password-based Authentication Mechanism Management: FIA_UIA_EXT.1 The following actions could be considered for the management functions in FMT: a. Ability to configure the list of TOE services available before an entity is identified and authenticated Audit: FIA_UIA_EXT.1 The following actions should be auditable if FAU_GEN Security audit data generation is included in the cPP/ST: a. All use of the identification and authentication mechanism b. Provided user identity, origin of the attempt (e.g. IP address) FIA_UIA_EXT.1 User Identification and Authentication Hierarchical to: No other components Dependencies: FTA_TAB.1 Default TOE Access Banners • 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 ▫ [selection: no other actions, [assignment: list of services, actions performed by the TSF in response to non- TOE requests.]] • 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 Section 5.1.3.3 FIA_UAU_EXT: Password-based Authentication Mechanism Family Behavior Provides for a locally based administrative user authentication mechanism. Component Leveling Figure 9: Password-based Authentication Mechanism Family Decomposition FIA_UAU_EXT.2 The password-based authentication mechanism provides administrative users a locally based authentication mechanism. Reference Guide Chapter 5 Extended Components FIA_X509_EXT: Authentication Using X.509 Certificates 37 Management: FIA_UAU_EXT.2 The following actions could be considered for the management functions in FMT: a. None Audit: FIA_UAU_EXT.2 The following actions should be auditable if FAU_GEN Security audit data generation is included in the cPP/ST: a. Minimal: All use of the authentication mechanism FIA_UAU_EXT.2 Password-based Authentication Mechanism Hierarchical to: No other components Dependencies: No other components • FIA_UAU_EXT.2.1 The TSF shall provide a local password-based authentication mechanism, and [selection: [assignment: other authentication mechanism(s)], no other authentication mechanism] to perform administrative user authentication Section 5.1.3.4 FIA_X509_EXT: Authentication Using X.509 Certificates Family Behavior This family defines the behavior, management, and use of X.509 certificates for functions to be performed by the TSF. Components in this family require validation of certificates according to a specified set of rules, use of certificates for authentication for protocols and integrity verification, and the generation of certificate requests. Component Leveling Figure 10: User Identification and Authentication Family Decomposition FIA_X509_EXT.1/REV X509 Certificate Validation, requires the TSF to check and validate certificates in accordance with the RFCs and rules specified in the component. Chapter 5 Extended Components Reference Guide 38 FIA_X509_EXT: Authentication Using X.509 Certificates FIA_X509_EXT.2 X509 Certificate Authentication, requires the TSF to use certificates to authenticate peers in protocols that support certificates, as well as for integrity verification and potentially other functions that require certificates. IA_X509_EXT.3 X509 Certificate Requests, requires the TSF to be able to generate Certificate Request Messages and validate responses. Management: FIA_X509_EXT.1/REV, FIA_X509_EXT.2, FIA_X509_EXT.3 The following actions could be considered for the management functions in FMT: a. Remove imported X.509v3 certificate b. Approve import and removal of X.509v3 certificates c. Initiate certificate requests Audit: FIA_X509_EXT.1/REV, FIA_X509_EXT.2, FIA_X509_EXT.3 The following actions should be auditable if FAU_GEN Security audit data generation is included in the cPP/ST: a. Minimal: No specific audit requirements are specified FIA_X509_EXT.1/REV X.509 Certificate Validation Hierarchical to: No other components Dependencies: No other components • 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 certificate path must terminate with a trusted CA certificate ▫ The TSF shall validate a certificate path by ensuring the presence of the basicConstraints extension and that the CA flag is set to TRUE for all CA certificates ▫ The TSF shall validate the revocation status of the certificate using [selection: the Online Certificate Status Protocol (OCSP) as specified in RFC 6069, a Certificate Revocation List (CRL) as specified in RFC 5280 Section 6.3, Certificate Revocation List (CRL) as specified in RFC 5759 Section 5, no revocation method] ▫ The TSF shall validate the extendedKeyUsage field according to the following rules: • 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 • 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 • 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 • 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 Reference Guide Chapter 5 Extended Components Class FPT: Protection of the TSF 39 FIA_X509_EXT.2 X.509 Certificate Authentication Hierarchical to: No other components Dependencies: No other components • FIA_X509_EXT.2.1 The TSF shall use X.509v3 certificates as defined by RFC 5280 to support authentication for [selection: IPsec, TLS, HTTPS, SSH, DTLS], and [selection: code signing for system software updates, code signing for integrity verification, [assignment: other uses], no additional uses] • FIA_X509_EXT.2.2 When the TSF cannot establish a connection to determine the validity of a certificate, the TSF shall [selection: allow the administrator to choose whether to accept the certificate in these cases, accept the certificate, not accept the certificate] FIA_X509_EXT.3 X.509 Certificate Requests Hierarchical to: No other components Dependencies: No other components • FIA_X509_EXT.3.1 The TSF shall generate a Certificate Request Message as specified by RFC 2986 and be able to provide the following information in the request: public key and [selection: device-specific information, Common Name, Organization, Organizational Unit, Country, [assignment: other information]]. • FIA_X509_EXT.3.2 The TSF shall validate the chain of certificates from the Root CA upon receiving the CA Certificate Response Section 5.1.4 Class FPT: Protection of the TSF Families in this class address the requirements for functions providing integrity and management of mechanisms that constitute the TSF and of the TSF data as defined in Chapter 2, Conformance Claims. CONTENTS • Section 5.1.4.1, “FPT_SKP_EXT: Protection of TSF Data” • Section 5.1.4.2, “FPT_APW_EXT: Protection of Administrator Passwords” • Section 5.1.4.3, “FPT_TST_EXT: TSF Testing” • Section 5.1.4.4, “FPT_TUD_EXT: Trusted Update” • Section 5.1.4.5, “FPT_STM_EXT: Reliable Time Stamps” Chapter 5 Extended Components Reference Guide 40 FPT_SKP_EXT: Protection of TSF Data Section 5.1.4.1 FPT_SKP_EXT: Protection of TSF Data Family Behavior Components in this family address the requirements for managing and protecting TSF data, such as cryptographic keys. This is a new family modelled after the FPT_PTD Class. Component Leveling Figure 11: Protection of TSF Data (for Reading of Symmetric Keys) Family Decomposition FPT_SKP_EXT.1 Protection of TSF Data (for reading all symmetric keys), requires preventing symmetric keys from being read by any user or subject. It is the only component of this family. Management: FPT_SKP_EXT.1 The following actions could be considered for the management functions in FMT: a. There are no management activities foreseen Audit: FPT_SKP_EXT.1 The following actions should be auditable if FAU_GEN Security audit data generation is included in the cPP/ST: a. There are no auditable events foreseen FFPT_SKP_EXT.1 Protection of TSF Data (for Reading of All Pre-shared Symmetric and Private Keys) Hierarchical to: No other components Dependencies: No dependencies • FPT_SKP_EXT.1.1 The TSF shall prevent reading of all pre-shared keys, symmetric keys, and private keys Section 5.1.4.2 FPT_APW_EXT: Protection of Administrator Passwords Family Behavior Components in this family ensure that the TSF will protect plaintext credential data such as passwords from unauthorized disclosure. Reference Guide Chapter 5 Extended Components FPT_TST_EXT: TSF Testing 41 Component Leveling Figure 12: Protection of Administrator Passwords FPT_APW_EXT.1 Protection of administrator passwords, requires the TOE not to store passwords in plaintext. It was modeled after FPT_SSP.1. Management: FPT_APW_EXT.1 The following actions could be considered for the management functions in FMT: a. There are no management activities foreseen Audit: FPT_APW_EXT.1 The following actions should be auditable if FAU_GEN Security audit data generation is included in the cPP/ST: a. There are no auditable events foreseen FPT_APW_EXT.1 Protection of Administrator Passwords Hierarchical to: No other components Dependencies: No other components • FPT_APW_EXT.1.1 The TSF shall store passwords in non-plaintext form • FPT_APW_EXT.1.2 The TSF shall prevent the reading of plaintext passwords Section 5.1.4.3 FPT_TST_EXT: TSF Testing Family Behavior Components in this family address the requirements for self-testing the TSF for selected correct operation. Component Leveling Figure 13: TSF Testing Family Decomposition Chapter 5 Extended Components Reference Guide 42 FPT_TUD_EXT: Trusted Update FPT_TST _EXT.1: TSF Self-Test requires a suite of self-tests to be run during initial start-up in order to demonstrate correct operation of the TSF. Management: FPT_TST_EXT.1 The following actions could be considered for the management functions in FMT: a. No management functions Audit: FPT_TST_EXT.1 The following actions should be auditable if FAU_GEN Security audit data generation is included in the cPP/ST: a. Indication that TSF self test was completed FPT_TST_EXT.1 TSF Testing Hierarchical to: No other components Dependencies: No other components • FPT_TST_EXT.1.1 The TSF shall run a suite of the following self-tests [selection: during initial start-up (on power on), periodically during normal operation, at the request of the authorised user, at the conditions [assignment: conditions under which self-tests should occur]] to demonstrate the correct operation of the TSF: [assignment: list of self-tests run by the TSF] Section 5.1.4.4 FPT_TUD_EXT: Trusted Update Family Behavior Components in this family address the requirements for updating the TOE firmware and/or software. Component Leveling Figure 14: Trusted Update Family Decomposition FPT_TUD_EXT.1 Trusted Update requires management tools be provided to update the TOE firmware and software, including the ability to verify the updates prior to installation. Management: FPT_TUD_EXT.1 The following actions could be considered for the management functions in FMT: Reference Guide Chapter 5 Extended Components FPT_STM_EXT: Reliable Time Stamps 43 a. Ability to update the TOE and to verify the updates b. Ability to update the TOE and to verify the updates using the digital signature capability (FCS_COP.1(2)) and [selection: no other functions, [assignment: other cryptographic functions (or other functions) used to support the update capability]] c. Ability to update the TOE and to verify the updates using [selection: digital signature, published hash, no other mechanism] capability prior to installing those updates Audit: FPT_TUD_EXT.1 The following actions should be auditable if FAU_GEN Security audit data generation is included in the cPP/ST: a. Initiation of the update process b. Any failure to verify the integrity of the update FPT_TUD_EXT.1 Trusted Update Hierarchical to: No other components Dependencies: FCS_COP.1/SigGen Cryptographic operation (for cryptographic signature), or FCS_COP.1/Hash Cryptographic operation (for cryptographic hashing) • FPT_TUD_EXT.1.1 The TSF shall provide [assignment: Administrators] the ability to query the currently executing version of the TOE firmware/software and [selection: the most recently installed version of the TOE firmware/software; no other TOE firmware/software version]. • FPT_TUD_EXT.1.2 The TSF shall provide [assignment: Administrators] the ability to manually initiate updates to TOE firmware/ software and [selection: support automatic checking for updates, support automatic updates, no other update mechanism] • FPT_TUD_EXT.1.3 The TSF shall provide means to authenticate firmware/software updates to the TOE using a [selection: digital signature mechanism, published hash] prior to installing those updates Section 5.1.4.5 FPT_STM_EXT: Reliable Time Stamps Family Behavior Components in this family address the requirements for maintaining a reliable time stamp. Chapter 5 Extended Components Reference Guide 44 Class FTA: TOE Access Component Leveling Figure 15: Reliable Time Stamp Family Decomposition FPT_STM_EXT.1 Reliable Time Stamp requires that the TSF provide a reliable time stamp and allows for Administrator to set time and configure synchronization with an external time source. Management: FPT_STM_EXT.1 The following actions could be considered for the management functions in FMT: a. Ability to set the TOE time b. Administrator setting of the time Audit: FPT_STM_EXT.1 The following actions should be auditable if FAU_GEN Security audit data generation is included in the cPP/ST: a. Discontinuous changes to time – either administrator actuated or changed via automated process FPT_STM_EXT.1 Reliable Time Stamp Hierarchical to: No other components Dependencies: No other components • 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 [selection: allow the Security Administrator to set the time, synchronize time with external sources] Section 5.1.5 Class FTA: TOE Access Families in this class specify functional requirements for controlling the establishment of a user’s session as defined in Chapter 2, Conformance Claims. CONTENTS • Section 5.1.5.1, “FTA_SSL_EXT: TSF-initiated Session Locking” Reference Guide Chapter 5 Extended Components FTA_SSL_EXT: TSF-initiated Session Locking 45 Section 5.1.5.1 FTA_SSL_EXT: TSF-initiated Session Locking Family Behavior Components in this family address the requirements for TSF-initiated and user-initiated locking, unlocking, and termination of interactive sessions. The extended FTA_SSL_EXT family is based on the FTA_SSL family. Component Leveling Figure 16: TSF-initiated Session Locking Family Decomposition FTA_SSL_EXT.1: TSF-initiated session locking, requires system initiated locking of an interactive session after a specified period of inactivity. It is the only component of this family. Management: FTA_SSL_EXT.1 The following actions could be considered for the management functions in FMT: a. Specification of the time of user inactivity after which lock-out occurs for an individual user Audit: FTA_SSL_EXT.1 The following actions should be auditable if FAU_GEN Security audit data generation is included in the cPP/ST: a. Any attempts at unlocking an interactive session FTA_SSL_EXT.1 TSF-initiated Session Locking Hierarchical to: No other components Dependencies: FIA_UAU.1 timing of authentication • FTA_SSL_EXT.1.1 The TSF shall, for local interactive sessions, [selection: ▫ lock the session – disable any activity of the user’s data access/display devices other than unlocking the session, and requiring that the administrator re-authenticate to the TSF prior to unlocking the session; ▫ terminate the session] after a Security Administrator-specified time period of inactivity Chapter 5 Extended Components Reference Guide 46 Extended TOE Security Assurance Components Section 5.2 Extended TOE Security Assurance Components There are no extended TOE Security Assurance Components. Reference Guide Chapter 6 Security Requirements Security Assurance Requirements 47 Security Requirements This cPP identifies the SFRs and SARs to be met by the TOE. These requirements are described in the sections below. CONTENTS • Section 6.1, “Security Assurance Requirements” • Section 6.2, “Conventions” • Section 6.3, “Security Functional Requirements” Section 6.1 Security Assurance Requirements The SARs identified in the cPP frame the extent to which the evaluator assesses the documentation applicable for the evaluation and performs independent testing. This section lists the set of SARs from CC Part 3 that are required in evaluations against this cPP. Individual Evaluation Activities to be performed are specified in the Supporting Document (SD), Mandatory Technical Document, Evaluation Activities for Network Device cPP. The TOE security assurance requirements are identified in Table 6. Table 6: Security Assurance Requirements Assurance Requirements 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) Security Target (ASE) TOE summary specification (ASE_TSS.1) Development (ADV) Basic functional specification (ADV_FSP.1) Operational user guidance (AGD_OPE.1) Guidance documents (AGD) Preparative procedures (AGD_PRE.1) Labeling of the TOE (ALC_CMC.1) Life Cycle Support (ALC) TOE Configuration Management coverage (ALC_CMS.1) Tests (ATE) Independent testing – sample (ATE_IND.1) Chapter 6 Security Requirements Reference Guide 48 Conventions Assurance Requirements Vulnerability assessment (AVA) Vulnerability survey (AVA_VAN.1) Section 6.2 Conventions The conventions used in descriptions of the SFRs are as follows: • Assignment: Indicated with italicized text • Refinement made by PP author: Indicated with bold text and strikethroughs, if necessary • Selection: Indicated with underlined text • Assignment within a Selection: Indicated with italicized and underlined text • Iteration: Indicated by appending the iteration number in parenthesis, e.g., (1), (2), (3) and/or by adding a string starting with “/” • Extended SFRs are identified by having a label “EXT” at the end of the SFR name • Operations such as assignments and selections performed by the PP author are identified as shown above; however, do not appear within brackets. This is done intentionally to delineate between selections/assignments made by the PP author and those made by the ST author. No refinements have been made by the ST author other than grammatical and/or formatting corrections, or in places where a table reference differs from that of the PP. Section 6.3 Security Functional Requirements The individual security functional requirements are specified in the sections below. SFRs in this section are mandatory SFRs that any conformant TOE must meet. Based on selections made in these SFRs, it will also be necessary to include some of the selection-based SFRs in Appendix B. Additional optional SFRs may also be adopted from those listed in Appendix A. The Evaluation Activities defined in [SD] describe actions that the evaluator will take in order to determine compliance of a particular TOE with the SFRs. The content of these Evaluation Activities will therefore provide more insight into deliverables required from TOE Developers. This section specifies the SFRs for the TOE. This section organizes the SFRs by CC class. Table 7 identifies all SFRs implemented by the TOE and indicates the ST operations performed on each requirement. Table 7: TOE Security Functional Requirements Name Description S a A b R c I d FAU_GEN.1 Audit data generation ü ü FAU_GEN.2 User identity association FAU_STG_EXT.1 Protected Audit Event Storage ü ü FCS_CKM.1 Cryptographic Key Generation ü ü FCS_CKM.2 Cryptographic Key Establishment ü ü Reference Guide Chapter 6 Security Requirements Security Functional Requirements 49 Name Description S a A b R c I d FCS_CKM.4 Cryptographic Key Destruction ü FCS_COP.1/ DataEncryption Cryptographic Operation (AES Data Encryption/ Decryption) ü ü FCS_COP.1/SigGen Cryptographic Operation (Signature Generation and Verification) ü ü ü ü FCS_COP.1/Hash Cryptographic Operation (Hash Algorithm) ü ü ü FCS_COP.1/Keyed Hash Cryptographic Operation (Keyed Hash Algorithm) ü ü ü ü FCS_HTTPS_EXT.1 HTTPS Protocol ü FCS_SSHS_EXT.1 SSH Server ü ü FCS_TLSS_EXT.1 TLS Server Protocol ü FCS_RBG_EXT.1 Random Bit Generation ü ü FIA_AFL.1 Authentication Failure Management ü ü FIA_PMG_EXT.1 Password Management ü ü FIA_UIA_EXT.1 User Identification and Authentication ü ü FIA_UAU_EXT.2 Password-based Authentication Mechanism ü ü FIA_UAU.7 Protected Authentication Feedback ü FIA_X509_EXT.1/REV X.509 Certificate Validation ü ü FIA_X509_EXT.2 X.509 Certificate Authentication ü ü FIA_X509_EXT.3 X.509 Certificate Requests ü FMT_MOF.1/ ManualUpdate Management of security functions behavior ü FMT_MTD.1/CoreData Management of TSF data ü FMT_SMF.1 Specification of management functions ü FMT_SMR.2 Restrictions on Security Roles FPT_APW_EXT.1 Protection of Administrator Passwords FPT_SKP_EXT.1 Protection of TSF Data (for reading of all symmetric keys) FPT_STM_EXT.1 Reliable Time Stamps FPT_TST_EXT.1 TSF testing ü ü FPT_TUD_EXT.1 Trusted Update ü ü 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 ü FTP_ITC.1 Inter-TSF Trust Channel ü ü ü Chapter 6 Security Requirements Reference Guide 50 Class FAU: Security Audit Name Description S a A b R c I d FTP_TRP.1/Admin Trusted Path ü ü ü a S=Selection b A=Assignment c R=Refinement d I=Iteration CONTENTS • Section 6.3.1, “Class FAU: Security Audit” • Section 6.3.2, “Class FCS: Cryptographic Support” • Section 6.3.3, “Class FIA: Identification and Authentication” • Section 6.3.4, “Class FMT: Security Management” • Section 6.3.5, “Class FPT: Protection of the TSF” • Section 6.3.6, “Class FTA: TOE Access” • Section 6.3.7, “Class FTP: Trusted Path/Channels” Section 6.3.1 Class FAU: Security Audit FAU_GEN.1 Audit Data Generation Hierarchical to: No other components Dependencies: FPT_STM.1 Reliable Time Stamps • FAU_GEN.1.1 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). ▫ [Starting and stopping services]; d. Specifically defined auditable events listed in Table 8. Reference Guide Chapter 6 Security Requirements Class FAU: Security Audit 51 Table 8: FAU_GEN.1 Audit Data Generation Requirement Auditable Events Additional Audit Record Contents FAU_GEN.1 None None FAU_GEN.2 None None FAU_STG_EXT.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_HTTPS_EXT.1 Failure to establish an HTTPS Session Reason for failure FCS_SSHS_EXT.1 Failure to establish an SSH Session Reason for failure FCS_TLSS_EXT.1 Failure to establish a TLS Session Reason for failure 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 the identification and authentication mechanism 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 FIA_X509_EXT.1/REV Unsuccessful attempt to validate a certificate Reason for failure FIA_X509_EXT.2 None None FIA_X509_EXT.3 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 None None FMT_SMR.2 None None FPT_APW_EXT.1 None None FPT_SKP_EXT.1 None None FPT_STM_EXT.1 Discontinuous changes to time – either administrator actuated or changed via an automated process. (Note that no continuous changes to time need to be logged. See also application note on FPT_STM_EXT.1.) 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). Chapter 6 Security Requirements Reference Guide 52 Class FAU: Security Audit Requirement Auditable Events Additional Audit Record Contents FPT_TST_EXT.1 None None FPT_TUD_EXT.1 Initiation of update; result of the update attempt (success or failure) None FTA_SSL_EXT.1 (if ‘terminate the session’ is selected) The termination of a local 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 attempts FTP_TRP.1/Admin Initiation of the trusted path. Termination of the trusted path. Failure of the trusted path functions. None • FAU_GEN.1.2 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 PP/ST, information specified in column three of Table 8. FAU_GEN.2 User Identity Association Hierarchical to: No other components Dependencies: FAU_GEN.1 Audit Data Generation FIA_UID.1 Timing of Identification • 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 FAU_STG_EXT.1 Protected Audit Event Storage Hierarchical to: No other components Dependencies: FAU_GEN.1 Audit Data Generation FTP_ITC.1 Inter-TSF Trusted Channel • 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 • FAU_STG_EXT.1.2 The TSF shall be able to store generated audit data on the TOE itself • FAU_STG_EXT.1.3 The TSF shall [overwrite previous audit records according to the following rule: [ Reference Guide Chapter 6 Security Requirements Class FCS: Cryptographic Support 53 a. for TOEs with a ColdFire processor, the oldest sector is overwritten with the record b. for TOEs with a PowerPC processor the log file is erased and new logs are written into the erased file]] when the local storage space for audit data is full. Section 6.3.2 Class FCS: Cryptographic Support FCS_CKM.1 Cryptographic Key Generation Hierarchical to: No other components Dependencies: FCS_CKM.2 FCS_CKM.4 • FCS_CKM.1.1 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 Diffie-Hellman group 14 that meet the following: RFC 3526, Section 3 ] and specified cryptographic key sizes [assignment: cryptographic key sizes] that meet the following: [assignment: list of standards]. FCS_CKM.2 Cryptographic Key Establishment Hierarchical to: No other components Dependencies: FCS_CKM.1 FCS_CKM.4 FTP_ITC.1 • FCS_CKM.2.1 The TSF shall perform cryptographic key establishment in accordance with a specified cryptographic key establishment method: [ ▫ RSA-based key establishment schemes that meets the following: NIST Special Publication 800-56B Revision 1, “Recommendation for Pair-Wise Key Establishment Schemes Using Integer Factorization Cryptography”; ▫ Elliptic curve-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”; ▫ Key establishment scheme using Diffie-Hellman group 14 that meets the following: RFC 3526, Section 3; ] that meets the following: [assignment: list of standards]. Chapter 6 Security Requirements Reference Guide 54 Class FCS: Cryptographic Support FFCS_CKM.4 Cryptographic Key Destruction Hierarchical to: No other components Dependencies: FCS_CKM.1 Cryptographic Key Generation • 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 [single overwrite consisting of [zeroes]], ▫ For plaintext keys in non-volatile storage, the destruction shall be executed by the invocation of an interface provided by the TSF that [ • Logically addresses the storage location of the key and performs a [single] overwrite consisting of [zeroes]]; ] that meets the following: No Standard FCS_COP.1/DataEncryption Cryptographic Operation (AES Data Encryption/Decryption) Hierarchical to: No other components Dependencies: FCS_CKM.1 Cryptographic Key Generation FCS_CKM.4 Cryptographic Key Destruction • FCS_COP.1.1/DataEncryption The TSF shall perform encryption/decryption in accordance with a specified cryptographic algorithm AES used in [CBC, CTR, GCM] mode and cryptographic key sizes [128 bits, 256 bits] that meet the following: AES as specified in ISO 18033-3, [CBC as specified in ISO 10116, CTR as specified in ISO 10116, GCM as specified in ISO 19772] FCS_COP.1/SigGen Cryptographic Operation (Signature Generation and Verification) Hierarchical to: No other components Dependencies: FCS_CKM.1 Cryptographic Key Generation FCS_CKM.4 Cryptographic Key Destruction • 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 to 3072 bits], ] and cryptographic key sizes [assignment: cryptographic key sizes] 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 ] Reference Guide Chapter 6 Security Requirements Class FCS: Cryptographic Support 55 FCS_COP.1/Hash Cryptographic Operation (Hash Algorithm) Hierarchical to: No other components Dependencies: FCS_CKM.1 Cryptographic Key Generation FCS_CKM.4 Cryptographic Key Destruction • 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/Keyed Hash Cryptographic Operation (Keyed Hash Algorithm) Hierarchical to: No other components Dependencies: FCS_CKM.1 Cryptographic Key Generation FCS_CKM.4 Cryptographic Key Destruction • FCS_COP.1.1/Keyed Hash 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 to 320 bits, 256 to 512 bits, 384 to 768 bits, or 512 to 1024] and message digest sizes [160, 256, 384, 512] bits that meet the following: ISO/IEC 9797-2:2011, Section 7 “MAC Algorithm 2” FCS_HTTPS_EXT.1 HTTPS Protocol Hierarchical to: No other components Dependencies: FCS_TLS_EXT.1 • FCS_HTTPS_EXT.1.1 The TSF shall implement the HTTPS protocol that complies with RFC 2818 • FCS_HTTPS_EXT.1.2 The TSF shall implement HTTPS using TLS • FCS_HTTPS_EXT.1.3 If a peer certificate is presented, the TSF shall [not require client authentication, [no other action]] if the peer certificate is deemed invalid FCS_SSHS_EXT.1 SSH Server Protocol Hierarchical to: No other components Dependencies: 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 Chapter 6 Security Requirements Reference Guide 56 Class FCS: Cryptographic Support • FCS_SSHS_EXT.1.1 The TSF shall implement the SSH protocol that complies with RFC(s) [4251, 4252, 4253, 4254, 5647] • 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 [4096] 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, aes256-ctr, AEAD_AES_128_GCM, AEAD_AES_256_GCM] • FCS_SSHS_EXT.1.5 The TSF shall ensure that the SSH public-key based authentication implementation uses [ssh-rsa] and [no other public key algorithm] 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] and [AEAD_AES_128_GCM, AEAD_AES_256_GCM] as its MAC algorithm(s) and rejects all other MAC algorithm(s) • FCS_SSHS_EXT.1.7 The TSF shall ensure that [diffie-hellman-group14-sha1, ecdh-sha2-nistp256] and [ecdh-sha2-nistp521, and ecdh-sha2-nistp384] 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 no more than one gigabyte of transmitted data. After either of the thresholds are reached a rekey needs to be performed. FCS_TLSS_EXT.1 TLS Server Protocol Hierarchical to: No other components Dependencies: 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 Random Bit Generation • FCS_TLSS_EXT.1.1 The TSF shall implement [TLS 1.2 (RFC 5246), TLS 1.1 (RFC 4346)] and reject all other TLS and SSL versions. The TLS implementation will support the following ciphersuites: [ ▫ TLS_RSA_WITH_AES_128_CBC_SHA as defined in RFC 3268 ▫ TLS_RSA_WITH_AES_256_CBC_SHA as defined in RFC 3268 ▫ TLS_DHE_RSA_WITH_AES_128_CBC_SHA as defined in RFC 3268 ▫ TLS_DHE_RSA_WITH_AES_256_CBC_SHA as defined in RFC 3268 ▫ TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA as defined in RFC 4492 Reference Guide Chapter 6 Security Requirements Class FIA: Identification and Authentication 57 ▫ TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA as defined in RFC 4492 ▫ TLS_RSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5246 ▫ TLS_RSA_WITH_AES_256_CBC_ SHA256 as defined in RFC 5246 ▫ TLS_DHE_RSA_WITH_AES_128_CBC_ SHA256 as defined in RFC 5246 ▫ TLS_DHE_RSA_WITH_AES_256_CBC_ SHA256 as defined in RFC 5246 ▫ TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 as defined in RFC 5289 ▫ TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5289] • FCS_TLSS_EXT.1.2 The TSF shall deny connections from clients requesting SSL 2.0, SSL 3.0, TLS 1.0 and [none] • FCS_TLSS_EXT.1.3 The TSF shall [perform RSA key establishment with key size [2048 bits, 3072 bits]; generate EC Diffie-Hellman parameters over NIST curves [secp256r1, secp384r1, secp521r1] and no other curves; generate Diffie-Hellman parameters of size [2048 bits]] FCS_RBG_EXT.1 Random Bit Generation Hierarchical to: No other components Dependencies: No dependencies • FCS_RBG_EXT.1.1 The TSF shall perform all deterministic random bit generation services in accordance with ISO/IEC 18031:2011 using [CTR_DRBG (AES)] • FCS_RBG_EXT.1.2 The deterministic RBG shall be seeded by at least one entropy source that accumulates entropy from [[one] software-based noise source] with 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 Section 6.3.3 Class FIA: Identification and Authentication FIA_AFL.1 Authentication Failure Management Hierarchical to: No other components Dependencies: FIA_UIA_EXT.1 • FIA_AFL.1.1 The TSF shall detect when an Administrator configurable positive integer within [1 to 20] unsuccessful authentication attempts occur related to Administrators attempting to authenticate remotely • FIA_AFL.1.2 When the defined number of unsuccessful authentication attempts has been met, the TSF shall [prevent the offending remote Administrator from successfully authenticating until [the appliance’s rebooting action] is taken by a local Administrator; prevent the offending remote Administrator from successfully authenticating until an Administrator defined time period has elapsed]. Chapter 6 Security Requirements Reference Guide 58 Class FIA: Identification and Authentication FIA_PMG_EXT.1 Password Management Hierarchical to: No other components Dependencies: No dependencies • 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: [“!”, “@”, “#”, “$”, “%”, “^”, “&”, “*”, “(“, “)”]; b. Minimum password length shall be configurable to [1] and [17] FIA_UIA_EXT.1 User Identification and Authentication Hierarchical to: No other components Dependencies: FTA_TAB.1 Default TOE Access Banners • 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 response; ▫ HTTP redirects; ▫ TCP handshakes]] • 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 FIA_UAU_EXT.2 Password-based Authentication Mechanism Hierarchical to: No other components Dependencies: No other components • FIA_UAU_EXT.2.1 The TSF shall provide a local password-based authentication mechanism, and [no other authentication mechanism] to perform local administrative user authentication FIA_UAU.7 Protected Authentication Feedback Hierarchical to: No other components Dependencies: FIA_UAU.1 Timing of Authentication • 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 Reference Guide Chapter 6 Security Requirements Class FIA: Identification and Authentication 59 FIA_X509_EXT.1/Rev X.509 Certificate Validation Hierarchical to: No other components Dependencies: No other components • 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 certificate path must terminate with a trusted CA certificate ▫ The TSF shall validate a certificate path by ensuring the presence of the basicConstraints extension and that the CA flag is set to TRUE for all CA certificates ▫ The TSF shall validate the revocation status of the certificate using [the Online Certificate Status Protocol (OCSP) as specified in RFC 6960] ▫ The TSF shall validate the extendedKeyUsage field according to the following rules: • 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 • 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 • 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 • 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 FIA_X509_EXT.2 X.509 Certificate Authentication Hierarchical to: No other components Dependencies: No other components • FIA_X509_EXT.2.1 The TSF shall use X.509v3 certificates as defined by RFC 5280 to support authentication for [TLS, HTTPS], and [no additional uses] • 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] FIA_X509_EXT.3 X.509 Certificate Requests Hierarchical to: No other components Dependencies: No other components Chapter 6 Security Requirements Reference Guide 60 Class FMT: Security Management • FIA_X509_EXT.3.1 The TSF shall generate a Certificate Request Message as specified by RFC 2986 and be able to provide the following information in the request: public key and [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 Section 6.3.4 Class FMT: Security Management FMT_MOF.1/ManualUpdate Management of Security Functions Behaviour Hierarchical to: No other components Dependencies: FMT_SMR.1 Security Roles FMT_SMF.1 Specification of Management Functions • FMT_MOF.1.1/ManualUpdate The TSF shall restrict the ability to enable the functions to perform manual update to Security Administrators FMT_MTD.1/CoreData Management of TSF Data Hierarchical to: No other components Dependencies: FMT_SMF.1 Specification of Management Functions FMT_SMR.1 Security Roles • FMT_MTD.1.1/CoreData The TSF shall restrict the ability to manage the TSF data to Security Administrators FMT_SMF.1 Specification of Management Functions Hierarchical to: No other components Dependencies: FIA_UIA_EXT.1 User Identification and Authentication FCS_COP.1/SigGen Cryptographic Operation (for Cryptographic Signature) FPT_TUD_EXT.1 Trusted Update • FMT_SMF.1.1 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] capability prior to installing those updates; ▫ Ability to configure the authentication failure parameters for FIA_AFL.1; ▫ [ Reference Guide Chapter 6 Security Requirements Class FPT: Protection of the TSF 61 • Ability to set the time that is used for time-stamps; • Ability to re-enable an Administrator account; • No other capabilities] FMT_SMR.2 Restrictions on Security Roles Hierarchical to: No other components Dependencies: FIA_UID.1 Timing of Identification • 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 Section 6.3.5 Class FPT: Protection of the TSF FPT_APW_EXT.1 Protection of Administrator Passwords Hierarchical to: No other components Dependencies: No dependencies • FPT_APW_EXT.1.1 The TSF shall store passwords in non-plaintext form • FPT_APW_EXT.1.2 The TSF shall prevent the reading of plaintext passwords FPT_SKP_EXT.1 Protection of TSF Data (for Reading of All Pre-shared, Symmetric, and Private Keys) Hierarchical to: No other components Dependencies: No dependencies • FPT_SKP_EXT.1.1 The TSF shall prevent reading of all pre-shared keys, symmetric keys, and private keys Chapter 6 Security Requirements Reference Guide 62 Class FPT: Protection of the TSF FPT_STM_EXT.1 Reliable Time Stamps Hierarchical to: No other components Dependencies: No dependencies • 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] FPT_TST_EXT.1 TSF Testing Hierarchical to: No other components Dependencies: No dependencies • FPT_TST_EXT.1.1 The TSF shall run a suite of the following self-tests [during initial start-up (on power on), at the request of the authorised user] to demonstrate the correct operation of the TSF: [ ▫ Firmware Integrity Test ▫ AES encrypt/decrypt CBC Known Answer Test (KAT) ▫ AES encrypt/decrypt CTR KAT ▫ AES encrypt/decrypt GCM KAT ▫ HMAC KAT with SHA-1, SHA-224, SHA-256, SHA-384, and SHA-512 ▫ SHA-1 KAT ▫ SHA-224, SHA-256, SHA-384, and SHA-512 KATs ▫ CTR DRBG KAT ▫ RSA signature generation/verification KAT ▫ ECDSA pair-wise consistency test ▫ Primitive “Z” Computation KAT ▫ Continuous Random Number Generator Test for DRBG ▫ Continuous Random Number Generator Test for NDRNG ▫ RSA pair-wise consistency test ▫ ECDSA signature generation/verification test ▫ ECC full public-key validation test ▫ EC Diffie-Hellman Public Key Assurance Test] FPT_TUD_EXT.1 Trusted Update Hierarchical to: No other components Dependencies: FCS_COP.1(1) Cryptographic Operation (for Cryptographic Signature), or FCS_COP.1(3) Cryptographic Operation (for Cryptographic Hashing) Reference Guide Chapter 6 Security Requirements Class FTA: TOE Access 63 • 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 [the most recently installed version of the TOE firmware/software] • 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.3 The TSF shall provide means to authenticate firmware/software updates to the TOE using a [digital signature mechanism] prior to installing those updates Section 6.3.6 Class FTA: TOE Access FTA_SSL_EXT.1 TSF-initiated Session Locking Hierarchical to: No other components Dependencies: No dependencies • FTA_SSL_EXT.1.1 The TSF shall, for local interactive sessions, [ ▫ terminate the session] after a Security Administrator-specified time period of inactivity FTA_SSL.3 TSF-initiated Termination Hierarchical to: No other components Dependencies: No dependencies • FTA_SSL.3.1 The TSF shall terminate a remote interactive session after a Security Administrator-configurable time interval of session inactivity FTA_SSL.4 User-initiated Termination Hierarchical to: No other components Dependencies: No dependencies • FTA_SSL.4.1 The TSF shall allow Administrator-initiated termination of the Administrator’s own interactive session FTA_TAB.1 Default TOE Access Banners Hierarchical to: No other components Dependencies: No dependencies Chapter 6 Security Requirements Reference Guide 64 Class FTP: Trusted Path/Channels • 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 Section 6.3.7 Class FTP: Trusted Path/Channels FTP_ITC.1 Inter-TSF Trusted Channel Hierarchical to: No other components Dependencies: No other components • FTP_ITC.1.1 The TSF shall be capable of using [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 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 [no services] FTP_TRP.1/Admin Trusted Path Hierarchical to: No other components Dependencies: No other components • FTP_TRP.1.1/Admin The TSF shall be capable of using [SSH, TLS, HTTPS] 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 Reference Guide Chapter 7 TOE Summary Specification TOE Security Functionality 65 TOE Summary Specification This section presents information to detail how the TOE meets the functional requirements described in previous sections of this ST. CONTENTS • Section 7.1, “TOE Security Functionality” Section 7.1 TOE Security Functionality Each of the security requirements and the associated descriptions correspond to the security functions. Hence, each function is described by how it specifically satisfies each of its related requirements. This serves to both describe the security functions and rationalize that the security functions satisfy the necessary requirements. Table 9: Mapping of TOE Security Functionality to Security Functional Requirements TOE Security Function SFR ID Description FAU_GEN.1 Audit data generation FAU_GEN.2 User identity association Security Audit FAU_STG_EXT.1 Protected audit event storage FCS_CKM.1 Cryptographic key generation FCS_CKM.2 Cryptographic key establishment FCS_CKM.4 Cryptographic key destruction FCS_COP.1/DataEncryption Cryptographic operation (AES data encryption/decryption) FCS_COP.1/SigGen Cryptographic operation (signature generation and verification) FCS_COP.1/Hash Cryptographic operation (hash algorithm) FCS_COP.1/Keyed Hash Cryptographic operation (keyed hash algorithm) FCS_HTTPS_EXT.1 HTTPS protocol FCS_SSHS_EXT.1 SSH server protocol FCS_TLSS_EXT.1 TLS server protocol Cryptographic Support FCS_RBG_EXT.1 Random bit generation FIA_AFL.1 Authentication Failure Management FIA_PMG_EXT.1 Password management Identification and Authentication FIA_UIA_EXT.1 User identification and authentication Chapter 7 TOE Summary Specification Reference Guide 66 TOE Security Functionality TOE Security Function SFR ID Description FIA_UAU_EXT.2 Password-based authentication mechanism FIA_UAU.7 Protected authentication feedback FIA_X509_EXT.1/REV X.509 Certificate validation FIA_X509_EXT.2 X.509 Certificate authentication FIA_X509_EXT.3 X.509 Certificate requests FMT_MOF.1/ManualUpdate Management of security functions behavior FMT_MTD.1/CoreData Management of TSF data FMT_SMF.1 Specification of management functions FMT_SMR.2 Restrictions on security roles FPT_APW_EXT.1 Protection of administrator passwords FPT_SKP_EXT.1 Protection of TSF data (for reading of all symmetric keys) FPT_STM_EXT.1 Reliable time stamps FPT_TST_EXT.1 TSF testing Protection of the TSF FPT_TUD_EXT.1 Trusted update FTA_SSL.3 TSF-initiated termination FTA_SSL.4 User-initiated termination FTA_SSL_EXT.1 TSF-initiated session locking TOE Access FTA_TAB.1 Default TOE access banners FTP_ITC.1 Inter-TSF trust channel Trusted path/channels FTP_TRP.1/Admin Trusted path CONTENTS • Section 7.1.1, “Security Audit” • Section 7.1.2, “Cryptographic Support” • Section 7.1.3, “Identification and Authentication” • Section 7.1.4, “Security Management” • Section 7.1.5, “Protection of the TSF” • Section 7.1.6, “TOE Access” • Section 7.1.7, “Trusted Path/Channels” Reference Guide Chapter 7 TOE Summary Specification Security Audit 67 Section 7.1.1 Security Audit FAU_GEN.1, FAU_GEN.2 The TOE generates audit records as part of the security audit function. As administrators manage and configure the TOE, their activities are tracked and recorded as audit records and are stored in the file system. The TOE generates audit records for all the required events specified in Section 6.3.1, “Class FAU: Security Audit”. An example audit record is shown below: • 15/09/15 18:29:54.481 INFO 32C Console user ‘admin’ logged out This example shows for the event: • Date and time: 15/09/15 18:29:54.481 • Level of event: possible levels include DEBUG, INFO, NOTICE, WARN, ERROR, CRITICAL, ALERT • Interface where event occurred: possible values are Console, SSH, or HTTPS • Username of user who performed the action: ‘admin’ • Description of the action: logged out For the password authentication mechanism, the User Name is the User ID. Actions performed by the user (admin role) authenticated using the password are identified by the "User Name." For the SSH key-based authentication mechanism, the keys are identified by their fingerprint and the key fingerprint will be the User ID. Actions performed by users authenticated using key-based authentication are identified by the key fingerprints. The user name in that case is the client's user name associated with particular ssh public key and it is used by the SSH service of the TOE to select the respective public key. Audits of time vary according to the type of time change that is made. When an administrator changes the time, the old and new time are recorded in the audit records. When a time zone change is made, the time is also updated. In this case the old and new time are also recorded. The TOE can be set to automatically account for Daylight Savings Time. FAU_STG_EXT.1 The TOE securely transfers audit logs via SSH to an external audit server. The TOE maintains 1.5 to 5.5 MB 1 of local audit storage. The TOE can include a ColdFire or PowerPC processor. The action that is taken when the audit storage is full depends on the type of processor. The CPU platforms differ, in that the ColdFire platform’s filesystem is directly mapped flash sectors, while the PowerPC platform uses a transparent filesystem (tfs). The flash sectors implement a simple round-robin mechanism for the logs by writing over the first sector after all sectors are filled. On the ColdFire processor the syslog.txt file is allocated the remainder of flash memory after all other files have been allocated. The size can be verified by using the flashfiles command. When the log becomes full on a TOE with a ColdFire processor, the TOE will erase the first sector of the file and begin recording audit records in this sector. On the PowerPC processor the log is file based and the syslog.txt file is 1.75M in size. When the log becomes full on a TOE with a PowerPC processor, the TOE will erase the log file and begin a new log file. Please see Section 1.5.1.1, “TOE Hardware and Software” for a complete list of which model includes which CPU. A Security Administrator can configure logs to be sent to the external server as they occur so that no log events are lost. All audit logs are protected using operating system file permissions and only authorized Security Administrators can delete these files. TOE Security Functional Requirements Satisfied: • FAU_GEN.1 1 MB - Megabytes Chapter 7 TOE Summary Specification Reference Guide 68 Cryptographic Support • FAU_GEN.2 • FAU_STG_EXT.1 Section 7.1.2 Cryptographic Support Details the cryptographic algorithm certificates for the TOE. Table 10: CAVP-Approved Algorithm Implementations CAVP Certificate PowerPC ColdFire Algorithm Standard Mode/ Method Key Lengths/ Curves/ Moduli Use FIPS 197 NIST SP 800-38D CBC, GCM 128, 256 4030 [http://csrc.nist.gov/groups/ STM/cavp/documents/aes/ aesval.html#4030] 4037 [http://csrc.nist.gov/groups/ STM/cavp/documents/aes/ aesval.html#4037] AES a FIPS 197 CTR 256 Encryption/ Decryption (FCS_COP.1/ DataEncryption) - 2048, 3072 Key Generation (FCS_CKM.1, bullet 1) 2078 [http://csrc.nist.gov/ groups/STM/cavp/documents/dss/ rsanewval.html#2078] 2072 [http://csrc.nist.gov/ groups/STM/cavp/documents/dss/ rsanewval.html#2072] RSA FIPS 186-4 SHA-256, SHA-384, and SHA-512 (PKCS #1 v1.5) b 2048, 3072 Signature Generation and Verification (FCS_COP.1/SigGen) 899 [http://csrc.nist.gov/groups/ STM/cavp/documents/dss/ ecdsanewval.html#899] 903 [http://csrc.nist.gov/groups/ STM/cavp/documents/dss/ ecdsanewval.html#903] ECDSA FIPS 186-4 - P-256, P-384, P-521 Public Key Generation and Verification (FCS_CKM.1, bullet 2) 3336 [http://csrc.nist.gov/ groups/STM/cavp/documents/shs/ shaval.html#3336] 3329 [http://csrc.nist.gov/ groups/STM/cavp/documents/shs/ shaval.html#3329] SHS FIPS 180-4 SHA-1, SHA-256, SHA-384, SHA-512 - Message Digest (FCS_COP.1/Hash) 2631 [http://csrc.nist.gov/groups/ STM/cavp/documents/mac/ hmacval.html#2631] 2635 [http://csrc.nist.gov/groups/ STM/cavp/documents/mac/ hmacval.html#2635] HMAC FIPS 198-1 SHA-1, SHA-256, SHA-384, and SHA-512 - Message Authentication (FCS_COP.1/Keyed Hash) 1204 [http://csrc.nist.gov/groups/ STM/cavp/documents/drbg/ drbgnewval.html#1204] 1207 [http://csrc.nist.gov/groups/ STM/cavp/documents/drbg/ drbgnewval.html#1207] DRBG NIST SP 800-90A CTR_based - Deterministic Random Bit Generation (FCS_RBG_EXT.1) 858 [http://csrc.nist.gov/ groups/STM/cavp/ documents/components/ componentnewval.html#858] 863 [http://csrc.nist.gov/ groups/STM/cavp/ documents/components/ componentnewval.html#863] CVL for ECC KAS NIST SP 800-56A - P-256, P-384, P-521 ECC KAS (FCS_CKM.2, bullet 2) a CAVP testing was performed on AES ECB mode but is not implemented in the module. b SHA-1 shall not be used for digital signature generation with the exception as specified in SP 800-52 REV1 and SP 800-57 Part 3 REV1. Reference Guide Chapter 7 TOE Summary Specification Cryptographic Support 69 FCS_CKM.1 The TOE is capable of generating asymmetric RSA key pairs. RSA key pairs can be generated for 2048 and 3072- bit sizes and are used for SSH and TLS. The RSA key pairs meet the SP 800-56B section 6.3.1. ECDSA key pairs are generated as a part of the ECDH algorithm using the P-256, P-384, and P-521 curves. The TOE implements DH group 14 as a part of SSH. FCS_CKM.2 The TOE uses RSA-based key establishment for TLS. In TLS communications the TOE acts as the server and therefore receives the pre-master secret and verifies it using the server’s generated RSA key. Both ECDH and DH are used to establish keys in SSH communications. The TOE acts as the server in SSH communications as well and therefore uses ECDH and DH to compute the shared secret. The DH key agreement used for SSH uses 2048-bit MODP group as defined in RFC 3526 Section 3. FCS_CKM.4 Volatile memory is used for temporary storage of passwords during the authentication process, and session or ephemeral keys are used during the secure session. Volatile memory is destroyed using a single, direct overwrite of zeros. SSH host keys, SSH public keys, SSL host certificates, and public certificates are stored in non-volatile flash memory. When key destruction is needed, a block erase is performed followed by a read of the memory to confirm the key has been erased. If memory is not all zeros, the block erase is attempted up to five times. FCS_COP.1/DataEncryption As a part of the TOE’s secure protocols, AES is used for encryption and decryption. The modes CBC or GCM can be used in either SSH or TLS, and key sizes are either 128 bits or 256 bits. AES CTR with 256 bits can also be used for encryption and decryption in SSH. In AES GCM the IV is generated internally using the CTR DRBG. FCS_COP.1/SigGen Cryptographic signatures are used by the TOE as a part of SSH and TLS sessions as well as to verify TOE updates. RSA signatures with a key size of 2048 to 3072 bits can be generated and verified for SSH or TLS. Updates to the TOE are signed using RSA. FCS_COP.1/Hash In order to perform digital signature operations for TLS, and update verification, the TOE performs cryptographic hashing using Secure Hash Algorithm SHA-256, SHA-384, and SHA-512. In addition, the TOE performs cryptographic hashing using SHA-1 and SHA-256 for key exchange operations in SSH. The TOE also uses a SHA-512 hash to hash the password and a salt value prior to storing or checking the password. FCS_COP.1/Keyed Hash Keyed-hash message authentication is used in both TLS and SSH within the TOE. HMAC with SHA-1, SHA-256, SHA-384, and SHA-512 is provided by the TOE for this use. The HMAC SHA-1 algorithm provides key sizes of 160 to 320bits and message digests that are 160 bits. The HMAC SHA-256 algorithm provides key sizes of 256 to 512 bits and message digests that are 256 bits. The HMAC SHA-384 algorithm provides key sizes of 384 to 768 bits and message digests that are 384 bits. Lastly, the HMAC SHA-512 algorithm provides key sizes of 512 to 2014 bits and message digests that are 512 bits. Chapter 7 TOE Summary Specification Reference Guide 70 Cryptographic Support FCS_HTTPS_EXT.1 HTTPS using TLS is used for management sessions to the TOE’s web interface. Certificate-based authentication can be used for these sessions. The TOE does not perform mutual authentication and will not verify the client certificate prior to connection. The HTTPS implementation in the TOE complies with all MUST statements related to the server side implementation of HTTPS in RFC 2818. FCS_SSHS_EXT.1 The TOE uses SSH for management communications to the terminal-based menu and to send log messages to an external audit server. RSA is the only algorithm used for authentication within SSH. The host-based public key can use either 2048 or 3072 bit keys. Password-based authentication is also permitted via SSH. The TOE will drop packets received over SSH that are larger than 4096 bytes. SSH traffic is encrypted using one of the following algorithms: • AES CBC with 128 bit key • AES CBC with 256 bit key • AES CTR with 256 bit key • AES in GCM mode with authenticated encryption and 128 bit keys • AES in GCM mode with authenticated encryption and 256 bit keys SSH-RSA is used for SSH transport and Diffie-Hellman Group 14 with SHA 1 or ECDH with SHA 2 and NIST curves P-256, P-384, and P-521 are used for key exchange, according to SP 800-135 Rev 1. Data integrity is verified using HMAC SHA-1 or AES GCM with authenticated encryption with 128 or 256 bit keys. All SSH connections are rekeyed after 900MB of traffic has been transmitted using the same key or the session has been active for 3000 seconds. Hardware constraints restrict all models except the RSG2488F from being able to transmit 1GB within an hour. To do so would require a transmission rate of approximately 280 KB/s. The NXP ColdFire CPU is capable of receiving or transmitting at most 60KB/s using aes-128-cbc and is therefore not able to process 1GB within an hour. The RSG2488F model, with the NXP PowerQUICC, is capable of meeting this threshold. It is not possible to change the CPU in the TOE, therefore this limitation will always exist. FCS_TLSS_EXT.1 The TOE uses TLS v1.1 or 1.2 for secure management connections to the web interface. The SFR lists all ciphersuites implemented by the TOE. If a connection is requested using TLS v1.0, any version of SSL, or a ciphersuite not listed in the SFR, the TOE will reject the connection and a browser error will be seen on the client side. The TLS session establishes keys using one of the following methods: • RSA with key size of 2048 or 3072 bits • ECDHE with NIST curves secp256r1, secp384r1, or secp521r1 • Diffie-Hellman with a 2048 bit parameter Mutual authentication is not supported by the TOE. FCS_RBG_EXT.1 In order to generate secure keys, the TOE implements a CTR DRBG using AES. The DRBG relies on a software noise source to provide 256 bits of entropy for seeding the DRBG. Prediction resistance is enabled on the DRBG. TOE Security Functional Requirements Satisfied: • FCS_CKM.1 • FCS_CKM.2 Reference Guide Chapter 7 TOE Summary Specification Identification and Authentication 71 • FCS_CKM.4 • FCS_COP.1/DataEncryption • FCS_COP.1/SigGen • FCS_COP.1/Hash • FCS_COP.1/Keyed Hash • FCS_HTTPS_EXT.1 • FCS_SSHS_EXT.1 • FCS_TLSS_EXT.1 • FCS_RBG_EXT.1 Section 7.1.3 Identification and Authentication FIA_AFL.1 The TOE will only allow 1 Administrator account to use password-based authentication while operating in the evaluated configuration. The Operator and Guest accounts are disabled. The TOE allows the Administrator to configure the number of unsuccessful login attempts to the TOE with a configurable value from 1 to 20 attempts per service, i.e. SSH or Web UI. The TOE will disable the password-based login authentication for a service when the number of successive, unsuccessful authentication attempts has been reached within a defined time window called the “Failed Attempts Windows”. This time period is not associated with the lockout period that RUGGEDCOM ROS imposes when the number of unsuccessful attempts is met. The TOE will also disable the password-based login authentication when the number of unsuccessful authentication attempts has been reached within the “Failed Attempts Window” when the attempts are not successive, meaning that a successful authentication within that time period does not reset the counter. The counter is reset to 0 when the “Failed Attempts Window” expires. If the device is rebooted, the admin account will be reenabled. This means that the TOE will not disable password- based login authentication for a service when the number of unsuccessful authentication attempts happens outside the “Failed Attempts Window” even if the attempts are successive, unsuccessful authentication attempts. The “Failed Attempts Window” can be configured to be between 1 and 30 minutes. Since the Administrator is the only valid TOE user, all login attempts are to the Administrator account and any unsuccessful attempts are counted against the Administrator’s unsuccessful attempts. Authentication on the service is blocked by disabling the authentication mechanism on that service until the Lockout Time is reached. The Lockout Time can be configured by an Administrator to between 1 to 120 minutes. The service and port remain open. When password-based logins are blocked on SSH, they are still available via the Web UI, the local console, or SSH using public key-based authentication. SSH key-based authentication is a more secure authentication mechanism and it will not be disabled/blocked by unsuccessful authentication attempts. If logins are blocked on both the Web UI and SSH, local console is always available to prevent a denial of service attack. The local console is protected by the secure environment. This will prevent a remote threat from to attempting to access the TOE by brute force attacks. Only the user using password authentication via a specific service (e.g. SSH) will be blocked for that service (e.g. SSH). Password authentications via other services are not affected, meaning that the same user blocked on password authentication on SSH can still be successfully authenticated using the password via the HTTPS service or local Console. Chapter 7 TOE Summary Specification Reference Guide 72 Identification and Authentication FIA_PMG_EXT.1 Authorized administrators can configure the password to be from a minimum length of one (1) characters to a maximum length of nineteen (19) characters. Valid passwords can be composed of any combination of upper and lower case letters, numbers, and other printable characters including: !, @, #, $, %, ^, &, *, (, and ). Administrators can configure the password requirements from the shell within the CLI using the passwordCfg table. FIA_UIA_EXT.1, FIA_UAU_EXT.2, FIA_UAU.7 All interfaces and access methods show an access banner prior to authentication. The TOE will respond to ICMP echoes and perform HTTP redirect and TCP handshakes prior to authentication. No other actions are allowed prior to authentication. Only authentication to the local file system is provided in the evaluated configuration. On the terminal-based menu, a user can access via serial connection or SSH. When accessing via serial access, the access banner is shown and then the user is prompted for their username. After entering the username, the user is prompted for the user’s password. No feedback is shown when entering the password. The TOE verifies the username and password against the local user file. If the password is verified, the user is shown a list of menus available to their role. The same process is used when authenticating to the terminal-based menu via SSH except that an SSH client is required. The SSH client will perform initial key exchange and display the configured banner prior to performing user authentication via either password or public key. Access via the web interface is similar. A TLS session is established with the TOE via the client’s web browser. Once the TLS session is established, the login page is displayed. The login page includes the access banner and fields for username and password. The password is displayed as dots when entering on the web interface. Once the user enters their authentication data and presses submit, the data is sent to the TOE and verified against the local user file. Once the password is verified, the web interface displays the list of menus available to the user’s role. This list is similar to the menus available on the terminal-based menu. FIA_X509_EXT.1/REV, FIA_X509_EXT.2 The TOE provides an X.509 certificate to support authentication in TLS server sessions. A Security Administrator must first provision the public portion of a trusted CA certificate into the sslpub.certs file. This file is in PEM format and is preceded by the following header: • , , Where each component in the header indicates the following: • Index A unique integer value used to identify the entry • Active Means the certificate has been loaded into the truststore • Inactive Means the certificate has not been loaded into the trust store • Rootca Signifies that this certificate is the certificate of a root CA • Signingca Signifies that this certificate is from an intermediate certificate issuer All certificates are verified against the certificate chain in the ssl.crt file. This chain terminates with the trusted CA certificate. The TOE calls out to the external OCSP server listed in the uploaded chain to verify revocation status when verifying new certificates. The TOE verifies the extendedKeyUsage field within certificates based on the rules outlined in the SFR. If the TOE cannot connect to the OCSP server to check for revocation, the Security Administrator can configure the functionality of the TSF. The TSF can be configured to ACCEPT or REJECT certificates in these cases. If REJECT is selected, entire chain of certificates are rejected. In the case where this a rejection leaves no valid certificates, the TOE web server is disabled. If the OCSP server returns that a certificate Reference Guide Chapter 7 TOE Summary Specification Security Management 73 has been revoked, the TOE will destroy the certificate to ensure it can no longer be used. A certificate’s status is additionally checked via the OCSP server at regular intervals once it has been added to ensure it remains valid. FIA_X509_EXT.3 Security Administrators can create a Certificate Request Message to receive a certificate generated by a trusted CA by specifying the following parameters in the web interface: • Common Name • Email Address • Organization • Organizational Unit • Locality • State or Province • Country • PKI key type and size The TOE then generates a PKI key pair and a csr.txt file. The file contains the CSR and the private key. The Administrator downloads this file and submits the CSR PEM to the appropriate CA for signature. The CA returns the signed certificate and certificate chain. The Administrator loads the trust anchor(s) into the sslpub.certs file via SFTP. These may be root or intermediate CA certificates to which the TLS server certificate chain traces its authenticity. The TLS server certificate chain and TLS server certificate’s private key are loaded into the ssl.crt file in PEM format. The server certificate appears first, followed by each issuer CA certificate in the hierarchy. The last PEM object in the ssl.crt file is the TLS server certificate’s private key pair. The TOE then validates all uploaded certificates prior to accepting the new certificate. If any certificate within the chain cannot be verified, the certificate is rejected. TOE Security Functional Requirements Satisfied: • FIA_PMG_EXT.1 • FIA_UIA_EXT.1 • FIA_UAU_EXT.2 • FIA_UAU.7 • FIA_X509_EXT.1/REV • FIA_X509_EXT.2 • FIA_X509_EXT.3 Section 7.1.4 Security Management Security management specifies how the TOE manages several aspects of the TSF including TSF data and security functions. TSF data includes configuration data of the TSF and audit data. The TOE provides authorized administrators over the web interface and terminal-based menu to easily manage the security functions and TSF data of the TOE. Chapter 7 TOE Summary Specification Reference Guide 74 Security Management FMT_MOF.1/ManualUpdate, FMT_MTD.1/CoreData A Security Administrator can update the TOE by transferring the TOE binary over SFTP to the TOE and resetting the device. The device can be reset from the CLI or web interface in the Diagnostics menu. The Diagnostics menu additionally provides the Security Administrator with the ability to configure alarms, view and clear the log, load factory defaults and reset the device. The Administration menu on both interfaces provides the Security Administrator with the ability to manage passwords. Additionally the CLI shell allows the Security Administrator to query system configurations. Security Administrators can import certificates to the TOE and upload new configuration files to modify configurations via SFTP. Only acceptance of the access banner is allowed prior to authenticating. The TOE does not provide any additional options to allow other actions prior to authentication. FMT_SMF.1, FMT_SMR.2 The TOE provides a role called Administrator. There are also Operator and Guest roles, but these are disabled in the evaluated configuration. The Administrator role holds the Security Administrator privileges discussed in this ST. Administrators can manage the TOE remotely via the web interface over HTTPS/TLS or the terminal-based menu. The terminal-based menu can be accessed locally via RS-232 or remotely over SSH. The TOE supports one user (in admin role) for the password authentication mechanism (via SSH/HTTPS/Console) and additional users (in admin role) authenticated using key-based authentication (via SSH only). There is only one password-based user which is created by default and has a configurable username and password. To allow multiple new users to access the TOE, the password-based user with the role of Administrator can be used to add SSH public keys for specified user names and associate them with the Administrator role. For information on managing this, refer to the "Managing SSH Public Keys" section of the RUGGEDCOM RUGGEDCOM ROS v4.2.2.F User Guides. Security Administrators can configure the following on either the web interface or the terminal-based menu: • Configure session inactivity timeouts • Reset the device to apply an update • Configure the authentication failure parameters • Configure the system time • Reboot the appliance Security Administrators can configure the following only through the terminal-based menu: • Upload a text file that is used to generate an access banner • Upload the update Rebooting the appliance will unlock an Administrator account that has been lockout due to authentication failures. Signature verification is an internal process that is automatically triggered by uploading an update. No administrator action is required to perform the verification. The Security Administrator can also configure the system time used for time stamps. TOE Security Functional Requirements Satisfied: • FMT_MOF.1/ManualUpdate • FMT_MTD.1/Coredata • FMT_SMF.1 • FMT_SMR.2 Reference Guide Chapter 7 TOE Summary Specification Protection of the TSF 75 Section 7.1.5 Protection of the TSF FPT_APW_EXT.1 A salted hash of the password is stored in the TOE’s user configuration file. This hash is created using an SHA-512 hash. Only the Security Administrator has the ability to read the salted and hashed passwords. The Security Administrators are trusted not to read these files. FPT_SKP_EXT.1 Private keys are stored in the TOE’s file system with access controls on the file. No reading of these files is allowed. The files can be zeroized and updated by an authorized Security Administrator. FPT_STM_EXT.1 The TOE provides a reliable time stamp for use in the audit function. TOE maintains an internal date and time, this system time can be modified by an Administrator in the Administration » System Time Manager menu. The NTP service is excluded from the TOE and must be disabled.. FPT_TST_EXT.1 The TOE performs FIPS power-up and conditional self-tests for all cryptographic algorithms. The following is a description of each of the start-up tests: • Firmware Integrity Test (RUGGEDCOM ROS Firmware Components) The TOE performs a firmware integrity check using a SHA-256 hash to ensure that the firmware binary image is not corrupted or tampered with. At power-up, the modules compute a new hash and compare it to the pre- computed value which is decrypted using an RSA 2048 public key. If the values are same, the test is passed; otherwise, it is failed. • AES Encrypt/Decrypt CBC KAT The AES CBC KAT takes a known 256-bit key and plaintext value, which is encrypted and compared to the expected ciphertext value. If the values differ, the test is failed. The AES KAT then reverses this process by taking the ciphertext value and key, performing decryption, and comparing the result to the known plaintext value. If the values differ, the test is failed. If they are the same, the test is passed. • AES Encrypt/Decrypt GCM KAT The AES GCM KAT encrypts a known plaintext with known 256-bit key. It then compares the resultant ciphertext with the expected ciphertext hard-coded in the module. If the two values differ, then the KAT is failed. If the two values agree, then the AES-GCM KAT decrypts the ciphertext with the known keys and compares the decrypted text with the known plaintext. If they differ, then the test fails. If they are the same, then the test passes. • AES Encrypt/Decrypt CTR KAT The AES CTR KAT takes a known 256-bit key and plaintext value, which is encrypted and compared to the expected ciphertext value. If the values differ, the test fails. The AES CTR KAT the reverses this process by taking the ciphertext value and key, performing decryption, and comparing the results to the known plaintext value. If the values differ, the test is failed. If they are the same, the test passes. • HMAC KAT with SHA-1, SHA-224, SHA-256, SHA-384, and SHA-512 The HMAC implementation creates a MAC using known input data and known 256-bit key. This MAC value is then compared to the expected MAC value. If the values differ, the test fails. If they are the same, the test passes. Chapter 7 TOE Summary Specification Reference Guide 76 Protection of the TSF • SHA KAT with SHA-1, SHA-224, SHA-256, SHA-384, and SHA-512 The SHA implementation is further tested in a SHA KAT. Again, a known 256 bit input data is used and a hash is created of the input data. This hash is compared to the expected hash. If the values differ, the test fails. If they are the same, the test passes. • CTR DRBG KAT An entropy input string is used to create the seed and after initialization, the DRBG generates random bits by using this seed and provided additional input. These generated random bits are discarded. The DRBG is then reseeded with reseed entropy and an additional reseed input for creating the new seed. This new seed along with the provided second additional input generates the random bits which are compared with the known bits. If there is a match, the test passes; if there is no match, the test fails. • RSA Signature Generation/Verification KAT A known private 2048-bit (with SHA-256) key is used to sign a known block of. data, and the resultant value is compared with the expected ciphertext. If they differ, the test fails. If they are the same, then the public key is used to decrypt the ciphertext and the output is compared to the original data. If they are the same, the test passes. Otherwise, it is failed. • ECDSA Pair-wise Consistency Test The ECDSA private key is used to sign a block of data. The resulting signature is compared to the original data before it was signed. If the two values are equal, then the test fails. If the two values differ, the ECDSA public key is used to verify the signature and the resulting value is compared to the original data. If they are the same, the test is passed. Otherwise, it is failed. • Primitive “Z” Computation KAT (Crypto Library) The EC DH KAT requires two public/private key pairs obtained from one of the NIST-Approved P-521 curves. A shared secret is generated using the private key of the first key pair (derived from the P curve) with the public key of the second key pair (derived from the P curve). A second shared secret is generated using the private key from the second key pair and the public key of the first key pair. If the shared secret values differ, the test fails. If they are the same, the test passes. • Continuous Random Number Generator Test for DRBG This test is activated on the DRBG implementation whenever a fresh random value is requested. The new random number returned from the DRBG will be compared with the previous random number from the same DRBG to determine if stuck-at-constant type of failure is occurring. • Continuous Random Number Generator Test for NDRNG This test is activated on the NDRNG implementation whenever a fresh random value is requested. The new random number returned from the NDRNG will be compared with the previous random number from the same NDRNG to determine if stuck-at-constant type of failure is occurring. • RSA Pair-wise Consistency Test The RSA private key is used to sign a block of data. The resulting signature is compared to the original data before it was signed. If the two values are equal, then the test fails. If the two values differ, the RSA public key is used to verify the signature and the resulting value is compared to the original data. If they are the same, the test is passed. Otherwise, it is failed. • ECDSA Signature Generation/Verification Test The generated ECDSA private key is used to sign a known block of data, which outputs two signature components. The public key curve point is used to verify the signature. If the verification matches, the test passes. Otherwise, it fails. • ECC Full Public-key Validation Test Whenever a public key is generated for ECC Diffie-Hellman key agreement, the module will implement the elliptical curve cryptography full public key validation routine outlined in Section 5.6.2.3.2 of SP 800-56A. • EC Diffie-Hellman Public Key Assurance Test Whenever a public key is generated for Diffie-Hellman key agreement, the module will implement the elliptical curve cryptography full public key validation routine outlined in Section 5.7.1.2 of SP 800-56A. Reference Guide Chapter 7 TOE Summary Specification TOE Access 77 FPT_TUD_EXT.1 Security Administrators can download firmware updates from https://www.siemens.com/ruggedcom. These files can then be loaded onto the TOE using SFTP. The files are signed using a Siemens key. Once the files are on the TOE, the TOE decrypts the digital signature of the firmware binary using the compiled-in Siemens public key. If the signature is verified the installation can occur. If the signature fails, the installation operation stops and an error is logged. Once the signature is validated, the TOE must be reset to complete the installation. The Security Administrator can query the TOE version through the CLI shell version command. TOE Security Functional Requirements Satisfied: • FPT_APW_EXT.1 • FPT_SKP_EXT.1 • FPT_STM_EXT.1 • FPT_TST_EXT.1 • FPT_TUD_EXT.1 Section 7.1.6 TOE Access FTA_SSL_EXT.1, FTA_SSL.3, FTA_SSL.4 Local and interactive sessions with the TOE are terminated after a period of inactivity. This period can be configured by a Security Administrator using the Administration » Configure IP Services » Inactivity Timeout menu. This timeout time is valid on all interfaces. Administrators can also terminate their own session by typing “logout” on the CLI or clicking Log Out on the web interface. FTA_TAB.1 The TOE provides an access banner on the web interface and terminal-based menu prior to accessing the TOE. This banner can be configured by modifying the banner.txt file. This file can be downloaded from the device via SFTP. Once it has been modified, SFTP can again be used to upload the file to the TOE. TOE Security Functional Requirements Satisfied • FTA_SSL_EXT.1 • FTA_SSL.3 • FTA_SSL.4 • FTA_TAB.1 Section 7.1.7 Trusted Path/Channels FTP_ITC.1 Audit events are sent from the TOE to an external audit server over an SSH trusted channel. The channel is initiated by the audit server and follows all FCS_SSHS_EXT.1 requirements. As part of the channel initiation the Chapter 7 TOE Summary Specification Reference Guide 78 Trusted Path/Channels audit server sends an SSH public key to identify itself to the TOE. The TOE does not initiate any secure channels for any services. FTP_TRP.1/Admin Secure remote management is performed using SSH to the terminal-based menu or HTTPS/TLS to the web interface. These remote sessions conform to the requirements in FCS_SSHS_EXT.1 or FCS_HTTPS_EXT.1 and FCS_TLSS_EXT.1. TOE Security Functional Requirements Satisfied • FTP_ITC.1 • FTP_TRP.1/Admin Reference Guide Chapter 8 Conformance Claims Rationale Variance Between the PP and this ST 79 Conformance Claims Rationale This Security Target conforms to Part 2 extended and Part 3 conformant of the Common Criteria Standard for Information Technology Security Evaluations, Version 3.1 Release 4. This ST conforms to the ND cPP v2.0E. CONTENTS • Section 8.1, “Variance Between the PP and this ST” • Section 8.2, “Security Assurance Requirements Rationale” • Section 8.3, “Dependency Rationale” Section 8.1 Variance Between the PP and this ST There is no variance between the ND cPP v2.0E and this ST. Section 8.2 Security Assurance Requirements Rationale This ST maintains exact conformance to the ND cPP v2.0E, including the assurance requirements listed in Section 6 of the ND cPP v2.0E. Section 8.3 Dependency Rationale This ST does satisfy all the requirement dependencies of the Common Criteria. Table lists each requirement to which the TOE claims conformance with a dependency and indicates whether the dependent requirement was included. As Table 11 indicates, all dependencies have been met. Table 11: Functional Requirements Dependencies SFR ID Dependencies Dependency Met Rationale FAU_GEN.1 FPT_STM.1 ü FPT_STM_EXT.1 included (which is hierarchic to FPT_STM.1) FIA_UID.1 ü Satisfied by FIA_UIA_EXT.1, which specifies the relevant Administrator identification timing FAU_GEN.2 FAU_GEN.1 ü FAU_GEN.1 included Chapter 8 Conformance Claims Rationale Reference Guide 80 Dependency Rationale SFR ID Dependencies Dependency Met Rationale FAU_GEN.1 ü FAU_GEN.1 included FAU_STG_EXT.1 FTP_ITC.1 ü FTP_ITC.1 included FCS_CKM.2 ü FCS_CKM.2 included FCS_CKM.1 FCS_CKM.4 ü FCS_CKM.4 included FCS_CKM.1 ü FCS_CKM.1 included FCS_CKM.4 ü FCS_CKM.4 included FCS_CKM.2 FTP_ITC.1 ü FTP_ITC.1 as a secure channel that is used for import FCS_CKM.4 FCS_CKM.1 ü FCS_CKM.1 included FCS_CKM.4 ü FCS_CKM.4 included FCS_COP.1/DataEncryption FCS_CKM.1 ü FCS_CKM.1 included FCS_CKM.4 ü FCS_CKM.4 included FCS_COP.1/SigGen FCS_CKM.1 ü FCS_CKM.1 included FCS_CKM.4 ü FCS_COP.1/Hash FCS_CKM.1 ü This SFR specifies keyless hashing operations, so initialisation and destruction of keys are not relevant FCS_CKM.1 ü FCS_CKM.1 included FCS_COP.1/KeyedHash FCS_CKM.4 ü FCS_CKM.4 included FCS_HTTPS_EXT.1 FCS_TLSS_EXT.1 ü FCS_TLSS_EXT.1 included as selection-based SFR FCS_CKM.1 ü FCS_CKM.1 included FCS_CKM.2 ü FCS_CKM.2 included FCS_COP.1/DataEncryption ü FCS_COP.1/DataEncryption included FCS_COP.1/SigGen ü FCS_COP.1/SigGen included FCS_COP.1/Hash ü FCS_COP.1/Hash included FCS_COP.1/KeyedHash ü FCS_COP.1/KeyedHash included FCS_SSHS_EXT.1 FCS_RBG_EXT.1 ü FCS_RBG_EXT.1 included FCS_CKM.1 ü FCS_CKM.1 included FCS_CKM.2 ü FCS_CKM.2 included FCS_COP.1/DataEncryption ü FCS_COP.1/DataEncryption included FCS_COP.1/SigGen ü FCS_COP.1/SigGen included FCS_COP.1/Hash ü FCS_COP.1/Hash included FCS_COP.1/KeyedHash ü FCS_COP.1/KeyedHash included FCS_TLSS_EXT.1 FCS_RBG_EXT.1 ü FCS_RBG_EXT.1 included FCS_RBG_EXT.1 No dependencies ü FIA_AFL.1 FIA_UAU.1 ü Satisfied by FIA_UIA_EXT.1, which specifies the relevant Administrator authentication. Reference Guide Chapter 8 Conformance Claims Rationale Dependency Rationale 81 SFR ID Dependencies Dependency Met Rationale FIA_PMG_EXT.1 No dependencies ü FIA_UIA_EXT.1 FTA_TAB.1 ü FTA_TAB.1 included FIA_UAU_EXT.2 No dependencies ü FIA_UAU.7 FIA_UAU.1 ü Satisfied by FIA_UIA_EXT.1, which specifies the relevant Administrator authentication. FIA_X509_EXT.1/REV No dependencies ü FIA_X509_EXT.2 No dependencies ü FIA_X509_EXT.3 FCS_CKM.1 ü FCS_CKM.1 included FMT_SMR.1 ü FMT_SMR.2 included FMT_MOF.1/ManualUpdate FMT_SMF.1 ü FMT_SMF.1 included FMT_SMF.1 ü FMT_SMF.1 included FMT_MTD.1/CoreData FMT_SMR.1 ü FMT_SMR.2 included FMT_SMF.1 No dependencies ü FMT_SMR.2 FIA_UID.1 ü Satisfied by FIA_UIA_EXT.1, which specifies the relevant Administrator authentication. FPT_APW_EXT.1 No dependencies ü FPT_SKP_EXT.1 No dependencies ü FPT_STM_EXT.1 No dependencies ü FPT_TST_EXT.1 No dependencies ü FPT_TUD_EXT.1 FCS_COP.1/Hash ü FCS_COP.1/Hash included FTA_SSL_EXT.1 FIA_UAU.1 ü Satisfied by FIA_UIA_EXT.1, which specifies the relevant Administrator authentication. FTA_SSL.3 No dependencies ü FTA_SSL.4 No dependencies ü FTA_TAB.1 No dependencies ü FTP_ITC.1 No dependencies ü FTP_TRP.1/Admin No dependencies ü Chapter 8 Conformance Claims Rationale Reference Guide 82 Dependency Rationale Reference Guide Chapter 9 Acronyms and Terms Acronyms 83 Acronyms and Terms This section describes the acronyms and terms used throughout the document. CONTENTS • Section 9.1, “Acronyms” • Section 9.2, “Terms” Section 9.1 Acronyms Table 12: Acronyms Acronym Definition AEAD Authenticated Encryption with Associated Data AES Advanced Encryption Standard °C Celsius CA Certificate Authority CAVP Cryptographic Algorithm Validation Program CBC Cipher Block Chaining CC Common Criteria CEM Common Evaluation Methodology CLI Command Line Interface cPP Collaborative Protection Profile CRL Certificate Revocation List CSP Critical Security Parameters CTR Counter Mode CVL Component Validation List DHE Diffie-Hellman DRBG Deterministic Random Bit Generator DSS Digital Signature Standard EAL Evaluation Assurance Level EC Elliptical Curve Chapter 9 Acronyms and Terms Reference Guide 84 Acronyms Acronym Definition ECDH Elliptical Curve Diffie-Hellman ECDSA Elliptical Curve Digital Signature Algorithm FIPS Federal Information Processing Standards GCM Galois Counter Mode HMAC (Keyed-)Hashed Message Authentication Code HTTPS Hypertext Transfer Protocol Secure ICMP Internet Control Message Protocol IP Internet Protocol IPsec Internet Protocol Security ISO International Standards Organization IT Information Technology MAC Media Access Control MB Megabytes ND cPP Collaborative Protection Profile for Network Devices v2.0E NIST National Institute of Standards and Technology NTP Network Time Protocol OCSP Online Certificate Status Protocol OS Operating System OSP Organizational Security Policy PP Protection Profile RADIUS Remote Authentication Dial-In User Service RBG Random Bit Generator RFC Request for Comment RSA Rivest-Shamir-Adleman SAR Security Assurance Requirement SFR Security Functional Requirement SFTP Secure File Transfer Protocol SHA Secure Hash Algorithm SHS Secure Hash Standard SNMP Simple Network Management Protocol SSH Secure Shell SSL Secure Sockets Layer ST Security Target TACACS+ Terminal Access Controller Access Control System Plus Reference Guide Chapter 9 Acronyms and Terms Terms 85 Acronym Definition TCP Transmission Control Protocol TD Technical Decision TFTP Trivial File Transfer Protocol TLS Transport Layer Security TOE Target of Evaluation TSF TOE Security Functionality Section 9.2 Terms Table 13: Terms Name Definition Administrator See “Security Administrator.” Assurance Grounds for confidence that a TOE meets the SFRs. Security Administrator The terms “Administrator” and “Security Administrator” are used interchangeably in this document at present. Target of Evaluation A set of software, firmware and/or hardware possibly accompanied by guidance. TOE Security Functionality (TSF) A set consisting of all hardware, software, and firmware of the TOE that must be relied upon for the correct enforcement of the SFRs. TSF Data Data for the operation of the TSF upon which the enforcement of the requirements relies. User See “Security Administrator”. Chapter 9 Acronyms and Terms Reference Guide 86 Terms