Hewlett-Packard Hewlett-Packard Company 5900 Series, 5900CP Series, 5920 Series, 5930 Series, 10500 Series, 12500 Series and 12900 Series Switches Security Target Version 2.0 February 16, 2015 Prepared for: Hewlett-Packard Development Company, L.P. 11445 Compaq Center Drive West Houston, Texas 77070 Prepared by: Leidos Inc (formerly Science Applications International Corporation) Common Criteria Testing Laboratory 6841 Benjamin Franklin Drive, Columbia, Maryland 21046 Security Target Version 2.0, 02/16/2015 2 1. SECURITY TARGET INTRODUCTION...........................................................................................................4 1.1 SECURITY TARGET, TOE AND CC IDENTIFICATION........................................................................................4 1.2 CONFORMANCE CLAIMS.................................................................................................................................5 1.3 CONVENTIONS ................................................................................................................................................5 1.3.1 Abbreviations and Acronyms ................................................................................................................6 2. TOE DESCRIPTION ..........................................................................................................................................7 2.1 TOE OVERVIEW ...........................................................................................................................................8 2.1.1 5900 Series Switches .............................................................................................................................8 2.1.2 5900CP Series Switches ........................................................................................................................8 2.1.3 5920 Series Switches .............................................................................................................................8 2.1.4 5930 Series Switches .............................................................................................................................8 2.1.5 10500 Series Switches ...........................................................................................................................8 2.1.6 12500 Series Switches ...........................................................................................................................9 2.1.7 12900 Series Switches .........................................................................................................................10 2.2 TOE ARCHITECTURE....................................................................................................................................10 2.2.1 Modular Design ...................................................................................................................................11 2.2.2 Intelligent Resilient Framework ..........................................................................................................12 2.2.3 Multitenant Device Context.................................................................................................................13 2.2.4 Physical Boundaries.............................................................................................................................13 2.2.5 Logical Boundaries..............................................................................................................................13 2.3 TOE DOCUMENTATION ................................................................................................................................15 3. SECURITY PROBLEM DEFINITION ..........................................................................................................16 4. SECURITY OBJECTIVES ..............................................................................................................................17 4.1 SECURITY OBJECTIVES FOR THE ENVIRONMENT...........................................................................................17 5. IT SECURITY REQUIREMENTS..................................................................................................................18 5.1 EXTENDED REQUIREMENTS..........................................................................................................................18 5.2 TOE SECURITY FUNCTIONAL REQUIREMENTS .............................................................................................19 5.2.1 Security Audit (FAU) ..........................................................................................................................20 5.2.2 Cryptographic Support (FCS)..............................................................................................................21 5.2.3 User Data Protection (FDP).................................................................................................................23 5.2.4 Identification and Authentication (FIA) ..............................................................................................23 5.2.5 Security Management (FMT) ..............................................................................................................24 5.2.6 Protection of the TSF (FPT) ................................................................................................................24 5.2.7 TOE Access (FTA) ..............................................................................................................................25 5.2.8 Trusted path/channels (FTP)................................................................................................................25 5.3 TOE SECURITY ASSURANCE REQUIREMENTS...............................................................................................27 6. TOE SUMMARY SPECIFICATION..............................................................................................................27 6.1 SECURITY AUDIT..........................................................................................................................................27 6.2 CRYPTOGRAPHIC SUPPORT...........................................................................................................................28 6.3 USER DATA PROTECTION .............................................................................................................................37 6.4 IDENTIFICATION AND AUTHENTICATION ......................................................................................................37 Security Target Version 2.0, 02/16/2015 3 6.5 SECURITY MANAGEMENT.............................................................................................................................38 6.6 PROTECTION OF THE TSF .............................................................................................................................38 6.7 TOE ACCESS................................................................................................................................................39 6.8 TRUSTED PATH/CHANNELS ..........................................................................................................................40 7. PROTECTION PROFILE CLAIMS...............................................................................................................41 8. RATIONALE.....................................................................................................................................................42 8.1 TOE SUMMARY SPECIFICATION RATIONALE................................................................................................42 APPENDIX A: DOCUMENTATION FOR HP 5900, 5900CP, 5920, 5930 10500, 12500 AND 12900 SWITCHES................................................................................................................................................................44 LIST OF TABLES Table 1 TOE Series and Devices.................................................................................................................................5 Table 2: TOE Security Functional Components.....................................................................................................19 Table 3: Auditable Events.........................................................................................................................................21 Table 4: Assurance Components..............................................................................................................................27 Table 5: Cryptographic Functions ...........................................................................................................................29 Table 6: NIST SP800-56B Conformance .................................................................................................................30 Table 7 SFR Protection Profile Sources ..................................................................................................................41 Table 8 Security Functions vs. Requirements Mapping.........................................................................................43 Security Target Version 2.0, 02/16/2015 4 1. Security Target Introduction This section identifies the Security Target (ST) and Target of Evaluation (TOE) identification, ST conventions, ST conformance claims, and the ST organization. The TOE is Hewlett-Packard 5900, 5900CP, 5920, 5930, 10500, 12500 and 12900 Series Switches provided by Hewlett-Packard Development Company. Each device in the TOE is a stand-alone gigabit Ethernet switch that implements network layers 2 and 3 switching, service and routing operations. The Security Target contains the following additional sections:  TOE Description (Section 2)  Security Problem Definition (Section 3)  Security Objectives (Section 4)  IT Security Requirements (Section 5)  TOE Summary Specification (Section 6)  Protection Profile Claims (Section 7)  Rationale (Section 8). 1.1 Security Target, TOE and CC Identification ST Title – Hewlett-Packard Company 5900 Series, 5900CP Series, 5920 Series, 5930 Series, 10500 Series, 12500 Series and 12900 Series Switches Security Target ST Version – Version 2.0 ST Date – 16 February 2015 TOE Identification – Hewlett-Packard Company 5900 Series, 5900CP Series and 5920 Series all running Comware V7.1.045 Release 2311 P03, 5930 Series running Comware V7.1.045, Release R2416 10500 Series running Comware V7.1.045 Release 2111 P05, 12500 Series Switches running Comware 7.1.045, Release 7328 P03, and 12900 Series running Comware V7.1.045, Release 1005P10 Product Series Specific Devices HP 5900 HP 5900AF-48XG-4QSFP+ Switch HP 5900AF-48XGT-4QSFP+ Switch HP 5900AF-48G-4XG-2QSFP+ Switch HP 5900CP HP FlexFabric 5900CP-48XG-4QSFP+ Switch HP 5920 HP 5920AF-24XG Switch HP 5930 HP FlexFabric 5930-32QSFP+ Switch HP 10500 Series Chassis’ with HP 10500 Type A Main Processing Unit with Comware v7 Operating System (JG496A) HP 10504 Switch Chassis HP 10508 Switch Chassis HP 10508-V Switch Chassis HP 10512 Switch Chassis HP 12500 Series Chassis’ with HP 12500 Type A Main Processing Unit with HP 12504 (AC) Switch Chassis HP 12504 (DC) Switch Chassis HP 12508 (AC) Switch Chassis Security Target Version 2.0, 02/16/2015 5 Comware v7 Operating System (JG497A) HP 12508 (DC) Switch Chassis HP 12518 (AC) Switch Chassis HP 12518 (DC) Switch Chassis HP 12900 Series Chassis (Main Processing Unit (JG621A) HP FlexFabric 12910 Switch AC Chassis HP FlexFabric 12916 Switch AC Chassis Table 1 TOE Series and Devices TOE Developer – Hewlett-Packard Company Evaluation Sponsor – Hewlett-Packard Company CC Identification – Common Criteria for Information Technology Security Evaluation, Version 3.1, Revision 3, July 2009 1.2 Conformance Claims This TOE is conformant to the following CC specifications:  This ST is conformant to the Protection Profile for Network Devices, Version 1.1, 8 June 2012, as amended by Errata #2 dated 13 January 2014, and including the following optional SFRs: FCS_IPSEC_EXT.1; FCS_SSH_EXT.1; and FIA_PSK_EXT.1.  Common Criteria for Information Technology Security Evaluation Part 2: Security functional components, Version 3.1, Revision 3, July 2009.  Part 2 Extended  Common Criteria for Information Technology Security Evaluation Part 3: Security assurance components, Version 3.1 Revision 3, July 2009.  Part 3 Conformant 1.3 Conventions The following conventions have been applied in this document:  Security Functional Requirements – Part 2 of the CC defines the approved set of operations that may be applied to functional requirements: iteration, assignment, selection, and refinement. o Iteration: allows a component to be used more than once with varying operations. In the ST, iteration is indicated by a number in parentheses placed at the end of the component. For example FDP_ACC.1(1) and FDP_ACC.1(2) indicate that the ST includes two iterations of the FDP_ACC.1 requirement, (1) and (2). o Assignment: allows the specification of an identified parameter. Assignments are indicated using bold and are surrounded by brackets (e.g., [assignment]). Note that an assignment within a selection would be identified in italics and with embedded bold brackets (e.g., [[selected- assignment]]). o Selection: allows the specification of one or more elements from a list. Selections are indicated using bold italics and are surrounded by brackets (e.g., [selection]). o Refinement: allows the addition of details. Refinements are indicated using bold, for additions, and strike-through, for deletions (e.g., “… all objects …” or “… some big things …”). Note that ‘cases’ that are not applicable in a given SFR have simply been removed without any explicit identification. Security Target Version 2.0, 02/16/2015 6  The NDPP uses an additional convention – the ‘case’ – which defines parts of an SFR that apply only when corresponding selections are made or some other identified conditions exist. Only the applicable cases are identified in this ST and they are identified using bold text.  Other sections of the ST – Other sections of the ST use bolding to highlight text of special interest, such as captions. 1.3.1 Abbreviations and Acronyms AAA Authentication, Authorization and Accounting ACL Access Control List AES Advanced Encryption Standard CBC Cipher-Block Chaining CC Common Criteria for Information Technology Security Evaluation CM Configuration Management CLI Command Line Interface DH Diffie-Hellman EVB Edge Virtual Bridging FIPS Federal Information Processing Standard GbE Gigabit Ethernet HMAC Hashed Message Authentication Code IP Internet Protocol IPsec Internet Protocol Security IRF Intelligent Resilient Framework ISSU In Service Software Upgrades IT Information Technology LACP Link Aggregation Control Protocol MDC Multitenant device context MPLS Multiprotocol Label Switching NDPP Protection Profile for Network Devices OAA Open Application Architecture OSPF Open Shortest Path First PP Protection Profile QoS Quality of Service RADIUS Remote Authentication Dial In User Service RSA Rivest, Shamir and Adleman (algorithm for public-key cryptography) RTC Real-Time Clock SA Security Association SAR Security Assurance Requirement SFP Small Form-factor Pluggable SFR Security Functional Requirement SHA Secure Hash Algorithm SSH Secure Shell ST Security Target TACACS+ Terminal Access Controller Access Control System Plus TOE Target of Evaluation TRILL Transparent Interconnection of Lots of Links TSF TOE Security Functions VLAN Virtual Local Area Network Security Target Version 2.0, 02/16/2015 7 2. TOE Description The Target of Evaluation (TOE) is the Hewlett-Packard 5900, 5900 CP, 5920, 5930, 10500, 12500 and 12900 Series Switches. The 5900 Series devices in the evaluated configuration are as follows:  HP 5900AF-48XG-4QSFP+ switch  HP 5900AF-48XGT-4QSFP+ switch  HP 5900AF-48G-4XG-2QSFP+ switch. The 5900CP Series device in the evaluated configuration is the HP FlexFabric 5900CP-48XG-4QSFP+ Switch. The 5920 Series device in the evaluated configuration is the HP 5920AF-24XG switch. The 5930 Series device in the evaluated configuration is the HP FlexFabric 5930-32QSFP+ Switch. The 10500 Series devices in the evaluated configuration are as follows, each with the HP 10500 Main Processing Unit:  HP 10504 switch chassis  HP 10508 switch chassis  HP 10508-V switch chassis  HP 10512 switch chassis. The 12500 Series devices in the evaluated configuration are as follows, each with the HP 12500 Main Processing Unit:  HP 12504 (AC) switch chassis  HP 12504 (DC) switch chassis  HP 12508 (AC) switch chassis  HP 12508 (DC) switch chassis  HP 12518 (AC) switch chassis  HP 12518 (DC) switch chassis. The 12900 Series devices in the evaluated configuration are as follows, each with the HP 12900 Main Processing Unit:  HP FlexFabric 12910 Switch AC Chassis  HP FlexFabric 12916 Switch AC Chassis Each series of switches included in the TOE comprises a set of distinct devices (as identified in Section 1.1), which vary primarily according to power delivery, performance, and port density. The 5900, 5900CP, 5920 and 5930 switches have a fixed number of ports. In the evaluated configuration, they can be deployed as a single device or alternately as a group of up to four 5900, 5900CP, 5920 or 5930 Series devices connected using the HP Intelligent Resilient Framework (IRF) technology to effectively form a logical switch device. The IRF technology requires that devices be directly connected to one another using an IRF stack utilizing one or more dedicated Ethernet connections that are used to coordinate the overall logical switch configuration and also to forward applicable network traffic as necessary between attached devices. The 10500, 12500 and 12900 Series support plug-in modules, which provide additional functionality (e.g., various numbers and types of network connection ports), and security blades, which offer additional advanced security functions (e.g., firewall). With the exception of pluggable security blades, all of the available plug-in modules are included in the evaluated configuration (see below). The security blades offer additional advanced (e.g., firewall) security functions and are intended to be addressed in an alternate evaluation. As with the 5900, 5900CP, 5920 and Security Target Version 2.0, 02/16/2015 8 5930 Series, a 10500, 12500 or 12900 Series switch can be deployed as a single device or alternately as a group of devices connected using IRF technology to effectively form a logical switch device. For the 10500, 12500 and 12900 Series devices, the IRF technology does not require that switches be co-located—these Series support enhanced IRF mode, in which devices can be attached using standard Link Aggregation Control Protocol (LACP) for automatic load balancing and high availability. 2.1 TOE Overview The various switches comprising the TOE are all gigabit Ethernet switch appliances that consist of hardware and software components. While the physical form factor of each distinct series is substantially different, the underlying hardware shares a similar architecture. The software shares a common code base of a modular nature, with only the modules applicable for the specific hardware installed. 2.1.1 5900 Series Switches The HP 5900 series comprises high-density 10 gigabit Ethernet (10GbE), ultra-low latency, top-of-rack switches, suited for deployment at the server access layer of a large enterprise data center or for deployment at the data center core layer of medium-sized enterprises. They provide 48 high-density 10GbE ports and IPv6 support with full layer 2 and layer 3 features. The HP IRF is also supported, allowing up to four 5900AF switches to be grouped together and managed as a single switch with a single IP address. 2.1.2 5900CP Series Switches HP FlexFabric 5900CP Switch Series comprises a high-density, ultra-low latency, converged, top-of-rack (ToR) switch, suited for deployment at the server access layer of medium or large enterprise data centers. The HP FlexFabric 5900CP Switch Series offers 48 converged ports that support 1GbE/10GbE and 4Gbps/8Gbps Fibre Channel (FC) and IPv4/IPv6 dual stack support with full layer 2 and layer 3 features. The HP IRF is also supported, allowing up to nine HP FlexFabric 5900CP Switch Series to be grouped together and managed as a single switch with a single IP address. 2.1.3 5920 Series Switches The HP 5920 series comprises a high-density 10 gigabit Ethernet (10GbE), ultra-deep packet buffering, top-of rack switch, suited for deployments at the server access layer of large enterprise data centers. The switch provides 24 high-density 10GbE ports and IPv6 support with full layer 2 and layer 3 features. The HP IRF is also supported, allowing up to four 5920AF switches to be grouped together and managed as a single switch with a single IP address. 2.1.4 5930 Series Switches The HP FlexFabric 5930 Switch Series comprises a high performance and ultra-low-latency 40 gigabit Ethernet (40GbE) top-of-rack (ToR) data center switch suited for deployment at the aggregation or server access layer of large enterprise data centers, or at the core layer of medium-sized enterprise data centers. The switch provides 48 40GbE ports and IPv6 support with full layer 2 and layer 3 features. The HP IRF is also supported, allowing up to four 5930 switches to be grouped together and managed as a single switch with a single IP address. 2.1.5 10500 Series Switches The HP 10500 series comprises gigabit Ethernet switches designed for enterprise campus core networks that provide 10GbE/40GbE port density. They support layer 2 switching, select layer 3 services, static layer 3 routing and provide dual IP stack to transition from IPv4 to IPv6. The HP IRF is also supported, allowing up to four 10500 switches to be grouped together and managed as a single switch with a single IP address. The 10500 series supports the following optional modules, which extend the physically available ports and do not otherwise affect any of the claimed security functions:  HP 10500 16-port GbE SFP/8-port GbE Combo/2-port 10GbE XFP SE Module (JC617A)  HP 10500 48-port Gig-T SE Module (JC618A)  HP 10500 48-port GbE SFP SE Module (JC619A) Security Target Version 2.0, 02/16/2015 9  HP 10500 4-port 10GbE XFP SE Module (JC620A)  HP 10500 16-port GbE SFP/8-port GbE Combo/2-port 10GbE XFP EA Module (JC621A)  HP 10500 48-port GbE SFP EA Module (JC622A)  HP 10500 48-port Gig-T EA Module (JC623A)  HP 10500 4-port 10GbE XFP EA Module (JC624A)  HP 10500 48-port GbE SFP EB Module (JC625A)  HP 10500 16-port GbE SFP/8-port GbE Combo/2-port 10GbE XFP EB Module (JC626A)  HP 10500 4-port 10GbE XFP EB Module (JC627A)  HP 10500 16-port 10GbE SFP+ SC Module (JC628A)  HP 10500 8-port 10GbE SFP+ EB Module (JC629A)  HP 10500 8-port 10GbE SFP+ EA Module (JC630A)  HP 10500 8-port 10GbE SFP+ SE Module (JC631A)  HP 10500 32-port 10GbE SFP+ SF Module (JC755A)  HP 10500 48-port 10GbE SFP+ SF Module (JC756A)  HP 10500 4-port 40GbE QSFP+ SF Module (JC757A)  HP 10500 16-port GbE SFP / 8-port GbE Combo SE Module (JC763A)  HP 10500 8-port 40GbE QSFP+ SF Module (JG392A)  HP 10500 4-port 40GbE CFP SF Module (JG396A)  HP 10508/10508-V 640Gbps Type A Fabric Module (JC616A)  HP 10504 320Gbps Type A Fabric Module (JC615A)  HP 10512 960Gbps Type B Fabric Module (JC749A)x  HP 10512 2.88Tbps Type D Fabric Module (JC750A)  HP 10504 640Gbps Type B Fabric Module (JC751A)  HP 10504 960Gbps Type D Fabric Module (JC752A)  HP 10508 640Gbps Type B Fabric Module (JC753A)  HP 10508 1.92Tbps Type D Fabric Module (JC754A). 2.1.6 12500 Series Switches The HP 12500 series comprises routing switches with capacity for the network core or the data center and support IRF technology, allowing up to four 12500 switches to be grouped together and managed as a single switch with a single IP address. The 12500 series is intended for organizations contemplating large-scale data center or campus consolidations, business continuity and disaster recovery sites, metropolitan area network deployments, and other applications requiring a robust, high-performance switching platform. The 12500 series supports the following optional modules, which extend available network connectivity and do not otherwise affect any of the claimed security functions:  HP 12508 Fabric Module(JG798A)  HP 12518 Fabric Module(JG800A)  HP 12500 48-port Gig-T LEB Module(JC074B)  HP 12500 48-port Gig-T LEC Module(JC065B)  HP 12500 48-port GbE SFP LEB Module(JC075B)  HP 12500 48-port GbE SFP LEC Module(JC069B)  HP 12500 48-port GbE SFP LEF Module(JC660A)  HP 12500 8-port 10-GbE XFP LEB Module(JC073B)  HP 12500 8-port 10-GbE XFP LEC Module(JC068B)  HP 12500 32-port 10-GbE SFP+ REB Module(JC064B)  HP 12500 32-port 10-GbE SFP+ REC Module(JC476B)  HP 12500 8-port 10GbE SFP+ LEF Module(JC781A)  HP 12500 8-port 10GbE SFP+ LEB Module(JC780A)  HP 12500 8-port 10GbE SFP+ LEC Module(JC781A)  HP 12500 16-port 10GbE SFP+ LEB Module(JC782A)  HP 12500 16-port 10GbE SFP+ LEC Module(JC783A)  HP 12500 Power Monitor Module (JC502A) Security Target Version 2.0, 02/16/2015 10 2.1.7 12900 Series Switches The HP 12900 series comprises routing switches designed to support virtualized data centers and the evolving needs of private and public cloud deployments. These switches support full featured IPv4/IPv6, Layer 2 and 3 features and IRF technology which allows two or more 12900 switches to be grouped together and managed as a single switch with a single IP address. The 12900 series supports the following optional modules, which extend the physically available ports and do not otherwise affect any of the claimed security functions:  HP FlexFabric 12910 3.84Tbps Type B Fabric Module (JG623A)  HP FlexFabric 12910 1.92Tbps Type A Fabric Module (JG622A)  HP FlexFabric 12916 6.14Tbps Type B Fabric Module (JG636A)  HP FlexFabric 12916 2.56Tbps Type S Fabric Module (JG854A)  HP FlexFabric 12900 48-port 1/10GbE SFP+ FX Module (JG888B)  HP FlexFabric 12900 48-port 1/10GbE SFP+ FC Module (JG888A)  HP FlexFabric 12900 48-port 1/10GBASE-T FX Module (JH007A)  HP FlexFabric 12900 24-port 40GbE QSFP+ FX Module (JG889B)  HP FlexFabric 12900 12-port 40GbE QSFP+ FX Module (JH005A)  HP FlexFabric 12900 24-port 40GbE QSFP+ FC Module (JG889A)  HP FlexFabric 12900 48-port 1/10GbE SFP+ EC Module (JG626A)  HP FlexFabric 12900 12-port 40GbE QSFP+ EC Module (JG857A)  HP FlexFabric 12900 4-port 100GbE CFP EC Module (JG858A)  HP FlexFabric 12900 48-port GbE SFP EB Module (JG855A)  HP FlexFabric 12900 48-port 10/100/1000BASE-T EB Module (JG856A)  HP FlexFabric 12900 48-port 10GbE SFP+ EA Module (JG624A)  HP FlexFabric 12900 16-port 40GbE QSFP+ EA Module (JG625A) 2.2 TOE Architecture The various switches comprising the TOE share a common software code base, called Comware. Comware is special purpose appliance system software that implements various networking technologies, including: IPv4/IPv6 dual-stacks; a data link layer; layer 2 and 3 routing; Ethernet switching; VLANs; IRF routing; and Quality of Service (QoS). The evaluated version of Comware is V7.1. It should be noted that although Comware can run on a variety of underlying architectures, including VxWorks, Linux, pSOS and Windows, the only underlying architecture found in the evaluated configuration is Linux. Comware V7.1 implements full modularization and multi-process applications, and provides the following benefits:  Full modularization—Brings improvements in system availability, virtualization, multi-core multi-CPU applications, distributed computing, and dynamic loading and upgrading.  Openness—Comware V7.1 is a generic, open system based on Linux.  Improved operations—Comware V7.1 improves some detailed operations. For example, it uses preemptive scheduling to improve real-time performance. Comware V7.1 optimizes the following functions:  Virtualization—Supports N:1 virtualization.  In Service Support Updates (ISSU)—Supports ISSU for line cards.  Auxiliary CPU and OAA—Improves scalability for devices. In addition, Comware V7.1 supports new technologies for data centers, including TRILL and EVB. Security Target Version 2.0, 02/16/2015 11 Comware V7.1 comprises four planes: management; control; data; and infrastructure. Figure 1: Comware V7.1 Architecture  Infrastructure—the infrastructure plane provides basic Linux services and Comware support functions. Basic Linux services comprise basic Linux functions, C language library functions, data structure operations, and standard algorithms. Comware support functions provide software and service infrastructure for Comware processes, including all basic functions.  Data—the data plane provides data forwarding for local packets and received IPv4 and IPv6 packets at different layers.  Control—the control plane comprises all routing, signaling, and control protocols, such as MPLS, OSPF, and security control protocols. It generates forwarding tables for the data plane.  Management—the management plane provides a management interface for operators to configure, monitor, and manage Comware V7.1. The management interface comprises a Command Line Interface (CLI) accessed using SSH. The Comware V7.1 software is further decomposed into subsystems designed to implement applicable functions. For example, there are subsystems dedicated to the security management interface. There are also subsystems dedicated to the IPv4 and IPv6 network stacks as well as the applicable network protocols and forwarding, routing, etc. From a security perspective, the TOE implements NIST-validated cryptographic algorithms that support the IPsec and SSH protocols as well as digital signature services that support the secure update capabilities of the TOE. Otherwise, the TOE implements various network switching protocols and functions. The various TOE devices include the same security functions. The salient differences between the devices are the available ports and port adapters, primarily representing differences in numbers, types, and speeds of available network connections. 2.2.1 Modular Design Comware V7.1 implements full modularization based on Linux. All software features run independent processes in different spaces. A failed process does not affect other processes. Preemptive scheduling used by Linux threads enables Comware V7.1 to provide high-speed services. In addition, Linux supports multi-core, multi-CPU, and Symmetrical Multi-Processing (SMP) technologies, which can maximize multi-CPU performance. The modular design makes Comware V7.1 totally different from earlier versions. Security Target Version 2.0, 02/16/2015 12 Figure 2: Comware V7.1 Module Design  Process isolation—the modular design isolates processes to improve system availability. Each process can be managed separately. This refined management method enhances system stability and performance.  Multi-core support—Comware V7.1 supports multi-core CPU and SMP technologies besides multi-core support at the data plane. The modular design enables concurrent running of threads through direct Linux scheduling, which can maximize multi-CPU performance. More CPUs improve performance for the whole system to implement faster route convergence and less recovery time. Comware V7.1 allows a group of processes to run on a dedicated CPU set to ensure enough resources for key services. The thread preemptive scheduling and priority marking mechanisms enable real-time services to fast respond to requests even when the CPU system is busy. The multi-core CPU replaces auxiliary CPUs to complete related tasks, simplifying software operations.  On-demand operation—the modular design enables a process to load only needed functions to complete a task. Unused functions do not occupy any system resources and thus will not be attacked. This mechanism improves both system performance and security.  Modular upgrading—the modular design allows upgrades to a single feature or additions of new features without affecting other services.  Simplified software tailoring—Comware V7.1 software processes are independent of one another. This makes software tailoring much easier, without the need of re-compiling.  Open interfaces—Comware V7.1 provides APIs through dynamic Link Library for users to develop their own applications. This method is more flexible than OAA. 2.2.2 Intelligent Resilient Framework As indicated above, multiple devices in the evaluated configuration can be deployed as an IRF group. Each device in the IRF group is directly connected to the other IRF group members using an IRF stack utilizing dedicated network connections. One device in the group is designated as master and should that device fail a voting procedure ensues to elect a new master among the remaining IRF group members. All devices in the group share the same configuration, which is shared across the IRF connections when the group is formed and later when configuration changes occur. Management of the IRF group can occur via any of the IRF group members by an authorized administrator. Security Target Version 2.0, 02/16/2015 13 Once configured, the IRF group acts as a single, logical switch with a common configuration and will act to receive and forward network traffic in accordance with that common configuration. When necessary, network traffic is forwarded through the IRF connection in order to get the network traffic to and from the applicable physical network connections used to attach other network peers or clients. Note that the IRF connections are not secured (e.g., using encryption) by the TOE, so the IRF group members must be collocated and the IRF connections need to be as protected as the IRF group devices themselves. The IRF is excluded from the evaluation. 2.2.3 Multitenant Device Context Multitenant device context (MDC) is a 1:N virtualization technology. It virtualizes the data plane, control plane, and management plane of a physical device to create multiple logical devices called MDCs. MDCs use the same kernel, but their data is separated. Each MDC has its own interfaces and CPU resources. Rebooting an MDC does not affect the configuration or service of any other MDC. The modular design of Comware V7.1 enables each MDC to run its own control protocol processes on a separate control plane. A process failure of an MDC does not affect other MDCs. Note that since this technology is not covered in the NDPP, MDC was not subject to evaluation. 2.2.4 Physical Boundaries A TOE device in the 5900 Series, 5900CP Series, 5920 Series or 5930 Series is a physical network rack-mountable appliance with a fixed number of 10GbE ports (48 for the 5900 series switch, and 24 for the 5920 series switch). The list of applicable series and devices is provided in Section 1.1. A TOE device in the 10500 Series, 12500 Series or 12900 Series is a physical network rack-mountable chassis (or IRF connected group of chassis) that supports modules that provide a range of network ports varying in number, form factor (copper or fiber), and performance (1 – 10 Gb). The list of applicable series and devices is provided in Section 1.1 and the applicable modules for each series are identified in Section 2.1. The TOE can be configured to use the following components in its operational environment:  Syslog server—to receive audit records when the TOE is configured to deliver them to an external log server.  RADIUS and TACACS servers—the TOE can be configured to use external authentication servers.  Management Workstation—the TOE supports remote access to the CLI over SSHv2. As such, an administrator requires an SSHv2 client to access the CLI remotely. 2.2.5 Logical Boundaries This section summarizes the security functions provided by the TOE:  Security audit  Cryptographic support  User data protection  Identification and authentication  Security management  Protection of the TSF  TOE access  Trusted path/channels. 2.2.5.1 Security Audit The TOE is able to generate audit records of security relevant events. The TOE can be configured to store the audit records locally so they can be accessed by an administrator or alternately to send the audit records to a designated log server. Security Target Version 2.0, 02/16/2015 14 2.2.5.2 Cryptographic Support The TOE includes NIST-validated cryptographic mechanisms that provide key management, random bit generation, encryption/decryption, digital signature and secure hashing and key-hashing features in support of higher level cryptographic protocols, including IPsec and SSHv2. Note that to be in the evaluated configuration, the TOE must be configured in FIPS mode, which ensures the TOE’s configuration is consistent with the FIPS 140-2 standard. 2.2.5.3 User Data Protection The TOE performs network switching and routing functions, passing network traffic among its various physical and logical (e.g., VLAN) network connections. While implementing applicable network protocols associated with network traffic forwarding, the TOE is designed to ensure that it does not inadvertently reuse data found in network traffic. 2.2.5.4 Identification and Authentication The TOE requires users (i.e., administrators) to be successfully identified and authenticated before they can access any security management functions available in the TOE. The TOE offers both a locally connected console and a network accessible interface (SSHv2) for interactive administrator sessions. The TOE supports the local (i.e., on device) definition of administrators with usernames and passwords. Additionally, the TOE can be configured to use the services of trusted RADIUS and TACACS servers in the operational environment to support, for example, centralized user administration. 2.2.5.5 Security Management The TOE provides a CLI to access its security management functions. Security management commands are limited to administrators and are available only after they have provided acceptable user identification and authentication data to the TOE. 2.2.5.6 Protection of the TSF The TOE implements a number of features designed to protect itself to ensure the reliability and integrity of its security features. It protects particularly sensitive data such as stored passwords and cryptographic keys so that they are not accessible even by an administrator. It also provides its own timing mechanism to ensure that reliable time information is available (e.g., for log accountability). The TOE uses cryptographic means to protect communication with remote administrators. When the TOE is configured to use the services of a Syslog server or authentication servers in the operational environment, the communication between the TOE and the operational environment component is protected using encryption. The TOE includes functions to perform self-tests so that it might detect when it is failing. It also includes mechanisms so that the TOE itself can be updated while ensuring that the updates will not introduce malicious or other unexpected changes in the TOE. 2.2.5.7 TOE Access The TOE can be configured to display an informative banner that will appear prior to authentication when accessing the TOE via the console or SSH interfaces. The TOE subsequently will enforce an administrator-defined inactivity timeout value after which the inactive session will be terminated. 2.2.5.8 Trusted path/channels The TOE protects interactive communication with administrators using SSHv2 for CLI access. Using SSHv2, both integrity and disclosure protection is ensured. The TOE protects communication with external IT entities, including audit and authentication servers, using IPsec connections, which prevent unintended disclosure or modification of data. Security Target Version 2.0, 02/16/2015 15 2.3 TOE Documentation There are numerous documents that provide information and guidance for the deployment of the TOE. In particular, there are four Common Criteria specific guides that reference the security-related guidance material for all products evaluated:  Preparative Procedures for CC NDPP Evaluated Hewlett-Packard 5900 Series, 5900CP Series, 5920 Series, 5930 Series, 10500 Series, 12500 Series and 12900 Series Switches on Comware V7, V1.07, dated 2/20/2015  Command Reference for CC Supplement, Revision 1.2, dated 10/14/2014  Configuration Guide for CC Supplement, Revision 1.3, dated 10/14/2014  Comware V7.1 Platform System Log Messages, Revision .25, dated 4/21/2014. The links in Appendix A for each series can be used to find the full set of documentation for each of the evaluated switch series. The following documents (available for each series) were specifically examined during the evaluation.  Security Configuration Guide  Security Command Reference  Fundamentals Configuration Guide  Fundamentals Command Reference  Network Management and Monitoring Configuration Guide  Network Management and Monitoring Command Reference  ACL and QoS Configuration Guide  ACL and QoS Command Reference  Layer-3 IP Services Configuration Guide  Layer-3 IP Services Command Reference  Installation Guide Security Target Version 2.0, 02/16/2015 16 3. Security Problem Definition This security target includes by reference the Security Problem Definition (composed of organizational policies, threat statements, and assumption) from the NDPP. In general, the NDPP has presented a Security Problem Definition appropriate for network infrastructure devices, such as switches, and as such is applicable to the HP TOE. Security Target Version 2.0, 02/16/2015 17 4. Security Objectives Like the Security Problem Definition, this security target includes by reference the Security Objectives from the NDPP. The NDPP security objectives for the operational environment are reproduced below, since these objectives characterize technical and procedural measures each consumer must implement in their operational environment. In general, the NDPP has presented a Security Objectives appropriate for network infrastructure devices, such as switches, and as such are applicable to the HP TOE. 4.1 Security Objectives for the Environment OE.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. OE.PHYSICAL Physical security, commensurate with the value of the TOE and the data it contains, is provided by the environment. OE.TRUSTED_ADMIN TOE Administrators are trusted to follow and apply all administrator guidance in a trusted manner. Security Target Version 2.0, 02/16/2015 18 5. IT Security Requirements This section defines the Security Functional Requirements (SFRs) and Security Assurance Requirements (SARs) that serve to represent the security functional claims for the Target of Evaluation (TOE) and to scope the evaluation effort. The SFRs have all been drawn from the Protection Profile (PP): Protection Profile for Network Devices, Version 1.1, 8 June 2012 (NDPP), as amended by Errata #2. As a result, refinements and operations already performed in that PP are not identified (e.g., highlighted) here, rather the requirements have been copied from that PP and any residual operations have been completed herein. Of particular note, the NDPP made a number of refinements and completed some of the SFR operations defined in the CC and that PP should be consulted to identify those changes if necessary. The SARs are the set of SARs specified in NDPP. 5.1 Extended Requirements All of the extended requirements in this ST have been drawn from the NDPP. The NDPP defines the following extended SFRs and since they are not redefined in this ST, the NDPP should be consulted for more information in regard to those CC extensions.  FAU_STG_EXT.1: External Audit Trail Storage  FCS_CKM_EXT.4: Cryptographic Key Zeroization  FCS_IPSEC_EXT.1: Explicit: IPSEC  FCS_RBG_EXT.1: Extended: Cryptographic Operation (Random Bit Generation)  FCS_SSH_EXT.1: Explicit: SSH  FIA_PMG_EXT.1: Password Management  FIA_PSK_EXT.1: Extended: Pre-Shared Key Composition  FIA_UAU_EXT.2: Extended: Password-based Authentication Mechanism  FIA_UIA_EXT.1: User Identification and Authentication  FPT_APW_EXT.1: Extended: Protection of Administrator Passwords  FPT_SKP_EXT.1: Extended: Protection of TSF Data (for reading of all symmetric keys)  FPT_TST_EXT.1: TSF Testing  FPT_TUD_EXT.1: Extended: Trusted Update  FTA_SSL_EXT.1: TSF-initiated Session Locking. Security Target Version 2.0, 02/16/2015 19 5.2 TOE Security Functional Requirements The following table identifies the SFRs that are satisfied by the HP Switches. Requirement Class Requirement Component FAU: Security audit FAU_GEN.1: Audit Data Generation FAU_GEN.2: User identity association FAU_STG_EXT.1: External Audit Trail Storage FCS: Cryptographic support FCS_CKM.1: Cryptographic Key Generation (for asymmetric keys) FCS_CKM_EXT.4: Cryptographic Key Zeroization FCS_COP.1(1): Cryptographic Operation (for data encryption/decryption) FCS_COP.1(2): Cryptographic Operation (for cryptographic signature) FCS_COP.1(3): Cryptographic Operation (for cryptographic hashing) FCS_COP.1(4): Cryptographic Operation (for keyed-hash message authentication) FCS_IPSEC_EXT.1: Explicit: IPSEC FCS_RBG_EXT.1: Extended: Cryptographic Operation (Random Bit Generation) FCS_SSH_EXT.1: Explicit: SSH FDP: User data protection FDP_RIP.2: Full Residual Information Protection FIA: Identification and authentication FIA_PMG_EXT.1: Password Management FIA_PSK_EXT.1: Extended: Pre-Shared Key Composition FIA_UAU.7: Protected Authentication Feedback FIA_UAU_EXT.2: Extended: Password-based Authentication Mechanism FIA_UIA_EXT.1: User Identification and Authentication FMT: Security management FMT_MTD.1: Management of TSF Data (for general TSF data) FMT_SMF.1: Specification of Management Functions FMT_SMR.2: Restrictions on Security Roles FPT: Protection of the TSF FPT_APW_EXT.1: Extended: Protection of Administrator Passwords FPT_SKP_EXT.1: Extended: Protection of TSF Data (for reading of all symmetric keys) FPT_STM.1: Reliable Time Stamps FPT_TST_EXT.1: TSF Testing FPT_TUD_EXT.1: Extended: Trusted Update FTA: TOE access FTA_SSL.3: TSF-initiated Termination FTA_SSL.4: User-initiated Termination FTA_SSL_EXT.1: TSF-initiated Session Locking FTA_TAB.1: Default TOE Access Banners FTP: Trusted path/channels FTP_ITC.1: Trusted Channel FTP_TRP.1: Trusted Path Table 2: TOE Security Functional Components Security Target Version 2.0, 02/16/2015 20 5.2.1 Security Audit (FAU) 5.2.1.1 Audit Data Generation (FAU_GEN.1) FAU_GEN.1.1 The TSF shall be able to generate an audit record of the following auditable events: a) Start-up and shutdown of the audit functions; b) All auditable events for the not specified level of audit; and c) All administrative actions; d) Specifically defined auditable events listed in Table 3. 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 3. Requirement Auditable Events Additional Audit Record Contents FAU_GEN.1 None. FAU_GEN.2 None. FAU_STG_EXT.1 None. FCS_CKM.1 None. FCS_CKM_EXT.4 None. FCS_COP.1(1) None. FCS_COP.1(2) None. FCS_COP.1(3) None. FCS_COP.1(4) None. FCS_IPSEC_EXT.1 Failure to establish an IPsec SA. Establishment/Termination of an IPsec SA. Reason for failure. Non-TOE endpoint of connection (IP address) for both successes and failures. FCS_RBG_EXT.1 None. FCS_SSH_EXT.1 Failure to establish an SSH session. Establishment/Termination of an SSH session. Reason for failure Non-TOE endpoint of connection (IP address) for both successes and failures. FDP_RIP.2 None. FIA_PMG_EXT.1 None. FIA_UAU_EXT.2 All use of the authentication mechanism. Origin of the attempt (e.g., IP address). FIA_UIA_EXT.1 All use of the authentication and authentication mechanism. Provided user identity, origin of the attempt (e.g., IP address). FIA_UAU.7 None. FMT_MTD.1 None. FMT_SMF.1 None. FMT_SMR.2 None. FPT_APW_EXT.1 None. FPT_SKP_EXT.1 None. Security Target Version 2.0, 02/16/2015 21 Requirement Auditable Events Additional Audit Record Contents FPT_STM.1 Changes to the time. The old and new values for the time. Origin of the attempt (e.g., IP address). FPT_TUD_EXT.1 Initiation of update. No additional information. FPT_TST_EXT.1 None. FTA_SSL_EXT.1 Any attempts at unlocking of an interactive session. No additional information. FTA_SSL.3 The termination of a remote session by the session locking mechanism. No additional information. FTA_SSL.4 The termination of an interactive session. No additional information. FTA_TAB.1 None. FTP_ITC.1 Initiation of the trusted channel. Termination of the trusted channel. Failure of the trusted channel functions. Identification of the initiator and target of failed trusted channels establishment attempt. FTP_TRP.1 Initiation of the trusted channel. Termination of the trusted channel. Failures of the trusted path functions. Identification of the claimed user identity. Table 3: Auditable Events 5.2.1.2 User Identity Association (FAU_GEN.2) 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. 5.2.1.3 External Audit Trail Storage (FAU_STG_EXT.1) 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 implementing the [IPsec] protocol. 5.2.2 Cryptographic Support (FCS) 5.2.2.1 Cryptographic Key Generation (for asymmetric keys) (FCS_CKM.1) FCS_CKM.1.1 Refinement: The TSF shall generate asymmetric cryptographic keys used for key establishment in accordance with [ o NIST Special Publication 800-56B, 'Recommendation for Pair-Wise Key Establishment Schemes Using Integer Factorization Cryptography' for RSA-based key establishment schemes] and specified cryptographic key sizes equivalent to, or greater than, a symmetric key strength of 112 bits. 5.2.2.2 Cryptographic Key Zeroization (FCS_CKM_EXT.4) FCS_CKM_EXT.4.1 The TSF shall zeroize all plaintext secret and private cryptographic keys and CSPs when no longer required. 5.2.2.3 Cryptographic Operation (for data encryption/decryption) (FCS_COP.1(1)) FCS_COP.1(1).1 Refinement: The TSF shall perform [encryption and decryption] in accordance with a specified cryptographic algorithm [AES operating in [CBC, [CTR]]] and cryptographic key sizes 128-bits and 256-bits that meets the following:  FIPS PUB 197, ‘Advanced Encryption Standard (AES)’ Security Target Version 2.0, 02/16/2015 22  [NIST SP 800-38A]. 5.2.2.4 Cryptographic Operation (for cryptographic signature) (FCS_COP.1(2)) FCS_COP.1(2).1 Refinement: The TSF shall perform cryptographic signature services in accordance with a [ (1) RSA Digital Signature Algorithm (rDSA) with a key size (modulus) of 2048 bits or greater] that meets the following: Case: RSA Digital Signature Algorithm o FIPS PUB 186-2 or FIPS PUB 186-3, “Digital Signature Standard” 5.2.2.5 Cryptographic Operation (for cryptographic hashing) (FCS_COP.1(3)) FCS_COP.1(3).1 Refinement: The TSF shall perform cryptographic hashing services in accordance with a specified cryptographic algorithm [SHA-1, SHA-256, SHA-512] and message digest sizes [160, 256, 512] bits that meet the following: FIPS Pub 180-3, ‘Secure Hash Standard.’ 5.2.2.6 Cryptographic Operation (for keyed-hash message authentication) (FCS_COP.1(4)) FCS_COP.1(4).1 Refinement: The TSF shall perform keyed-hash message authentication in accordance with a specified cryptographic algorithm HMAC-[SHA-1, SHA-256], key size [160 bits, 256 bits], and message digest sizes [160, 256] bits that meet the following: FIPS Pub 198-1, ‘The Keyed-Hash Message Authentication Code’, and FIPS Pub 180-3, ‘Secure Hash Standard.’ 5.2.2.7 Explicit: IPSEC (FCS_IPSEC_EXT.1) FCS_IPSEC_EXT.1.1 The TSF shall implement the IPsec architecture as specified in RFC 4301. FCS_IPSEC_EXT.1.2 The TSF shall implement [tunnel mode, transport mode]. FCS_IPSEC_EXT.1.3 The TSF shall have a nominal, final entry in the SPD that matches anything that is otherwise unmatched, and discards it. FCS_IPSEC_EXT.1.4 The TSF shall implement the IPsec protocol ESP as defined by RFC 4303 using [the cryptographic algorithms AES-CBC-128 (as specified by RFC 3602) together with a Secure Hash Algorithm (SHA)-based HMAC, AES-CBC-256 (as specified by RFC 3602) together with a Secure Hash Algorithm (SHA)-based HMAC, [no other algorithms]]. FCS_IPSEC_EXT.1.5 The TSF shall implement the protocol: [IKEv1 as defined in RFCs 2407, 2408, 2409, RFC 4109, [no other RFCs for extended sequence numbers], and [RFC 4868 for hash functions]]. FCS_IPSEC_EXT.1.6 The TSF shall ensure the encrypted payload in the [IKEv1] protocol uses the cryptographic algorithms AES-CBC-128, AES-CBC-256 as specified in RFC 6379 and [no other algorithm]. FCS_IPSEC_EXT.1.7 The TSF shall ensure that IKEv1 Phase 1 exchanges use only main mode. FCS_IPSEC_EXT.1.8 The TSF shall ensure that [IKEv1 SA lifetimes can be established based on [number of packets/number of bytes; length of time, where the time values can be limited to: 24 hours for Phase 1 SAs and 8 hours for Phase 2 SAs]]. FCS_IPSEC_EXT.1.9 The TSF shall ensure that all IKE protocols implement DH Groups 14 (2048-bit MODP), and [no other DH groups]. FCS_IPSEC_EXT.1.10 The TSF shall ensure that all IKE protocols perform Peer Authentication using the [RSA] algorithm and Pre-shared Keys. Security Target Version 2.0, 02/16/2015 23 5.2.2.8 Extended: Cryptographic Operation (Random Bit Generation) (FCS_RBG_EXT.1) FCS_RBG_EXT.1.1 The TSF shall perform all random bit generation (RBG) services in accordance with [NIST Special Publication 800-90 using [CTR_DRBG (AES)]] seeded by an entropy source that accumulated entropy from [a software-based noise source]. FCS_RBG_EXT.1.2 The deterministic RBG shall be seeded with a minimum of [256 bits] of entropy at least equal to the greatest security strength of the keys and hashes that it will generate. 5.2.2.9 Explicit: SSH (FCS_SSH_EXT.1) FCS_SSH_EXT.1.1 The TSF shall implement the SSH protocol that complies with RFCs 4251, 4252, 4253, 4254, and [5656]. FCS_SSH_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_SSH_EXT.1.3 The TSF shall ensure that, as described in RFC 4253, packets greater than [256K] bytes in an SSH transport connection are dropped. FCS_SSH_EXT.1.4 The TSF shall ensure that the SSH transport implementation uses the following encryption algorithms: AES-CBC-128, AES-CBC-256, [no other algorithms]. FCS_SSH_EXT.1.5 The TSF shall ensure that the SSH transport implementation uses [SSH_RSA] and [no other public key algorithms] as its public key algorithm(s). FCS_SSH_EXT.1.6 The TSF shall ensure that data integrity algorithms used in SSH transport connection is [hmac-sha1, hmac-sha1-96]. FCS_SSH_EXT.1.7 The TSF shall ensure that diffie-hellman-group14-sha1 and [no other methods] are the only allowed key exchange methods used for the SSH protocol. 5.2.3 User Data Protection (FDP) 5.2.3.1 Full Residual Information Protection (FDP_RIP.2) FDP_RIP.2.1 The TSF shall ensure that any previous information content of a resource is made unavailable upon the [allocation of the resource to] all objects. 5.2.4 Identification and Authentication (FIA) 5.2.4.1 Extended: Pre-Shared Key Composition (FIA_PSK_EXT.1) FIA_PSK_EXT.1.1 The TSF shall be able to use pre-shared keys for IPsec. FIA_PSK_EXT.1.2 The TSF shall be able to accept text-based pre-shared keys that:  are 22 characters and [[lengths from 15 to 128 characters]];  composed of any combination of upper and lower case letters, numbers, and special characters (that include: “!”, “@”, “#”, “$”, “%”, “^”, “&”, “*”, “(“, and “)”). FIA_PSK_EXT.1.3 The TSF shall condition the text-based pre-shared keys by using [[the bit representation of the ASCII coding of the entered characters as the key]] and be able to [accept bit- based pre-shared keys]. 5.2.4.2 Password Management (FIA_PMG_EXT.1) FIA_PMG_EXT.1.1 The TSF shall provide the following password management capabilities for administrative passwords: 1. Passwords shall be able to be composed of any combination of upper and lower case letters, numbers, and the following special characters: [“!”, “@”, “#”, “$”, “%”, “^”, “&”, “*”, “(”, “)”, [“'”, “+”, “,”, “-”, “.”, “/”, “:”, “;”, “<”, “=”, “>”, “[”, “\”, “]”, “_”, “`”, “{”, “}”, and “~”]]; 2. Minimum password length shall settable by the Security Administrator, and support passwords of 15 characters or greater; Security Target Version 2.0, 02/16/2015 24 5.2.4.3 Protected Authentication Feedback (FIA_UAU.7) FIA_UAU.7.1 The TSF shall provide only obscured feedback to the administrative user while the authentication is in progress at the local console. 5.2.4.4 Extended: Password-based Authentication Mechanism (FIA_UAU_EXT.2) FIA_UAU_EXT.2.1 The TSF shall provide a local password-based authentication mechanism, [[and access to external RADIUS and TACACS]] to perform administrative user authentication. 5.2.4.5 User Identification and Authentication (FIA_UIA_EXT.1) 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;  [[network switching services]]. FIA_UIA_EXT.1.2 The TSF shall require each administrative user to be successfully identified and authenticated before allowing any other TSF-mediated actions on behalf of that administrative user. 5.2.5 Security Management (FMT) 5.2.5.1 Management of TSF Data (for general TSF data) (FMT_MTD.1) FMT_MTD.1.1 The TSF shall restrict the ability to manage the TSF data to the Security Administrators. 5.2.5.2 Specification of Management Functions (FMT_SMF.1) 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 update the TOE, and to verify the updates using the [digital signature] capability prior to installing those updates; [  Ability to configure the cryptographic functionality]. 5.2.5.3 Restrictions on Security Roles (FMT_SMR.2) FMT_SMR.2.1 The TSF shall maintain the roles:  Authorized 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  Authorized Administrator role shall be able to administer the TOE locally;  Authorized Administrator role shall be able to administer the TOE remotely; are satisfied. 5.2.6 Protection of the TSF (FPT) 5.2.6.1 Extended: Protection of Administrator Passwords (FPT_APW_EXT.1) 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. 5.2.6.2 Extended: Protection of TSF Data (for reading of all symmetric keys) (FPT_SKP_EXT.1) FPT_SKP_EXT.1.1 The TSF shall prevent reading of all pre-shared keys, symmetric key, and private keys. 5.2.6.3 Reliable Time Stamps (FPT_STM.1) FPT_STM.1.1 The TSF shall be able to provide reliable time stamps for its own use. Security Target Version 2.0, 02/16/2015 25 5.2.6.4 TSF Testing (FPT_TST_EXT.1) FPT_TST_EXT.1.1 The TSF shall run a suite of self tests during initial start-up (on power on) to demonstrate the correct operation of the TSF. 5.2.6.5 Extended: Trusted Update (FPT_TUD_EXT.1) FPT_TUD_EXT.1.1 The TSF shall provide security administrators the ability to query the current version of the TOE firmware/software. FPT_TUD_EXT.1.2 The TSF shall provide security administrators the ability to initiate updates to TOE firmware/software. FPT_TUD_EXT.1.3 The TSF shall provide a means to verify firmware/software updates to the TOE using a [digital signature mechanism] prior to installing those updates. 5.2.7 TOE Access (FTA) 5.2.7.1 TSF-initiated Termination (FTA_SSL.3) FTA_SSL.3.1 Refinement: The TSF shall terminate a remote interactive session after a Security Administrator-configurable time interval of session inactivity. 5.2.7.2 User-initiated Termination (FTA_SSL.4) FTA_SSL.4.1 The TSF shall allow Administrator-initiated termination of the Administrator’s own interactive session. 5.2.7.3 TSF-initiated Session Locking (FTA_SSL_EXT.1) FTA_SSL_EXT.1.1 The TSF shall, for local interactive sessions, [terminate the session] after a Security Administrator-specified time period of inactivity. 5.2.7.4 Default TOE Access Banners (FTA_TAB.1) FTA_TAB.1.1 Refinement: Before establishing an administrative user session the TSF shall display a Security Administrator-specified advisory notice and consent warning message regarding use of the TOE. 5.2.8 Trusted path/channels (FTP) 5.2.8.1 Trusted Channel (FTP_ITC.1) FTP_ITC.1.1 Refinement: The TSF shall use [IPsec] to provide a trusted communication channel between itself and authorized IT entities supporting the following capabilities: audit server, [[authentication server]] 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 [transmitting audit records to an audit server, and external authentication functions]. 5.2.8.2 Trusted Path (FTP_TRP.1) FTP_TRP.1.1 Refinement: The TSF shall use [SSH] to provide a trusted communication path between itself and 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 detection of modification of the communicated data. FTP_TRP.1.2 Refinement: The TSF shall permit remote administrators to initiate communication via the trusted path. Security Target Version 2.0, 02/16/2015 26 FTP_TRP.1.3 The TSF shall require the use of the trusted path for initial administrator authentication and all remote administrative actions. Security Target Version 2.0, 02/16/2015 27 5.3 TOE Security Assurance Requirements The security assurance requirements for the TOE are included by reference from the NDPP. Requirement Class Requirement Component ADV: Development ADV_FSP.1 Basic functional specification AGD: Guidance documents AGD_OPE.1: Operational user guidance AGD_PRE.1: Preparative procedures ALC: Life-cycle support ALC_CMC.1 Labelling of the TOE ALC_CMS.1 TOE CM coverage ATE: Tests ATE_IND.1 Independent testing - conformance AVA: Vulnerability assessment AVA_VAN.1 Vulnerability survey Table 4: Assurance Components Consequently, the assurance activities specified in NDPP apply to the TOE evaluation. 6. TOE Summary Specification This chapter describes the security functions:  Security audit  Cryptographic support  User data protection  Identification and authentication  Security management  Protection of the TSF  TOE access  Trusted path/channels. 6.1 Security Audit The TOE is designed to be able to generate log records for a wide range of security relevant and other events as they occur. The events that can cause an audit record to be logged include starting and stopping the audit function, any use of an administrator command via the CLI interface, as well as all of the events identified in Table 3 (which corresponds to the audit events specified in NDPP). Note that the only protocol (i.e., IPsec, SSH) failures auditable by the TOE are authentication failures for user-level connections. The generated audit records identify the date and time, the nature or type of the triggering event, an indication of whether the event succeeded, failed or had some other outcome, and the identity of the agent (e.g. user) responsible for the event (e.g., user or network host). The logged audit records also include event-specific content that includes at least all of the content required in Table 3. The TOE includes an internal log implementation that can be used to store and review audit records locally. The maximum storage space reserved for the local log file can be configured to a range between 1 and 10MB. When the local log storage is full, the TOE will overwrite the oldest records with new records. Only users with the role network-admin, network-operator, or level-15 can access the local audit trail. Alternately, the TOE can be configured to send generated audit records to an external Syslog server using IPsec. Note that audit records are not buffered for transmission to the syslog server. If the connection to the syslog server goes down, generated audit records are not queued and will not be transmitted to the syslog server when the connection is re-established. However, audit records will still be delivered to any other configured audit destinations, such as the log buffer and local log file. Additionally, the TOE generates audit records when connection to the syslog server is lost and when it is restored, and these audit records are sent to any other Security Target Version 2.0, 02/16/2015 28 configured audit destinations. Therefore, the administrator is advised to ensure additional audit destinations are configured so that generated audit records will still be available for review in the event of loss of connectivity to the syslog server. In addition, multiple log servers can be configured to provide redundancy. The Security Audit function is designed to satisfy the following security functional requirements:  FAU_GEN.1: The TOE can generate audit records for events include starting and stopping the audit function, administrator commands, and all other events identified in Table 3. Furthermore, each audit record identifies the date/time, event type, outcome of the event, responsible subject/user, as well as the additional event-specific content indicated in Table 3.  FAU_GEN.2: The TOE identifies the responsible user for each event based on the specific administrator or network entity (identified by IP address) that caused the event.  FAU_STG_EXT.1: The TOE can be configured to export audit records to an external Syslog server and can be configured to use IPsec for communication with the Syslog server. 6.2 Cryptographic Support The TOE includes NIST-validated cryptographic algorithms providing supporting cryptographic functions. The following functions have been certified in accordance with the identified standards. Functions Standards Certificates Asymmetric key generation Domain parameter generation (key size 2048 bits) NIST Special Publication 800- 56B Component Test #343 (for 5900, 5900CP and 5920) #432 (for 5930) #342 (for 10500) #340 (for 12500) #364 (for 12900) Encryption/Decryption AES CBC and CTR (128 and 256 bit key lengths) FIPS PUB 197 NIST SP 800-38A AES #2945, #2985 (for 5900, 5900CP and 5920) #3208, #3207 (for 5930) #2944, #2986 (for 10500) #2942, #2987 (for 12500) #2989, #2988 (for 12900) Cryptographic signature services RSA Digital Signature Algorithm (rDSA) (modulus 2048 bits) FIPS PUB 186-2 FIPS PUB 186-3 RSA #1548 (for 5900, 5900CP and 5920) #1629 ( for 5930) #1547 (for 10500) #1545 (for 12500) #1566 (for 12900) Cryptographic hashing SHA-1, SHA-256 and SHA-512 (digest sizes FIPS Pub 180-3 SHA Security Target Version 2.0, 02/16/2015 29 Functions Standards Certificates 160 , 256 and 512 bits) #2481, #2506 (for 5900, 5900CP and 5920) #2654, #2653 (for 5930) #2480, #2507 (for 10500) #2478, #2508 (for 12500) #2510, #2509 (for 12900) Keyed-hash message authentication HMAC-SHA-1 (block size 512 bits, key size 160 bits, and digest size 160 bits) FIPS Pub 198-1 FIPS Pub 180-3 HMAC #1868, #1891 (for 5900, 5900CP and 5920) #2021, #2020 (for 5930) #1867, #1892 (for 10500) #1865, #1893 (for 12500) #1895, #1894 (for 12900) HMAC-SHA-256 (key size 256 bits and digest size 256 bits ) FIPS Pub 198-1 FIPS Pub 180-3 HMAC #1868, #1891 (for 5900, 5900CP and 5920) #2021, #2020 (for 5930) #1867, #1892 (for 10500) #1865, #1893 (for 12500) #1895, #1894 (for 12900) Random bit generation CTR_DRBG (AES) with one independent software-based noise source of 256 bits of non-determinism NIST Special Publication 800-90 DRBG #548 (for 5900, 5900CP and 5920) #681 (for 5930) #547 (for 10500) #545 (for 12500) #571 (for 12900) Table 5: Cryptographic Functions The following table demonstrates that the TSF complies with 800-56B. The table identifies the sections in 800-56B that are implemented by the TSF; and the “should”, “should not”, and “shall not” conditions from the publication along with an indication of whether the TOE conforms to those conditions with deviations rationalized. Key establishment is among the identified sections. NIST SP800-56B Section Reference “should”, “should not”, or “shall not” Implemented accordingly? Rationale for deviation 5.6 should yes 5.8 shall not no RSA-OAEP is not supported. The device supports RSA-PKCS1 Padding 5.9 shall not (first occurrence) yes 5.9 shall not (second occurrence) yes 6.1 should not yes Security Target Version 2.0, 02/16/2015 30 NIST SP800-56B Section Reference “should”, “should not”, or “shall not” Implemented accordingly? Rationale for deviation 6.1 should (first occurrence) yes 6.1 should (second occurrence) yes 6.1 should (third occurrence) yes 6.1 should (fourth occurrence) yes 6.1 shall not (first occurrence) yes 6.1 shall not (second occurrence) yes 6.2.3 should yes 6.5.1 should yes 6.5.2 should yes 6.5.2.1 should yes 6.6 shall not yes 7.1.2 should yes 7.2.1.3 should yes 7.2.1.3 should not yes 7.2.2.3 should (first occurrence) no RSA-OAEP is not supported. The device supports RSA-PKCS1 Padding 7.2.2.3 should (second occurrence) no RSA-OAEP is not supported. The device supports RSA-PKCS1 Padding 7.2.2.3 should (third occurrence) no RSA-OAEP is not supported. The device supports RSA-PKCS1 Padding 7.2.2.3 should (fourth occurrence) no RSA-OAEP is not supported. The device supports RSA-PKCS1 Padding 7.2.2.3 should not no RSA-OAEP is not supported. The device supports RSA-PKCS1 Padding 7.2.2.3 shall not no RSA-OAEP is not supported. The device supports RSA-PKCS1 Padding 7.2.3.3 should (first occurrence) no RSA-KEM-KWS is not supported 7.2.3.3 should (second occurrence) no RSA-KEM-KWS is not supported 7.2.3.3 should (third occurrence) no RSA-KEM-KWS is not supported 7.2.3.3 should (fourth occurrence) no RSA-KEM-KWS is not supported 7.2.3.3 should (fifth occurrence) no RSA-KEM-KWS is not supported 7.2.3.3 should not no RSA-KEM-KWS is not supported 8 should yes 8.3.2 should not yes Table 6: NIST SP800-56B Conformance The TOE uses a software-based deterministic random bit generator (DRBG) that complies with NIST SP 800-90, using CTR_DRBG (AES). The entropy used to seed the DRBG is a 256-bit value obtained from the Comware entropy source. The design architecture of the Comware entropy source is the same as the architecture of the Linux kernel entropy pool. The noise sources for the Comware entropy pool include interrupt, process scheduling and memory allocation. Security Target Version 2.0, 02/16/2015 31 The TOE is designed to zeroize secret and private cryptographic keys and critical security parameters (CSPs) when they are no longer required by the TOE. The following table identifies the applicable secret and private cryptographic keys and CSPs, and summarizes how and when they are deleted. Note that where identified zeroization occurs as follows: 1) when deleted from FLASH, the previous value is overwritten once with zeroes; 2) when added or changed in FLASH, any old value is overwritten completely with the new value; and, 3) the zeroization of values in RAM is achieved by overwriting once with zeroes. Note that only some of the keys and CSPs are applicable to the evaluation. Also note that where identified zeroization occurs as follows: 1) when deleted from FLASH, the previous value is overwritten once with zeroes; 2) when added or changed in FLASH, any old value is overwritten completely with the new value; and, 3) the zeroization of values in RAM is achieved by overwriting once with zeroes. # Key/ CSP Name Generation/ Algorithm Key Size Description Storage Zeroization Public key management CSP1-1 RSA private key CTR_DRBG (AES)/RSA 2048 bits Identity certificates for the security appliance itself and also used in IPsec and SSH negotiations. FLASH (cipher text / AES-CTR 256) Using CLI command “public-key local destroy rsa …” to zeroize. CSP1-2 DSA private key (note that DSA is not included in the evaluated configuration) CTR_DRBG (AES)/DSA 2048 bits Identity certificates for the security appliance itself and also used in SSH negotiations. FLASH (cipher text /AES-CTR 256) Using CLI command “public-key local destroy dsa …” to zeroize CSP1-3 Public keys DSA / RSA RSA:1024 ~ 2048 bits DSA: 1024 ~ 2048 bits Note: 192, 224 –bit keys are not used in the evaluated configuration Public keys of peers to validate the digital signature FLASH(plain text) Peer public keys exist in a FLASH start-up configuration file. Using CLI commands “undo public-key peer “ and “save” to zeroize the public keys. IPsec CSP2-1 IPsec authentication keys Generated using IKE protocol (CTR_DRBG (AES)+HMAC- SHA1/HMAC- SHA256+DH). Algorithms: HMAC-SHA1-96 160 bits Used for authenticating the IPsec traffic RAM (plain text) Zeroized upon deleting the IPsec session. CSP2-2 IPsec encryption keys Generated using IKE protocol (CTR_DRBG (AES)+HMAC- SHA1/HMAC- SHA256+DH). Algorithms: AES 128 bits 192 bits 256 bits Note: 192 – bit keys are not used in the evaluated configuration Used for encrypting the IPsec traffic RAM (plain text) Zeroized upon deleting the IPsec session. Security Target Version 2.0, 02/16/2015 32 # Key/ CSP Name Generation/ Algorithm Key Size Description Storage Zeroization CSP2-3 IPsec authentication keys HMAC-SHA1-96 160 bits Manually configured key used for authenticating the IPsec traffic. FLASH (cipher text / AES-CTR 256) and RAM (plain text) Keys will be zeroized using CLI commands “undo sa hex-key authentication …” and “ save”, CSP2-4 IPsec encryption keys AES 128 bits 192 bits 256 bits Note: 192 – bit keys are not used in the evaluated configuration Manually configured key used for encrypting the IPsec traffic. FLASH (cipher text / AES-CTR 256) and RAM (plain text) Keys will be zeroized using CLI commands “undo sa hex-key encryption …” and “ save”, IKE CSP3-1 IKE pre-shared keys Shared Secret 15 ~ 128 bytes Entered by the Crypto- Officer in plain text form and used for authentication during IKE FLASH(ciphe r text/ AES- CTR 256) and RAM (plain) Keys will be zeroized using CLI commands “undo pre-shared-key …” and “ save”, CSP3-2 IKE RSA Authentication private Key RSA 2048 bits private key used for IKE protocol during the handshake RAM(plain text) Automatically zeroized upon handshake finishing CSP3-3 IKE DSA Authentication private Key DSA 2048 bits private key used for IKE protocol during the handshake RAM(plain text) Automatically zeroized upon handshake finishing CSP3-4 IKE Diffie- Hellman Key Pairs CTR_DRBG (AES) / DH 2048 bits Key agreement for IKE RAM (plain text) Automatically zeroized upon handshake finishing CSP3-5 IKE Authentication key Generated using IKE (CTR_DRBG (AES)+HMAC- SHA1/HMAC- SHA256+DH). Algorithms: HMAC-SHA1, HMAC-SHA256 160 bits 256 bits Used for authenticating IKE negotiations RAM (plain text) Zeroized upon deleting the IKE session. CSP3-6 IKE Encryption Key Generated using IKE (CTR_DRBG (AES)+HMAC- SHA1/HMAC- SHA256+DH). Algorithms: AES 128 bits, 192 bits, 256 bits Note: 192 – bit keys are not used in the evaluated configuration Used for encrypting IKE negotiations RAM (plain text) Zeroized upon deleting the IKE session. SSH Security Target Version 2.0, 02/16/2015 33 # Key/ CSP Name Generation/ Algorithm Key Size Description Storage Zeroization CSP4-1 SSH RSA Private key RSA 2048 bits private key used for SSH protocol during handshake RAM(plain text) Automatically zeroized upon finishing handshake. CSP4-2 SSH Diffie- Hellman Key Pairs CTR_DRBG (AES) / DH 2048 bits Key agreement for SSH sessions. RAM (plain text) Automatically zeroized upon finishing handshake. CSP4-3 SSH Session encryption key Generated using the SSH protocol(CTR_D RBG(AES)+SHA 1+DH) Algorithms: AES 128 bits, 256 bits Key used for encrypting SSH session. RAM (plain text) Automatically zeroized when SSH session terminated. CSP4-4 SSH Session authentication key Generated using the SSH protocol(CTR_D RBG(AES)+SHA 1+DH) Algorithms: HMAC-SHA1, HMAC-SHA1-96 160 bits Key used for authenticating SSH session. RAM (plain text) Automatically zeroized when SSH session terminated. AAA CSP5-1 User Passwords Secret 15 ~ 63 bytes Critical security parameters used to authenticate the administrator login. FLASH(ciphe r text/ AES- CTR 256) and RAM (plain) Use CLI command “password” to set new password, or use CLI command “undo local- user …” to zeroize the password and delete user account. CSP5-2 Super password Secret 15 ~ 63 bytes Critical security parameters used to authenticate privilege promoting. FLASH(ciphe r text/ AES- CTR 256) and RAM (plain) Use CLI command “undo super password” to zeroize the super password. CSP5-3 RADIUS shared secret keys Shared Secret 15 ~ 64 bytes Used for authenticating the RADIUS server to the security appliance and vice versa. Entered by the Security administrator in plain text form and stored in cipher text form. FLASH(ciphe r text/ AES- CTR 256) and RAM (plain) Keys will be zeroized using following commands: “undo primary authentication”, ““undo primary accounting”, “undo secondary authentication”, ““undo secondary accounting”. Security Target Version 2.0, 02/16/2015 34 # Key/ CSP Name Generation/ Algorithm Key Size Description Storage Zeroization CSP5-4 TACACS+ shared secret keys Shared Secret 15~255 bytes Used for authenticating the TACACS+ server to the security appliance and vice versa. Entered by the Security administrator in plain text form and stored in cipher text form. FLASH(ciphe r text/ AES- CTR 256) and RAM (plain) Keys will be zeroized using following commands: “undo primary authentication”, ““undo primary accounting”, ““undo primary authorization”, “undo secondary authentication”, ““undo secondary accounting”, ““undo secondary authorization”. Random Bits Generation CSP6-1 DRBG seed Entropy / SP 800‐90 CTR_DRBG 256 bits Input to the DRBG that determines the internal state of the DRBG RAM (plaintext) Automatically zeroized when DRBG initialized CSP6-2 DRBG V SP 800‐90 CTR_DRBG 128 bits Generated by entropy source via the CTR_DRBG derivation function RAM (plaintext) Resetting or rebooting the security appliance CSP6-3 DRBG Key SP 800‐90 CTR_DRBG 256 bits Generated by entropy source via the CTR_DRBG derivation function RAM (plaintext) Resetting or rebooting the security appliance SNMPv3 CSP7-1 SNMPv3 Authentication Key SHA1 160 bits Used to verify SNMPv3 packet. FLASH(ciphe r text/ AES- CTR 256) and RAM (plain) Using CLI command “undo snmp- agent usm-user v3 ...” to zeroize CSP7-2 SNMPv3 Encryption Key AES 128 bits Used to encrypt SNMPv3 packet. FLASH(ciphe r text/ AES- CTR 256) and RAM (plain) Using CLI command “undo snmp- agent usm-user v3 ...” to zeroize TLS (note that TLS is not included in the evaluated configuration) Security Target Version 2.0, 02/16/2015 35 # Key/ CSP Name Generation/ Algorithm Key Size Description Storage Zeroization CSP8-1 TLS Server RSA private key RSA 2048 bits private key used for TLS negotiations. RAM (plain text) Automatically zeroized when handshake finishing CSP8-2 TLS Master secret Generated using the TLS protocol (CTR_DRBG (AES) + SHA1+MD5 + RSA) 384 bits Shared secret used for creating TLS traffic keys. RAM (plain text) Automatically zeroized when session terminated. CSP8-3 TLS Traffic encryption key Generated using the TLS protocol (SHA1+MD5) Algorithms: AES 128 bits 256 bits Used for encrypting TLS data. RAM (plain text) Automatically zeroized when session terminated. CSP8-4 TLS traffic authentication key Generated using the TLS protocol (SHA1+MD5) Algorithms: HMAC-SHA1 160 bits Used for authenticating HTTPS data. RAM (plain text) Automatically zeroized when session terminated. Table 6: Key/CSP Zeroization Summary These supporting cryptographic functions are included to support the SSHv2 (RFCs 4251, 4252, 4253, and 4254) secure communication protocol. The TOE supports SSHv2 with AES (CBC) 128 or 256 bit ciphers, in conjunction with HMAC-SHA-1 or HMAC- SHA-1-96, and RSA (with diffie-hellman-group14-sha1 for the key exchange method). While DES and 3DES (CBC), HMAC-MD5 and HMAC-MD5-96, as well as diffie-hellman-group-1 and diffie-hellman-exchange are all implemented, they are disabled while the TOE is operating in CC/FIPS mode. SSHv2 connections are rekeyed prior to reaching 228 packets; the default authentication timeout period is 60 seconds allowing clients to retry only 3 times; both public-key and password based authentication can be configured; and packets are limited to 256K bytes. Note that the TOE manages a packet counter for each SSH session so that it can initiate a new key exchange when the 228 packet limit is reached. Whenever the timeout period or authentication retry limit is reached, the TOE closes the applicable TCP connection and releases the SSH session resources. As SSH packets are being received, the TOE uses a buffer to build all packet information. Once complete, the packet is checked to ensure it can be appropriately decrypted. However, if it is not complete when the buffer becomes full (256K bytes) the packet will be dropped. The TOE includes an implementation of IPsec in accordance with RFC 4301. The TOE’s implementation of IPsec supports both tunnel mode and transport mode. The TOE implements the Encapsulating Security Payload (ESP) IPsec protocol, as defined by RFC 4303, supporting AES-CBC-128 with HMAC-SHA1 and AES-CBC-256 with HMAC-SHA1 (both specified by RFC 3602). The TOE implements version 1 of Internet Key Exchange (IKEv1), as defined in RFCs 2407, 2408, 2409, and 4109 and supports use of AES-CBC-128 and AES-CBC-256 to encrypt IKEv1 payloads. Note that the TOE supports both main and aggressive modes, though aggressive mode is disabled in CC/FIPS mode. Furthermore, “confidentiality only” ESP mode is disabled by default. HMAC SHA-1 (key size 160 bits) and HMAC SHA-256 (key size 256 bits) are used in support of the IPsec protocol ESP (FCS_IPSEC_EXT.1.4). IKE authentication keys are generated using the HMAC algorithms. The keys are used Security Target Version 2.0, 02/16/2015 36 for authenticating IKE negotiations and IPsec traffic authentications and subsequent traffic encryption. HMAC SHA for IPsec key authentication and encryption can be generated by using IKE commands. The TOE provides mechanisms to implement an IPsec Security Policy Database (SPD) and to process packets to satisfy the behavior of DISCARD, BYPASS and PROTECT packet processing as described in RFC 4301. This is achieved through the administrator configuring appropriately specified access control lists (ACLs). The administrator first establishes an IPsec Policy containing a Security ACL to match traffic to be encrypted (PROTECTed) and applies it to the outbound interface. The Security ACL contains one or more rules, which are ordered based on a numeric index from lowest to highest. The TOE compares packets in turn against each rule in the Security ACL to determine if the packet matches the rule. Packets can be matched based on protocol (e.g., TCP, UDP), source IP address and destination IP address. As soon as a match is found, the packet is handled based on the action specified in the rule—either permit, which equates to PROTECT, or deny, which equates to BYPASS. Traffic matching a deny rule or not matching any rule in the Security ACL is passed on to the next stage of processing. Note that multiple IPsec Policies can be assigned to an interface as a policy group. In this case, each policy in the group has its own priority number that is unique within the policy group. Each policy is considered in turn, starting at the lowest number policy (which has highest priority) and proceeding in turn with increasing policy numbers until a match is found or until all policies have been examined. To cater for packets that match a deny rule or do not match any of the IPsec Policies, the administrator needs to configure further ACLs and bind them to the outbound interface using the packet-filter command. These ACLs specify permit/deny rules to implement BYPASS/DISCARD behavior. As with the Security ACL, the TOE compares packets against rules in the Firewall ACL based on protocol, source IP address and destination IP address. The rules in the Firewall ACL can be ordered in the same fashion as in a Security ACL. In the Firewall ACL, a permit rule equates to BYPASS, and a deny rule equates to DISCARD. IKEv1 SA lifetime and volume limits can be configured by an authorized administrator and can be limited to 24 hours (actually any value between 60 and 604,800 seconds) for phase 1 and 8 hours (actually any value from 180 to 604,800 seconds) for phase 2 and also to as little as 2.5 MB (actually any value between 2,560 and 4,294,967,295 KB) of traffic for phase 2. The IKEv1 protocols implemented by the TOE include DH Groups 2 (1024-bit MODP), 5 (1536-bit MODP), and 14 (2048-bit MODP) and use RSA (aka rDSA) peer authentication. However, when the TOE is operating in FIPS mode, only DH Group 14 is supported. In the IKEv1 phase 1 and phase 2 exchanges, the TOE and peer will agree on the best DH group both can support. When the TOE initiates IKE negotiation, the DH group is sent in order according to the peer’s configuration. When the TOE receives an IKE proposal, it will select the first match and the negotiation will fail if there is no match. During IKEv1 phase 1 authentication is based on a verifiable signature as described in RFC2409.. The TOE can be configured to use pre-shared keys with a given peer. When a pre-shared key is configured, the IPsec tunnel will be established using the configured pre-shared key, provided that the peer also has the pre-shared key. Text-based pre-shared keys used for IPsec can be constructed of essentially any alphabetic character (upper and lower case), numerals, and special characters (e.g., “!”, “@”, “#”, “$”, “%”, “^”, “&”, “*”, “(“, and “)”) and can be anywhere from 15 to 128 characters in length (e.g., 22 characters). In this case, the TOE uses the bit representation of the underlying ASCII characters of the text-based pre-shared key as the key for IPsec peer authentication. The TOE can also accept bit-based pre-shared keys, which are entered as characters using hexadecimal notation—in this case, the TOE uses the bit value represented by the hexadecimal string, rather than the bit representation of the underlying ASCII characters, as the key for IPsec per authentication. The TOE requires suitable keys to be entered by an authorized administrator. The Cryptographic Support function is designed to satisfy the following security functional requirements:  FCS_CKM.1: See Table 65 above.  FCS_CKM_EXT.4: See Table 6 above.  FCS_COP.1(1): See Table 5 above.  FCS_COP.1(2): See Table 5 above.  FCS_COP.1(3): See Table 5 above.  FCS_COP.1(4): See Table 5 above.  FCS_IPSEC_EXT.1: The TOE supports IPsec cryptographic network communication protection. Security Target Version 2.0, 02/16/2015 37  FCS_RBG_EXT.1: See Table 5 above.  FCS_SSH_EXT.1: The TOE supports SSHv2 interactive command-line secure administrator sessions as indicated above.  FIA_PSK_EXT.1: The TOE supports pre-shared keys for IPsec peer authentication. 6.3 User Data Protection The TOE is designed to ensure its own internal integrity as well as to protect user data from potential, unintended reuse by clearing resources (e.g., memory) as they are allocated to create objects used in the implementation of the TOE operations. Note that volatile memory is the primary resource involved in normal TOE execution while its persistent storage is based on non-volatile flash memory. When a network packet is sent, the buffer used by the packet is recalled and managed by the buffer pool. After that, if a new packet acquires a buffer from the buffer pool, the new packet data will be used to overwrite any previous data in the buffer. If an allocated buffer exceeds the size of the packet, the additional space will be overwritten (padded) with zeroes. The User Data Protection function is designed to satisfy the following security functional requirements:  FDP_RIP.2: The TOE always overwrites resources when allocated for use in objects. 6.4 Identification and Authentication The TOE is designed to require users to be identified and authenticated before they can access any of the TOE functions. Note that the normal switching of network traffic is not considered accessing TOE functions in this regard. In the evaluated configuration, users can connect to the TOE CLI via a local console or remotely using SSHv2. For each session, the user is required to log in prior to successfully establishing a session through which TOE functions can be exercised. Note that the only capabilities allowed prior to users authenticating are the display of the warning banner before authentication, and network switching services. In order to log in, the user must provide an identity and also authentication data (e.g., password or RSA public key used in conjunction with an SSH session) that matches the provided identity. Users can be defined locally within the TOE with a user identity, password or public key authentication data, and user role. Alternatively, users can be defined within an external RADIUS or TACACS server configured to be used by the TOE, each of which also define the user’s role in the TOE. Note that only password-based authentication is supported for users defined in an external authentication server. Locally defined users are authenticated directly by the TOE, while remotely defined users are authenticated by the external server and the result is enforced by the TOE. In either case, any resulting session is dependent upon successful authentication and established sessions are associated with the privilege level/role (see Section 6.5) assigned to the user. When logging in the TOE will not echo passwords so that passwords are not inadvertently displayed to the user and any other users that might be able to view the login display. Note also that should a console user have their session terminated (e.g., due to inactivity), they are required to successfully authenticate, by reentering their identity and authentication data, in order to establish a new session. Passwords can be composed of upper and lower case letters, numbers and special characters, including blank space and ~`!@#$%^&*()_+-={}|[]\:”;’<>,./. Also, new passwords have to satisfy a configurable minimum password length. The administrator can specify a minimum password length of 15 to 32 characters. The Identification and Authentication function is designed to satisfy the following security functional requirements:  FIA_PMG_EXT.1: The TOE implements a set of password composition constraints as described above.  FIA_UAU.7: The TOE does not echo passwords as they are entered.  FIA_UAU_EXT.2: The TOE can be configured to use external RADIUS and TACACS authentication servers. Security Target Version 2.0, 02/16/2015 38  FIA_UIA_EXT.1: The TOE only displays the warning banner and allows for network switching services prior to a user being identified and authenticated. 6.5 Security Management The TOE controls user access to commands and resources based on user role. Users are given permission to access a set of commands and resources based on their user role. The TOE includes pre-defined user roles, of which only the user roles: network-admin and level-15, are considered instances of the ‘Security Administrator’ as defined in the NDPP. These Security Administrator roles are capable of managing the security functions of the TOE since they allow for security relevant configuration. These capabilities include changing the user permission settings including user-role, authentication-mode, protocol, and setting the authentication password in user interface view. The other roles represent logical subsets of those security management roles, but do not offer any security relevant configuration management capabilities. The other roles are limited to the ability to change a user’s own password, non-security relevant functions and review of information. For example, the roles: network-operator, level-1 and level-9 can display the configuration and status of the TOE. The local audit log can only be accessed by those with the network-admin, network-operator, or level-15 role. The TOE offers a CLI providing a range of security management functions for use by an authorized administrator. Among these functions are those necessary to manage all aspects of the cryptographic functions of the TOE, those necessary to enable or disable the network services offered by the TOE, and the functions necessary to review the TOE versions, update the TOE components, and also to verify the validity of those updates. The Security Management function is designed to satisfy the following security functional requirements:  FMT_MTD.1: The TOE restricts the access to manage TSF data that can affect the security functions of the TOE to Security Administrators.  FMT_SMF.1: The TOE includes the functions necessary to enable/disable available network services, to manage the cryptomodule and associated functions, and to manage and verify updates of the TOE software and firmware.  FMT_SMR.2: The TOE includes 19 predefined roles. As described above only the network-admin, and level-15 roles, that have been configured to access all security management functions of the TOE correspond to the required ‘Security Administrator’. 6.6 Protection of the TSF The TOE is an appliance and as such is designed to work independent of other components to a large extent. Secure communication with third-party peers is addressed in section 6.8. Secure communication among multiple instances of the TOE, which is considered communication among collocated components that logically form an instance of the TOE, is limited to a direct link between redundant switch appliances deployed in a high-availability configuration to physically protect the IRF communication channels as the TOE devices themselves. Normally redundant components are co-located and connected via a link that would not be exposed outside of the same physical environment. As such, no additional protection (e.g., encryption) should be necessary in most operational environments. Note that IRF groups are not considered peer switches in the IPsec (or VPN) sense. Rather IRF groups effectively form a logical instance of the TOE comprised of up to nine distinct devices. All those devices must be collocated and the IRF connections among them must be protected to the same degree as the devices themselves. While the administrative interface is function rich, the TOE is designed specifically to prevent access to locally- stored cryptographically protected passwords and also, while cryptographic keys can be entered, the TOE does not disclose any keys stored in the TOE. In the evaluated configuration (i.e., with FIPS mode enabled), the TOE protects user passwords either by saving a SHA-512 hash of the password (for user accounts password that existed before FIPS mode was enabled) or by encrypting the password using AES in CTR mode (for user accounts password entered after FIPS mode was enabled). See Table 6: Key/CSP Zeroization Summary for more information about stored keys and passwords; note that while some keys and passwords occur in plain text in RAM, that is only while they are in use and are not accessible by any user from RAM. Security Target Version 2.0, 02/16/2015 39 The TOE is a hardware appliance where all of the switch models except the 5900 include a hardware-based real- time clock (RTC). A RTC is a battery-powered clock that is included in a microchip in a computer motherboard. If a switch has a hardware RTC, when it startups, the device gets the time from the hardware RTC and synchronizes it to the CPU. When the device is powered off, the RTC still keeps track of the current time. Since the 5900 model does not have a hardware RTC, the time is maintained by adding up the CPU ticks to the default time of the system. The TOE’s embedded OS manages the time/clock and exposes administrator clock-related functions. The time/clock is used for audit record time stamps, measuring session activity for termination, and for cryptographic operations based on time/date. The TOE includes a number of built in diagnostic tests that are run during start-up to determine whether the TOE is operating properly. An administrator can configure the TOE to reboot or to stop, with errors displayed, when an error is encountered. The built-in self-tests include basic read-write memory (i.e., each memory location is written with a non-zero value and read to ensure it is stored as expected), flash read, software checksum tests, and device detection tests. When operating in CC/FIPS mode, the power-on self-tests comply with the FIPS 140-2 requirements for self-testing. The TOE is designed to support upgrades to the boot ROM program and system boot file as well as to support software hotfixes. The TOE provides interfaces so that an administrator can query the current boot ROM program or system boot file versions as well as to identify any installed patches. Both the boot ROM program and system boot file can be upgraded via the Boot ROM menu or the command line interface, but a reboot is required in each case. Hotfixes, which can affect only the system boot file, can be installed via the command line interface and do not require a reboot to become effective. The TOE includes a validity checking function that can be enabled when upgrading the boot ROM program, while system boot files and software patches are always validated prior to installation. In each case, the upgrade version will be checked to ensure it is appropriate and the upgrade file will be verified using an embedded (HP authorized) digital signature verified against a configured pair of hard-coded keys embedded in the TOE. If the version is incorrect or the signature cannot be verified, the upgrade will not proceed to protect the integrity of the TOE. More specifically, each update includes a header and data. The header includes a SHA-256 secure hash of the data that is signed (using rDSA/RSA 2048) by HP. In order to verify the data, the TOE generates its own SHA-256 secure hash of the update data, compares it with the signed hash in the update header to ensure they match, and verifies the hash signature using its configured public key. The Protection of the TSF function is designed to satisfy the following security functional requirements:  FPT_APW_EXT.1: The TOE does not offer any functions that will disclose to any user a plain text password. Note that passwords are stored in cryptographically protected form within the TOE FLASH.  FPT_SKP_EXT.1: The TOE does not offer any functions that will disclose to any users a stored cryptographic key.  FPT_STM.1: The 5920, 10500, and 12500 switches each have their own hardware RTC. The time on a 5900 switch is maintained by adding up the CPU ticks to the default time of the system.  FPT_TST_EXT.1: The TOE includes a number of power-on diagnostics that will serve to ensure the TOE is functioning properly. The tests include ensure memory and flash can be accessed as expected, to ensure that software checksums are correct, and also to test the presence and function of plugged devices.  FPT_TUD_EXT.1: The TOE provides functions to query and upgrade the versions of the boot ROM program and system boot file (including installing hotfixes). Digital signatures are used to ensure the integrity of each upgrade prior to performing the upgrade; this checking is optional for the boot ROM program since special circumstances might require those checks to be disabled. 6.7 TOE Access The TOE can be configured to display administrator-configured advisory banners. A login banner can be configured to display warning information along with login prompts. The banner will be displayed when accessing the TOE via the console or SSH interfaces. Security Target Version 2.0, 02/16/2015 40 The TOE can be configured by an administrator to set an interactive session timeout value (any integer value in minutes and also optionally in seconds, with 0 disabling the timeout) – the default timeout is 10 minutes. A remote session that is inactive (i.e., no commands issuing from the remote client) for the defined timeout value will be terminated. A local session that is similarly inactive for the defined timeout period will be terminated. The user will be required to re-enter their user id and their password so they can establish a new session once a session is terminated. If the user id and password match those of the user that was locked, the session is reconnected with the console and normal input/output can again occur for that user. The TOE Access function is designed to satisfy the following security functional requirements:  FTA_SSL.3: The TOE terminates remote sessions that have been inactive for an administrator-configured period of time.  FTA_SSL.4: The TOE provides the function to logout (or terminate) both local and remote user sessions as directed by the user.  FTA_SSL_EXT.1: The TOE terminates local sessions that have been inactive for an administrator- configured period of time.  FTA_TAB.1: The TOE can be configured to display administrator-defined advisory banners before establishing an administrative user session. 6.8 Trusted Path/Channels The TOE can be configured to export audit records to an external Syslog server. The TOE uses IPsec to protect communications between itself and components in the operational environment including Syslog and authentication servers (RADIUS and TACACS). To support secure remote administration, the TOE includes an implementation of SSHv2. An administrator with an appropriate SSHv2-capable client can establish secure remote connections with the TOE. The TOE supports both public key-based and password-based client authentication for the SSH trusted path. To successfully establish an interactive administrative session, the administrator must be able to provide acceptable user credentials (e.g., user id and password), after which they will be able to issue commands within their assigned authorizations. All of the secure protocols are supported by NIST-validated cryptographic mechanisms included in the TOE implementation. The Trusted Path/Channels function is designed to satisfy the following security functional requirements:  FTP_ITC.1: The TOE can be configured to use IPsec to protect authentication operations, exported audit records, and time information transmitted between the TOE and external servers from inappropriate disclosure or modification.  FTP_TRP.1: The TOE provides SSH to support secure remote administration. Administrators can initiate a remote session that is secured from disclosure and modification using NIST-validated cryptographic operations, and all remote security management functions require the use of this secure channel. Security Target Version 2.0, 02/16/2015 41 7. Protection Profile Claims This ST is conformant to the Protection Profile for Network Devices, Version 1.1, 8 June 2012 (NDPP), as amended by Errata #2 – with the optional SSH, IPsec and pre-shared key requirements. The TOE includes Ethernet switch devices. As such, the TOE is a network device making the NDPP claim valid and applicable. As explained in section 3, Security Problem Definition, the Security Problem Definition of the NDPP has been included by reference into this ST. As explained in section 4, Security Objectives, the Security Objectives of the NDPP have been included by reference into this ST. The following table identifies all the Security Functional Requirements (SFRs) in this ST. Each SFR is reproduced from the NDPP and operations completed as appropriate. Requirement Class Requirement Component Source FAU: Security audit FAU_GEN.1: Audit Data Generation NDPP FAU_GEN.2: User identity association NDPP FAU_STG_EXT.1: External Audit Trail Storage NDPP FCS: Cryptographic FCS_CKM.1: Cryptographic Key Generation (for asymmetric keys) NDPP support FCS_CKM_EXT.4: Cryptographic Key Zeroization NDPP FCS_COP.1(1): Cryptographic Operation (for data encryption/decryption) NDPP FCS_COP.1(2): Cryptographic Operation (for cryptographic signature) NDPP FCS_COP.1(3): Cryptographic Operation (for cryptographic hashing) NDPP FCS_COP.1(4): Cryptographic Operation (for keyed-hash message authentication) NDPP FCS_IPSEC_EXT.1: Explicit: IPSEC NDPP FCS_RBG_EXT.1: Extended: Cryptographic Operation (Random Bit Generation) NDPP FCS_SSH_EXT.1: Explicit: SSH NDPP FDP: User data protection FDP_RIP.2: Full Residual Information Protection NDPP FIA: Identification FIA_PMG_EXT.1: Password Management NDPP and authentication FIA_PSK_EXT.1: Extended: Pre-Shared Key Composition NDPP FIA_UAU.7: Protected Authentication Feedback NDPP FIA_UAU_EXT.2: Extended: Password-based Authentication Mechanism NDPP FIA_UIA_EXT.1: User Identification and Authentication NDPP FMT: Security FMT_MTD.1: Management of TSF Data (for general TSF data) NDPP management FMT_SMF.1: Specification of Management Functions NDPP FMT_SMR.2: Restrictions on Security Roles NDPP FPT: Protection of the TSF FPT_SKP_EXT.1: Extended: Protection of TSF Data (for reading of all symmetric keys) NDPP FPT_APW_EXT.1: Extended: Protection of Administrator Passwords NDPP FPT_STM.1: Reliable Time Stamps NDPP FPT_TST_EXT.1: TSF Testing NDPP FPT_TUD_EXT.1: Extended: Trusted Update NDPP FTA: TOE access FTA_SSL.3: TSF-initiated Termination NDPP FTA_SSL.4: User-initiated Termination NDPP FTA_SSL_EXT.1: TSF-initiated Session Locking NDPP FTA_TAB.1: Default TOE Access Banners NDPP FTP: Trusted path/channels FTP_ITC.1: Trusted Channel NDPP FTP_TRP.1: Trusted Path NDPP Table 7 SFR Protection Profile Sources Security Target Version 2.0, 02/16/2015 42 8. Rationale This security target includes by reference the NDPP Security Problem Definition, Security Objectives, and Security Assurance Requirements. The security target makes no additions to the NDPP assumptions. NDPP security functional requirements have been reproduced with the protection profile operations completed. Operations on the security requirements follow NDPP application notes and assurance activities. Consequently, NDPP rationale applies but is incomplete. The TOE Summary Specification rationale below serves to complete the rationale required for the security target. 8.1 TOE Summary Specification Rationale Each subsection in Section 6, the TOE Summary Specification, describes a security function of the TOE. Each description is followed with rationale that indicates which requirements are satisfied by aspects of the corresponding security function. The set of security functions work together to satisfy all of the security functions and assurance requirements. Furthermore, all of the security functions are necessary in order for the TSF to provide the required security functionality. This Section in conjunction with Section 6, the TOE Summary Specification, provides evidence that the security functions are suitable to meet the TOE security requirements. The collection of security functions work together to provide all of the security requirements. The security functions described in the TOE summary specification are all necessary for the required security functionality in the TSF. Table 8 Security Functions vs. Requirements Mapping demonstrates the relationship between security requirements and security functions. Security audit Cryptographic support User data protection Identification and authentication Security management Protection of the TSF TOE access Trusted path/channels FAU_GEN.1 X FAU_GEN.2 X FAU_STG_EXT.1 X FCS_CKM.1 X FCS_CKM_EXT.4 X FCS_COP.1(1) X FCS_COP.1(2) X FCS_COP.1(3) X FCS_COP.1(4) X FCS_IPSEC_EXT.1 X FCS_RBG_EXT.1 X FCS_SSH_EXT.1 X FDP_RIP.2 X FIA_PMG_EXT.1 X FIA_UAU.7 X FIA_UAU_EXT.2 X FIA_UIA_EXT.1 X FMT_MTD.1 X FMT_SMF.1 X FMT_SMR.2 X FPT_APW_EXT.1 X Security Target Version 2.0, 02/16/2015 43 Security audit Cryptographic support User data protection Identification and authentication Security management Protection of the TSF TOE access Trusted path/channels FPT_SKP_EXT.1 X FPT_STM.1 X FPT_TST_EXT.1 X FPT_TUD_EXT.1 X FTA_SSL.3 X FTA_SSL.4 X FTA_SSL_EXT.1 X FTA_TAB.1 X FTP_ITC.1 X FTP_TRP.1 X Table 8 Security Functions vs. Requirements Mapping Security Target Version 2.0, 02/16/2015 44 Appendix A: Documentation for HP 5900, 5900CP, 5920, 5930 10500, 12500 and 12900 Switches This Appendix provides a list of the product documentation used during the evaluation of each HP 5900/5920/10500/12500 Series switch product family. 5900/5900CP/5920 Switch Series The following documents for the 5900/5920 Switch series can be found under the General Reference section of the 5900 Switch Series documentation page on the HP Web site. The link is provided below.  R2307-HP 5900 Security Command Reference, 17 Jan 2014  R2307-HP 5900 Fundamentals Command Reference 17 Jan 2014  R2307-HP 5900 ACL and QoS Command Reference, 17 Jan 2014  R2307-HP 5900 Layer-3 IP Services Command Reference, 17 Jan 2014 The following documents for the 5900/5920 Switch series can be found under the Setup and Install section of the 5900 Switch Series documentation page on the HP Web site. The link is provided below.  R2307-HP 5900 Security Configuration Guide, 17 Jan 2014  R2307-HP 5900 Fundamentals Configuration Guide, 17 Jan 2014  R2307-HP 5900 Network Management and Monitoring Configuration Guide, 17 Jan 2014  HP 5900/5920 Switch Series Installation Guide, 12 Feb 2014 http://h20566.www2.hp.com/portal/site/hpsc/public/psi/home/?sp4ts.oid=5221896#manuals 5930 Switch Series The following documents for the 5930 Switch series can be found under the General Reference section of the 5930 Switch Series documentation page on the HP Web site. The link is provided below.  R240x-HP FlexFabric 5930 Security Command Reference, April 14, 2014  R240x HP FlexFabric 5930 Fundamentals Command Reference, April 14, 2014  R240x - HP FlexFabric 5930 ACL and QoS Command Reference, April 14, 2014  R240x - HP FlexFabric 5930 Layer-3 IP Services Command Reference, April 14, 2014 The following documents for the 5930 Switch series can be found under the Setup and Install section of the 5930 Switch Series documentation page on the HP Web site. The link is provided below.  R240x - HP FlexFabric 5930 Security Configuration Guide, April 15, 2014  R240x - HP FlexFabric 5930 Fundamentals Configuration Guide, April 14, 2014  R240x - HP FlexFabric 5930 Network Management and Monitoring Configuration Guide, April 14, 2014  HP FlexFabric 5930 Switch Series Installation Guide, Nov 28, 2013 http://h20565.www2.hp.com/portal/site/hpsc/public/psi/home/?sp4ts.oid=6604154&ac.admitted=1424159492693.87 6444892.492883150#manuals 10500 Switch Series The following documents for the 10500 Switch series can be found under the General Reference section of the 10500 Switch Series documentation page on the HP Web site. The link is provided below.  R211x-HP 10500 Switch Series Security Command Reference, 17 Aug 2014  R211x-HP 10500 Switch Series Fundamentals Command Reference, 17 Aug 2014  R211x-HP 10500 Switch Series ACL and QoS Command Reference, 17 Aug 2014  R211x-HP 10500 Switch Series Layer-3 IP Services Command Reference, 17 Aug 2014 Security Target Version 2.0, 02/16/2015 45 The following documents for the 10500 Switch series can be found under the Setup and Install section of the 10500 Switch Series documentation page on the HP Web site. The link is provided below.  R211x-HP 10500 Switch Series Security Configuration Guide, 18 Aug 2014  R211x-HP 10500 Switch Series Fundamentals Configuration Guide, 18 Aug 2014  R211x-HP 10500 Switch Series Network Management and Monitoring Configuration Guide, 18 Aug 2014  HP 10500 Switch Series Installation Guide, 20 Aug 2014 http://h20566.www2.hp.com/portal/site/hpsc/public/psi/home/?sp4ts.oid=5117468#manuals 12500 Switch Series The following documents for the 12500 Switch series can be found under the General Reference section of the 12500 Switch Series documentation page on the HP Web site. The link is provided below.  R1825P01-HP 12500 Switch Series Security Command Reference, 2 Apr 2013  R1825P01-HP 12500 Switch Series Fundamentals Command Reference 2 Apr 2013  R1825P01-HP 12500 Switch Series ACL and QoS Command Reference, 2 Apr 2013  R1825P01-HP 12500 Switch Series Layer-3 IP Services Command Reference, 2 Apr 2013 The following documents for the 12500 Switch series can be found under the Setup and Install section of the 12500 Switch Series documentation page on the HP Web site. The link is provided below.  R1825P01-HP 12500 Switch Series Security Configuration Guide, 2 Apr 2013  R1825P01-HP 12500 Switch Series Fundamentals Configuration Guide, 2 Apr 2013  R7128-HP 12500 Switch Series Network Management and Monitoring Configuration Guide, 30 Nov 2012  HP FlexFabric 12500E Switch Series Installation Guide, 25 Sep 2014 http://h20566.www2.hp.com/portal/site/hpsc/public/psi/manualsResults/?sp4ts.oid=4177453&ac.admitted=1413205 932488.876444892.199480143 12900 Switch Series The following documents for the 12900 Switch series can be found under the General Reference section of the 12900 Switch Series documentation page on the HP Web site. The link is provided below.  R1109-HP FlexFabric 12900 Security Command Reference, 15 Oct 2014  R1109-HP FlexFabric 12900 Fundamentals Command Reference 14 Oct 2014  R110x-HP FlexFabric 12900 ACL and QoS Command Reference, 14 Oct 2014  R1109-HP FlexFabric 12900 Layer-3 IP Services Command Reference, 15 Oct 2014 The following documents for the 12900 Switch series can be found under the Setup and Install section of the 12900 Switch Series documentation page on the HP Web site. The link is provided below.  R110x-HP FlexFabric 12900 Security Configuration Guide, 11 Jun 2014  R1109-HP FlexFabric 12900 Fundamentals Configuration Guide, 14 Oct 2014  R1109-HP FlexFabric 12900 Network Management and Monitoring Configuration Guide, 14 Oct 2014  HP FlexFabric 12900 Switch Installation Guide, 16 Oct 2014 http://h20565.www2.hp.com/portal/site/hpsc/public/psi/home/?sp4ts.oid=5443167&ac.admitted=1424158750730.87 6444892.492883150#manuals