Hewlett Packard Enterprise
MSR1000 Series, MSR2000 Series, MSR3000
Series and MSR4000 Series Routers
Security Target
Version 1.0
March 4, 2016
Prepared for:
Hewlett Packard Enterprise
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 1.0, 2/16/2016
2
1. SECURITY TARGET INTRODUCTION...........................................................................................................4
1.1 SECURITY TARGET, TOE AND CC IDENTIFICATION........................................................................................4
1.2 CONFORMANCE CLAIMS.................................................................................................................................5
1.3 CONVENTIONS ................................................................................................................................................6
1.3.1 Terminology ..........................................................................................................................................7
1.3.2 Acronyms...............................................................................................................................................7
2. TOE DESCRIPTION ..........................................................................................................................................8
2.1 TOE OVERVIEW .............................................................................................................................................9
2.1.1 MSR1000 Series Routers.......................................................................................................................9
2.1.2 MSR2000 Series Routers.....................................................................................................................10
2.1.3 MSR3000 Series Routers.....................................................................................................................11
2.1.4 MSR4000 Series Routers.....................................................................................................................12
2.2 TOE ARCHITECTURE....................................................................................................................................14
2.2.1 Multitenant device context...................................................................................................................15
2.2.2 Physical Boundaries.............................................................................................................................15
2.2.3 Logical Boundaries..............................................................................................................................16
2.3 TOE DOCUMENTATION ................................................................................................................................17
3. SECURITY PROBLEM DEFINITION ..........................................................................................................18
4. SECURITY OBJECTIVES ..............................................................................................................................19
4.1 SECURITY OBJECTIVES FOR THE OPERATIONAL ENVIRONMENT ...................................................................19
5. IT SECURITY REQUIREMENTS..................................................................................................................20
5.1 EXTENDED REQUIREMENTS..........................................................................................................................20
5.2 TOE SECURITY FUNCTIONAL REQUIREMENTS .............................................................................................21
5.2.1 Security audit (FAU) ...........................................................................................................................21
5.2.2 Cryptographic support (FCS)...............................................................................................................23
5.2.3 User data protection (FDP)..................................................................................................................25
5.2.4 Identification and authentication (FIA)................................................................................................26
5.2.5 Security management (FMT)...............................................................................................................26
5.2.6 Protection of the TSF (FPT) ................................................................................................................27
5.2.7 TOE access (FTA) ...............................................................................................................................27
5.2.8 Trusted path/channels (FTP)................................................................................................................28
5.3 TOE SECURITY ASSURANCE REQUIREMENTS...............................................................................................29
6. TOE SUMMARY SPECIFICATION..............................................................................................................29
6.1 SECURITY AUDIT ..........................................................................................................................................29
6.2 CRYPTOGRAPHIC SUPPORT ...........................................................................................................................30
6.3 USER DATA PROTECTION ..............................................................................................................................38
6.4 IDENTIFICATION AND AUTHENTICATION.......................................................................................................39
6.5 SECURITY MANAGEMENT .............................................................................................................................39
6.6 PROTECTION OF THE TSF .............................................................................................................................40
6.7 TOE ACCESS.................................................................................................................................................41
6.8 TRUSTED PATH/CHANNELS ...........................................................................................................................42
7. PROTECTION PROFILE CLAIMS...............................................................................................................43
8. RATIONALE.....................................................................................................................................................44
Security Target Version 1.0, 2/16/2016
3
8.1 TOE SUMMARY SPECIFICATION RATIONALE................................................................................................44
APPENDIX A: DOCUMENTATION FOR HEWLETT PACKARD ENTERPRISE MSR1000, MSR2000,
MSR3000, AND MSR4000 ROUTERS....................................................................................................................45
LIST OF TABLES
Table 1 TOE Series and Devices.................................................................................................................................5
Table 2 CPU’s and Number of Fixed Ports by Device............................................................................................16
Table 3 TOE Security Functional Components ......................................................................................................21
Table 4 Auditable Events..........................................................................................................................................23
Table 5 Assurance Components ...............................................................................................................................29
Table 6 Cryptographic Functions ............................................................................................................................30
Table 7 NIST SP800-56B Conformance ..................................................................................................................32
Table 8 Key/CSP Zeroization Summary .................................................................................................................36
Table 9 SFR Protection Profile Sources ..................................................................................................................43
Table 10 Security Functions vs. Requirements Mapping.......................................................................................45
Security Target Version 1.0, 2/16/2016
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 Enterprise MSR 1000, 2000, 3000, and
4000 Series Routers with Comware V7.1.059, Release 0305 provided by Hewlett Packard Enterprise. Each of the
Series Router products is a stand-alone Gigabit Ethernet router appliance designed to implement a wide range of
network layers 2 and 3 switching, service and routing operations.
The focus of the evaluation is on the TOE functionality supporting the claims in the Protection Profile for Network
Devices (NDPP). The only capabilities covered by the evaluation are those specified in the aforementioned
Protection Profile, all other capabilities are not covered in the evaluation. The security functionality specified in
[NDPP], includes protection of communications with remote administrators and trusted IT entities, identification
and authentication of administrators, auditing of security-relevant events, ability to verify the source and integrity of
updates to the TOE, and specifies NIST-validated cryptographic mechanisms.
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 Enterprise MSR Routers 1k-4k Security Target
ST Version – Version 1.0
ST Date –February 16, 2016
TOE Identification – Hewlett Packard Enterprise MSR 1000, 2000, 3000, and 4000 Series Routers with Comware
V7.1.059, Release 0305 with a High Encryption License1
.
On November 1, 2015, Hewlett-Packard became two separate companies: Hewlett Packard Enterprise and HP Inc.
The network products are part of the new Hewlett Packard Enterprise. The former HP network switches and routers
are undergoing product rebranding. The rebranding is not complete in the documentation and on the websites. The
TOE maybe referred to with the suffix “HP”, “HP FlexFabric”, “HPE” or “HPE FlexFabric”. For the purpose of this
evaluation, these name variations are used interchangeably and refer to the same product.
Product Series Specific Devices
HP MSR1000 HP MSR1002-4 AC Router ((JG875A)
HP MSR1003-8S AC Router (JH060A)
HP MSR2000 HP MSR2003 AC Router (JG411A)
HP MSR2004-24 AC Router (JG734A)
HP MSR2004-48 Router (JG735A)
1
HPE ships the MSR router series with a High Encryption License. The FIPS mode cannot be enabled if a High
Encryption license has not been installed.
Security Target Version 1.0, 2/16/2016
5
Product Series Specific Devices
HP MSR3000 HP MSR3012 AC Router (JG409A)
HP MSR3012 DC Router (JG410A)
HP MSR3024 AC Router ((JG406A)
HP MSR3024 DC Router (JG407A)
HP MSR3024 PoE Router (JG408A)
HP MSR3044 Router (JG405A)
HP MSR3064 Router (JG404A)
HP MSR4000 HP MSR 4060 Router Chassis with HP
MSR4000 MPU-100 Main Processing Unit
(JG403A)
HP MSR 4080 Router Chassis with HP
MSR4000 MPU-100 Main Processing Unit
(JG402A)
Note: Each MSR4000 product series must
also have one of the following Service
Processing Units2
:
 HP MSR4000 SPU-100 Service
Processing Unit (JG413A);
 HP MSR4000 SPU-200 Service
Processing Unit (JG414A); or
 HP MSR4000 SPU-300 Service
Processing Unit (JG670A).
Table 1 TOE Series and Devices
TOE Developer – Hewlett Packard Enterprise
Evaluation Sponsor – Hewlett Packard Enterprise
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:
 Protection Profile for Network Devices, Version 1.1, 8 June 2012 (NDPP) as amended by Errata
#3 dated 3 November 2013, and including the following optional SFRs: FCS_IPSEC_EXT.1;
FCS_SSH_EXT.1; and FIA_PSK_EXT.1. The following NIAP Technical Decisions apply to this
PP and have been accounted for in the ST development and the conduct of the evaluation:
 TD0004: FCS_TLS_EXT Man-in-the-Middle Test - This Technical Decision removes
the FCS_TLS_EXT man-in-the-middle tests for the NDPP (FCS_TLS_EXT.1.1, Test 2),
pending development of new TLS requirements and assurance activities and
identification of suitable test tools.
 TD0005: FPT_ITT Test 3 Resolution - This Technical Decision removes the need to
perform Test 3 associated with FPT_ITT.1 in NDPP, consistent with the test
requirements for FTP_ITC.1 and FTP_TRP.1.
2
See MSR4000 Series Routers in section 2.1.4 for a description of the Service Processing Units.
Security Target Version 1.0, 2/16/2016
6
 TD0011: FCS_SSH_EXT.1.4 Clarification - The SFR requires that the SSH transport
implementation use specific encryption algorithms. The TD clarifies that the
restrictions must be implemented by the TOE and cannot be reliant upon configuration
of the SSH client.
 TD0012: FCS_SSH_EXT.1.4 - Algorithms not identified in FCS_SSH_EXT.1.4 must
not be allowed; other cipher suites (such as 3DES-CBC) must be disabled in evaluated
configurations. The Assurance Activities associated with this requirement must verify
that connection attempts with algorithms not listed in FCS_SSH_EXT.1.4 are denied.
The NDPP was updated via errata to reflect this decision.
 TD0017: NDPP Audit Shutdown - This Technical Decision allows for the use of a
startup audit record to indicate audit shutdown in the event of an uncontrolled shutdown.
 TD0026: FPT_TUD_EXT.1 - This Technical Decision allows for the administrator
following TOE guidance to reject an illegitimate update detected by the TOE, in addition
to the TOE rejecting the update automatically (during testing).
 TD0032: FCS_SSH_EXT.1.2 – The SFR was rewritten to conditionally require
password-based authentication.
 Common Criteria for Information Technology Security Evaluation Part 2: Security functional components,
Version 3.1, Revision 33
, July 2009.
 Part 2 Extended
 Common Criteria for Information Technology Security Evaluation Part 3: Security assurance components,
Version 3.1 Revision 34
, 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 (for example, [assignment]). Note that an assignment within
a selection would be identified in italics and with embedded bold brackets (for example,
[[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 (for example, [selection]).
o Refinement: allows the addition of details. Refinements are indicated using bold, for additions,
and strike-through, for deletions (for example, “… 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.
3
NDPP claims conformance to CC Part 2 Revision 3. CC Part 2 Revision 3 and Revision 4 are the same for the
requirements included in this ST,
4
NDPP claims conformance to CC Part 3 Revision 3. CC Part 3 Revision 3 and Revision 4 are the same for the
requirements included in this ST,
Security Target Version 1.0, 2/16/2016
7
 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 Terminology
FlexBranch A solution provided by HP that integrates network connectivity and
applications.
FlexNetwork A network architecture developed by Hewlett-Packard to provide
networking services and a consistent network architecture for the data
center, campus and branch offices. It was developed to support
technologies such as virtualization and cloud computing.
1.3.2 Acronyms
AAA Authentication, Authorization and Accounting
ACL Access Control List
AES Advanced Encryption Standard
AUT Authentication
CBC Cipher-Block Chaining
CC Common Criteria for Information Technology Security Evaluation
CEM Common Evaluation Methodology for Information Technology Security
CM Configuration Management
CLI Command Line Interface
CPU Central Processing Unit
DH Diffie-Hellman
EVI Ethernet Virtualization Interconnection
FDP User Data Protection CC Class
FIA Identification and Authentication CC Class
FIPS Federal Information Processing Standard
FMT Security Management CC Class
FSP Functional Specification
GR Graceful Restart
HMAC Hashed Message Authentication Code
IP Internet Protocol
IPC Inter-process communication
IPv4 Internet Protocol version 4
IPv6 Internet Protocol version 6
IPsec Internet Protocol Security
ISSU
IT
In Service Software Upgrades
Information Technology
LACP Link Aggregation Control Protocol
LAN Local Area Network
MDC Multitenant device context
MOF
MPLS
MTD
Management of Functions
Multiprotocol Label Switching
Management of TSF Data
Mpps Millions of packets per second
NDPP Protection Profile for Network Devices
OAA
OSP
Open Application Architecture
Organization Security Policy
OSPF Open Shortest Path First
POS Prime order subgroup
Security Target Version 1.0, 2/16/2016
8
PP Protection Profile
PCI Peripheral Component Interconnect (personal computer bus)
QoS Quality of Service
RADIUS Remote Authentication Dial In User Service
RPC Remote procedure call
RSA Rivest, Shamir and Adleman (algorithm for public-key cryptography)
SA Security Association
SAR Security Assurance Requirement
SFP Security Function Policy
SFR Security Functional Requirement
SHA Secure Hash Algorithm
SIC Smart Interface Card
SM Security Management
SMR Security Management Roles
SOF Strength of Function
SSH Secure Shell
ST Security Target
TACACS+ Terminal Access Controller Access Control System Plus
TCP Transmission Control Protocol
TOE Target of Evaluation
TRILL Transparent Interconnection of Lots of Links
TSC TSF Scope of Control
TSF TOE Security Functions
TSP TOE Security Policy
UAU User Authentication
UDP User Data Protection
USB Universal Serial Bus
VLAN Virtual Local Area Network
VPN Virtual Private Network
WAN Wide Area Network
2. TOE Description
The Target of Evaluation (TOE) is the Hewlett Packard Enterprise MSR 1000, 2000, 3000, and 4000 Series Routers
with Comware V7.1.059, Release 0305. The MSR 1000 Series router in the evaluated configuration comprises the
following specific devices:
 HP MSR1002-4 AC router ((JG875A),
 HP MSR1003-8S AC Router (JH060A).
The MSR 2000 Series router in the evaluated configuration comprises the following specific devices:
 HP MSR 2003 AC Router (JG411A),
 HP MSR 2004-24 AC Router (JG734A),
 HP MSR 2004-48 Router (JG735A).
The MSR 3000 Series in the evaluated configuration comprises the following specific devices:
 HP MSR3012 AC Router (JG409A),
 HP MSR3012 DC Router (JG410A),
 HP MSR3024 AC Router ((JG406A),
 HP MSR3024 DC Router (JG407A),
Security Target Version 1.0, 2/16/2016
9
 HP MSR3024 PoE Router (JG408A),
 HP MSR3044 Router (JG405A), and
 HP MSR3064 Router (JG404A).
The MSR 4000 Series in the evaluated configuration comprises the following specific devices:
 HP MSR 4060 Router Chassis with HP MSR4000 MPU-100 Main Processing Unit (JG403A); and the
 HP MSR 4080 Router Chassis with HP MSR4000 MPU-100 Main Processing Unit (JG402A).
Note: Each MSR4000 product series must also have one of the following Service Processing Units: HP MSR4000
SPU-100 Service Processing Unit (JG413A); HP MSR4000 SPU-200 Service Processing Unit (JG414A); or HP
MSR4000 SPU-300 Service Processing Unit (JG670A).
Each series of routers comprising the TOE consists of a set of distinct devices (as identified in Section 1.1), which
vary primarily according to power delivery, performance, and port density.
The MSR 1000, 2000, 3000, and 4000 routers have a fixed number of ports and each support plug-in modules,
which provide additional functionality (for example, various numbers and types of network connection ports). All of
the available plug-in modules are included and can optionally be used in the evaluated configuration (see below) as
they do not affect any of the claimed security functionality.
2.1 TOE Overview
The various routers comprising the TOE are all Gigabit Ethernet router appliances that consist of hardware and
software components. While the physical form factor of each of the four series of MSR routers is substantially
different, the underlying hardware shares a similar architecture. The software uses a common code base of a
modular nature with only the modules applicable for the specific hardware installed.
The following product descriptions identify the evaluated hardware and software included in the TOE. The scope of
the evaluation is the security functions specified in the NDPP. The additional product features that have been
described are not within the scope of evaluation but are provided to identify the product type and intended use.
Please see the details in the text below.
2.1.1 MSR1000 Series Routers
The Hewlett Packard Enterprise MSR1000 series routers are a multiservice routers designed for small sized branch
offices or departmental end points. HP MSR1000 series routers feature interface and module options for Local Area
Network (LAN) and Wide Area Network (WAN) communications, along with security and convergence capabilities
through embedded and integrated encryption and voice processing. The evaluation covered Internet Protocol
Security (IPsec) capabilities specified in the NDPP.
The HP MSR1002-4 AC router provides three Smart Interface Card (SIC) interface module slots and up to eight
Gigabit Ethernet LAN ports which can be re-configured as WAN Routing ports. The router provides High-density
Ethernet access with WAN Fast Ethernet/Gigabit Ethernet, LAN 4- and 9-port Fast Ethernet; and mobility access
with 2 SIC (or 1 DSCI slot) module slots. The router also provides 1 RJ-45 autosensing 10/100/1000 WAN port, 1
SFP fixed Gigabit Ethernet SFP port, 4 RJ-45 autosensing 10/100/1000 LAN ports, and 1 Serial port.
The MSR1003-8S AC router provides 3 SIC or 1 SIC and 1 DSIC module slots, 2 RJ-45 autosensing 10/100/1000
WAN ports, and 8 RJ-45 autosensing 10/100/1000 LAN ports, supporting up to 500Kpps forwarding and 170Mbps
of IPsec encryption throughput.
The routers support IPv6 with full Layer 2 and Layer 3 features. The router uses USB memory disk to download
and upload configuration and operating system image files; and supports an external USB 3G/4G modem for a
3G/4G WAN uplink. The models included in the TOE are the HP MSR1002-4 AC router (JG875A); and the HP
MSR1003-8S AC Router (JH060A).
The following module(s) are supported by this series and can optionally be used since they do not affect any of the
claimed security functions but rather serve to extend available network connectivity:
 HP A-MSR 4-port 10/100Base-T Switch SIC Module JD573B
Security Target Version 1.0, 2/16/2016
10
 HP A-MSR 9-port 10/100Base-T Switch DSIC Module JD574B
 HP A-MSR 1-port 10/100Base-T SIC Module JD545B
 HP A-MSR 1-port 100Base-X SIC Module JF280A
 HP A-MSR 2-port FXO SIC Module JD558A
 HP A-MSR 1-port FXO SIC Module JD559A
 HP A-MSR 2-port FXS SIC Module JD560A
 HP A-MSR 1-port FXS SIC Module JD561A
 HP A-MSR 4-port FXS/1-port FXO DSIC Mod JD189A
 HP A-MSR 2-port ISDN-S/T Voice SIC Module JF821A
 HP A-MSR 2-port FXS/1-port FXO SIC Module JD632A
 HP A-MSR 1-port E1/Fractional E1 (75ohm) SIC Module JD634B
 HP A-MSR 1-port T1/Fractional T1 SIC Module JD538A
 HP A-MSR 2-port E1/Fractional E1 (75ohm) SIC Module JF842A
 HP A-MSR 1-port Enhanced Sync/Async Serial SIC Module JD557A
 HP A-MSR 1-port ISDN-S/T SIC Module JD571A
 HP A-MSR 8-port Async Serial SIC Module JF281A
 HP 802.11b/g/n Wireless AP SIC Module JF819A
 HP MSR 802.11b/g/n Wless AP SIC Mod (NA) JG211A
 HP A-MSR 16-port Async Serial SIC Module JG186A
 HP A-MSR HSPA/WCDMA SIC Module JG187A
 HP A-MSR 1-port ADSL over POTS SIC Mod JD537A
 HP MSR 1-p ADSL over ISDN BRI U SIC Mod JG056B
 HP A-MSR 1-p 8-wire G.SHDSL DSIC Module JG191A
 HP MSR 1p E1/CE1/PRI SIC Mod JG604
 HP MSR 4G LTE SIC Mod for Verizon JG742A
 HP MSR 4G LTE SIC Mod for ATT JG743A
 HP MSR 4G LTE SIC Mod for Global JG744A
 HP A-MSR 4-port 10/100Base-T PoE Switch SIC Module JD620A
 HP A-MSR 9-port 10/100Base-T PoE Switch DSIC Module JD621A
 HP MSR 2p Enh Sync/Async Srl SIC Mod JG736A
 HP MSR 4p Enh Sync/Async Srl SIC Mod JG737A
 HP MSR 1p GbE Combo SIC Mod JG738A
 HP MSR 4p Gig-T Switch SIC Mod JG739A
 HP MSR 4p Gig-T PoE Switch SIC Mod JG740A
2.1.2 MSR2000 Series Routers
The HP MSR2000 series router is a component of the Hewlett Packard Enterprise FlexBranch solution, which is a
part of the comprehensive Hewlett Packard Enterprise FlexNetwork architecture. These router appliances feature a
modular design that delivers application services for small- to medium-sized branch offices. This provides the
benefit of reduced complexity, and simplified configuration, deployment, and management. HP MSR2000 series
routers feature an interface and module options for reliable, scalable LAN and WAN communications, along with
security and convergence capabilities through embedded and integrated encryption and voice processing. The
evaluation covered IPsec capabilities specified in the NDPP. The HP MSR2000 supports up to 400 Mb/s of IPsec
VPN encrypted throughput.
The routers provides 3-4 interface module slots and 15 high-density Fast Ethernet ports, WAN Gigabit Ethernet and
LAN 4-port and 9-port Fast Ethernet; and mobility access with 3G SIC module and 3G/4G USB modems; as well
as provides IPv6 support with full Layer 2 and Layer 3 features. The routers use USB memory disk to download
and upload configuration and operating system image files; and supports an external USB 3G/4G modem for a
3G/4G WAN uplink. The series includes:
 HP MSR2003 AC Router JG411A
 HP MSR2004-24 AC Router JG734A
 HP MSR2004-48 Router JG735A
Security Target Version 1.0, 2/16/2016
11
The following modules, extending the physically available ports, are supported by this series and can optionally be
used since they do not affect any of the claimed security functions but rather serve to extend available network
connectivity:
 HP A-MSR 4-port 10/100Base-T Switch SIC Module JD573B
 HP A-MSR 9-port 10/100Base-T Switch DSIC Module JD574B
 HP A-MSR 1-port 10/100Base-T SIC Module JD545B
 HP A-MSR 1-port 100Base-X SIC Module JF280A
 HP A-MSR 2-port FXO SIC Module JD558A
 HP A-MSR 1-port FXO SIC Module JD559A
 HP A-MSR 2-port FXS SIC Module JD560A
 HP A-MSR 1-port FXS SIC Module JD561A
 HP A-MSR 4-port FXS/1-port FXO DSIC Mod JG189A
HP A-MSR 1-port E1 Voice SIC Module JF821A
 HP A-MSR 2-port FXS/1-port FXO SIC Module JD632A
 HP A-MSR 1-port E1/Fractional E1 (75ohm) SIC Module JD634B
 HP A-MSR 1-port T1/Fractional T1 SIC Module JD538A
 HP A-MSR 2-port E1/Fractional E1 (75ohm) SIC Module JF842A
 HP A-MSR 1-port Enhanced Sync/Async Serial SIC Module JD557A
 HP A-MSR 1-port ISDN-S/T SIC Module JD571A
 HP A-MSR 8-port Async Serial SIC Module JF281A
 HP A-MSR 16-port Async Serial SIC Module JG186A
 HP A-MSR HSPA/WCDMA SIC Module JG187A
 HP A-MSR 1-port ADSL over POTS SIC Mod JD537A
 HP MSR 1-p ADSL over ISDN BRI U SIC Mod JG056B
 HP A-MSR 1-p 8-wire G.SHDSL DSIC Module JG191A
 HP MSR 1p E1/CE1/PRI SIC Mod JG604A
 HP MSR 4G LTE SIC Mod for Verizon JG742A
 HP MSR 4G LTE SIC Mod for ATT JG743A
 HP MSR 4G LTE SIC Mod for Global JG744A
 HP MSR 2p Enh Sync/Async Srl SIC Mod JG736A
 HP MSR 4p Enh Sync/Async Srl SIC Mod JG737A
 HP MSR 1p GbE Combo SIC Mod JG738A
 HP MSR 4p Gig-T Switch SIC Mod JG739A
 HP MSR 4p Gig-T PoE Switch SIC Mod JG740A
2.1.3 MSR3000 Series Routers
The HP MSR3000 series routers are components of the HP FlexBranch solution, which is a part of the
comprehensive HP FlexNetwork architecture. These router appliances feature a modular design that delivers
application services for medium to large-sized branch offices. This provides the benefit of reduced complexity, and
simplified configuration, deployment, and management. The MSR3000 routers use the latest multicore central
processing units (CPUs), offer Gigabit switching, provide an enhanced Peripheral Component Interconnect (PCI)
bus, and provides a full-featured, resilient routing platform, including IPv6 and Multiprotocol Label Switching
(MPLS), with up to 5 million packets per second (Mpps) forwarding capacity and 3.3 Gb/s of IPsec VPN encrypted
throughput. The evaluation covered IPsec capabilities specified in the NDPP. The MSR3000 router series provide up
to three on-board Gigabit Ethernet ports. They support Layer 2 switching, select Layer 3 services, and static Layer 3
routing, as well as provide dual IP stack to transition from IPv4 to IPv6. The series include:
 HP MSR 3012 AC Router JG409A
 HP MSR 3012 DC Router JG410A
 HP MSR 3024 AC Router JG406A
 HP MSR 3024 DC Router JG407A
 HP MSR 3024 PoE Router JG408A
 HP MSR 3044 Router JG405A
Security Target Version 1.0, 2/16/2016
12
 HP MSR 3064 Router JG404A
The following modules, extending the physically available ports, are supported by this series and can optionally be
used since they do not affect any of the claimed security functions but rather serve to extend available network
connectivity:
 HP A-MSR 4-port 10/100Base-T Switch SIC Module JD573B
 HP A-MSR 9-port 10/100Base-T Switch DSIC Module JD574B
 HP A-MSR 1-port 10/100Base-T SIC Module JD545B
 HP A-MSR 1-port 100Base-X SIC Module JF280A
 HP A-MSR 2-port FXO SIC Module JD558A
 HP A-MSR 1-port FXO SIC Module JD559A
 HP A-MSR 2-port FXS SIC Module JD560A
 HP A-MSR 1-port FXS SIC Module JD561A
 HP A-MSR 4-port FXS/1-port FXO DSIC Mod JG189A
 HP A-MSR 1-port E1 Voice SIC Module JD575A
 HP A-MSR 1-port T1 Voice SIC Module JD576A
 HP A-MSR 2-port ISDN-S/T Voice SIC Module JF821A
 HP A-MSR 2-port FXS/1-port FXO SIC Module JD632A
 HP A-MSR 1-port E1/Fractional E1 (75ohm) SIC Module JD634B
 HP A-MSR 1-port T1/Fractional T1 SIC Module JD538A
 HP A-MSR 2-port E1/Fractional E1 (75ohm) SIC Module JF842A
 HP A-MSR 1-port Enhanced Sync/Async Serial SIC Module JD557A
 HP A-MSR 1-port ISDN-S/T SIC Module JD571A
 HP A-MSR 8-port Async Serial SIC Module JF281A
 HP A-MSR 16-port Async Serial SIC Module JG186A
 HP A-MSR HSPA/WCDMA SIC Module JG187A
 HP A-MSR 1-port ADSL over POTS SIC Mod JD537A
 HP MSR 1-p ADSL over ISDN BRI U SIC Mod JG056B
 HP A-MSR 1-p 8-wire G.SHDSL DSIC Module JG191A
 HP MSR 1p E1/CE1/PRI SIC Mod JG604A
 HP MSR 4G LTE SIC Mod for Verizon JG742A
 HP MSR 4G LTE SIC Mod for Global JG743A
 HP MSR 4G LTE SIC Mod for Global JG744A
 HP A-MSR 4-port 10/100Base-T PoE Switch SIC Module JD620A
 HP A-MSR 9-port 10/100Base-T PoE Switch DSIC Module JD621A
 HP MSR 2p Enh Sync/Async Srl SIC Mod JG736A
 HP MSR 4p Enh Sync/Async Srl SIC Mod JG737A
 HP MSR 1p GbE Combo SIC Mod JG738A
 HP MSR 4p Gig-T Switch SIC Mod JG739A
 HP MSR 4p Gig-T PoE Switch SIC Mod JG740A
2.1.4 MSR4000 Series Routers
The HP MSR 4000 series routers are components of the HP FlexBranch solution, which is a part of the
comprehensive HP FlexNetwork architecture. These router appliances feature a modular design that delivers
application services for extra-large branch offices, headquarters, and campuses. This provides the benefit of reduced
complexity, and simplified configuration, deployment, and management. The MSR 4000 series leverages separated
data and control planes, dual main processing units (MPUs), and support for up to four power supplies, which
provides outstanding performance and reliability.
The MSR4000 routers provide a full-featured, resilient routing platform with the latest multicore CPUs, offer 10
Gigabit switching, provide an enhanced PCI bus, and ship with the latest version of HP Comware software to help
ensure high performance with concurrent services. The MSR4000 series provides a full-featured, resilient routing
platform, including IPv6 and MPLS, with up to 20 Mpps forwarding capacity and 8 Gb/s of IPsec VPN encrypted
throughput. The evaluation included IPsec capabilities as specified in the NDPP . The series include:
Security Target Version 1.0, 2/16/2016
13
 HP MSR 4060 Router Chassis with HP MSR4000 MPU-100 Main Processing Unit (JG403A)
 HP MSR 4080 Router Chassis with HP MSR4000 MPU-100 Main Processing Unit (JG402A)
Note: Each model series must also have one of the following Service Processing Units: HP MSR4000 SPU-100
Service Processing Unit (JG413A); HP MSR4000 SPU-200 Service Processing Unit (JG414A); or HP MSR4000
SPU-300 Service Processing Unit (JG670A).
Most of the available modules, including the fabric modules, serve to extend the number of physical ports available
and the throughput performance to the base appliance. However, the Main Processing Unit and the Service
Processing Units serve to add additional processing power to the base appliance. A service processing unit performs
data forwarding, encryption or decryption, and analyzing or filtering of data packets. A main processing unit
performs route calculation, forward table maintenance, and configures and monitors the SPU. MPUs and SPUs
execute the same multiprocessor-capable operating system in conjunction with the instance operating on the
processor(s) found in the base appliance.
The following modules are supported by this series and can optionally be used since they do not affect any of the
claimed security functions but rather serve to extend available network connectivity:
 HP MSR G2 128-channel Voice Processing Module
 HP A-MSR 1-port E1 Voice MIM Module JD565B
 HP A-MSR 2-port E1 Voice MIM Module JD567B
 HP A-MSR 1-port T1 Voice MIM Module JD566B
 HP MSR 1-port E3 / CE3 / FE3 HMIM Module
 HP A-MSR 2-port T1 Voice MIM Module JD568B
 HP A-MSR 16-port FXS MIM Module JF822A
 HP A-MSR 16-port Enhanced Async Serial MIM Module JF841A
 Note 13 0.5U HMIM Adapter Modules can adapt following MIM Modules:
 HP A-MSR 8-port Enhanced Async Serial MIM Module JF840A
 HP A-MSR 1-port T3/CT3/FT3 MIM Module JD628A
 HP A-MSR 1-port E3/CE3/FE3 MIM Module JD630A
 HP A-MSR 1-port OC-3c/STM-1c POS MIM Module JG193A
 HP A-MSR 2-port Enhanced Sync/Async Serial MIM Module JD540A
 HP A-MSR 4-port Enhanced Sync/Async Serial MIM Module JD541A
 HP A-MSR 8-port Enhanced Sync/Async Serial MIM Module JD552A
 HP A-MSR 4-port FXS MIM Module JD553A
 HP A-MSR 4-port FXO MIM Module JD542A
 HP A-MSR 4-port E&M MIM Module JD539A
 HP A-MSR 2-port E1/CE1/PRI MIM Module JD544B
 HP A-MSR 4-port E1/CE1/PRI MIM Module JD550B
 HP A-MSR 8-port E1/CE1/PRI (75ohm) MIM Module JD563A
 HP A-MSR 4-port E1/Fractional E1 MIM Module JF257B
 HP A-MSR 8-port E1/Fractional E1 (75ohm) MIM Module JF255A
 HP A-MSR 2-port T1/CT1/PRI MIM Module
 HP A-MSR 4-port T1/Fractional T1 MIM Module JF254B
 HP A-MSR 8-port T1/CT1/PRI MIM Module JC160A
 HP A-MSR 8-port T1/Fractional T1 MIM Module JC159A
 HP A-MSR 2-port 10/100Base-T MIM Module JD613A
 HP A-MSR 4-port 10/100Base-T MIM Module JD551A
 HP A-MSR 2-port Gig-T MIM Module JD548A
 HP A-MSR 2-port FXO MIM Module JD543A
 HP A-MSR 4-port ISDN-S/T Voice MIM Module JF837A
 HP MSR G2 128-channel Voice Processing Module
Security Target Version 1.0, 2/16/2016
14
2.2 TOE Architecture
The various routers comprising the TOE share a common software code base, called Comware. Comware is special
purpose appliance system software that implements a wide array of networking technology, including: IPv4/IPv6
dual-stacks, a data link layer, layer 2 and 3 routing, Ethernet switching, Virtual Local Area Network (VLANs),
Quality of Service (QoS), etc. The evaluated version of Comware is V7.1.059, Release 0305. It should be noted that
Comware runs on a variety of underlying architectures including VxWorks, Linux, pSOS and Windows; however,
the only underlying architecture found in the evaluated configuration is Linux. The TOE supports both IPv4 and
IPv6 networks; however, IPv6 was not tested as part of this evaluation.
Comware V7.1.059, Release 0305 implements full modularization and multi-process applications, as well as
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.
 ISSU—Supports ISSU for line cards.
 Auxiliary CPU and OAA—Improve scalability for devices.
In addition, Comware V7.1 supports IETF industry standard TRILL (Transparent Interconnection of Lots of Links).
TRILL provides support for VLANs and is a link state routing protocol running over layer 2 that enables loop free
large Layer 2 networks with multi-path support. TRILL and the optimization functions are not security relevant and
not covered by the evaluation but can be included in the evaluated configuration as they do not affect any of the
claimed security functions.
Comware V7.1 comprises four planes: management plane, control plane, data plane, and infrastructure plane:
Figure 1 Comware V7.1 Architecture
 Infrastructure plane – 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
infrastructures for Comware processes, including all basic functions.
Security Target Version 1.0, 2/16/2016
15
 Data plane – The data plane provides data forwarding for local packets and received IPv4 and IPv6 packets
at different layers.
 Control plane – 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 plane – The management plane provides a management interface for operators to configure,
monitor, and manage Comware V7.1. The management interface comprises a CLI accessed using Secure
Shell (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 a wide range of 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 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.
Note that since this technology is not covered in the NDPP, the Multitenant device context virtualization technology
was not subject to evaluation.
2.2.2 Physical Boundaries
A TOE device in MSR1000 Series, MSR2000 Series, MSR3000 Series, or MSR4000 Series is a physical network
rack-mountable appliance with a fixed number of Ethernet ports as shown in Table 2. Each series also supports
modules that serve to offer a wide range of network ports varying in number, form factor (copper or fiber), and
performance (1 – 10 Gb). The applicable modules for each series are identified in Section 2.1.
Product Series Specific Devices CPU Ports
HP MSR1000 HP MSR1002-4 AC Router Freescale P1016 10
HP MSR1003-8S AC Router Freescale P1016 10
HP MSR2000 HP MSR2003 AC Router Freescale P1021 2
HP MSR2004-24 AC Router Freescale P1021 2
HP MSR2004-48 Router Freescale P1021 2
HP MSR3000 HP MSR3012 AC Router Cavium CN6130 4
HP MSR3012 DC Router Cavium CN6130 4
HP MSR3024 AC Router Cavium CN6130 4
HP MSR3024 DC Router Cavium CN6130 4
HP MSR3024 PoE Router Cavium CN6130 4
HP MSR3044 Router Cavium CN6130 5
HP MSR3064 Router Cavium CN6635 5
Security Target Version 1.0, 2/16/2016
16
HP MSR4000 HP MSR 4060 Router Chassis Cavium CN6218 4
HP MSR 4080 Router Chassis Cavium CN6218 4
HP MSR4000 Service Processing Units SPU-100 Cavium6740,1Ghz,MIPS -
SPU-200 Cavium6760,1Ghz,MIPS -
SPU-300 Cavium6880,1.2Ghz,MIPS -
Table 2 CPU’s and Number of Fixed Ports by Device
The TOE can be configured to rely on and use a number of other 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 CLI access and as such an administrator would need a
SSHv2 client to use the administrative interface.
2.2.3 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.3.1 Security audit
The TOE is able to generate logs for a wide range of security relevant events including the events specified in NDPP
. The TOE can be configured to store the logs locally so they can be accessed by an administrator or alternately to
send the logs to a designated external log server.
2.2.3.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 in the evaluated configuration, the TOE must be
configured in FIPS mode, which ensures the TOE uses only FIPS-approved and NIST-recommended cryptographic
algorithms..
2.2.3.3 User data protection
The TOE performs network switching and routing functions, passing network traffic among its various physical and
logical network connections. While implementing applicable network protocols associated with network traffic
forwarding, the TOE employs mechanisms to ensure that it does not inadvertently reuse data found in network
traffic.
2.2.3.4 Identification and authentication
The TOE requires 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.
Security Target Version 1.0, 2/16/2016
17
The TOE supports on device definition of administrators with usernames and passwords. Additionally, the TOE can
be configured to utilize the services of trusted RADIUS and TACACS+ servers in the operational environment to
support, for example, centralized user administration. The TOE supports the use of text-based pre-shared keys for
IKE peer authentication.
2.2.3.5 Security management
The TOE provides Command Line (CLI) commands to access a range of security management functions. Security
management commands are limited to administrators and are available only after they have provided acceptable
identification and authentication data to the TOE.
2.2.3.6 Protection of the TSF
The TOE implements a number of features to ensure the reliability and integrity of its security features.
It protects 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 (for
example, 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 to ensure updates to the TOE will not introduce malicious or other unexpected changes in the TOE.
2.2.3.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 which, when exceeded, will terminate the inactive session.
2.2.3.8 Trusted path/channels
The TOE protects interactive communication with administrators using SSHv2 for CLI access. Using SSHv2, both
integrity and disclosure protection are ensured.
The TOE protects communication with network peers, such as audit and authentication servers, using IPsec
connections to prevent unintended disclosure or modification of logs.
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 Enterprise MSR1000, MSR2000,
MSR3000 and MSR4000 router series based on Comware V7.1”, Version V1.01, dated 2/16/2016
 “Command Reference for CC Supplement”, Revision 1.05, dated 1/22/2016
 “Configuration Guide for CC Supplement”, Revision 1.6, dated 1/22/2016
 “Comware V7 Platform System Log Messages”, Revision 1.00, 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
router series. Note that only the documents listed above were examined during the course of the evaluation, and are
the approved documents for configuring and using the TOE in its evaluated configuration.
Security Target Version 1.0, 2/16/2016
18
3. Security Problem Definition
This security target includes by reference the Security Problem Definition (composed of organizational policies,
threat statements, and assumption) from NDPP. There are no additional assumptions.
In general, the NDPP presents a Security Problem Definition appropriate for network devices, such as routers, and
as such is applicable to the Hewlett Packard Enterprise TOE.
Security Target Version 1.0, 2/16/2016
19
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 presents Security Objectives appropriate for network infrastructure devices, such as routers,
and as such are applicable to the Hewlett Packard Enterprise TOE.
4.1 Security Objectives for the Operational 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 1.0, 2/16/2016
20
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 TOE and to scope the evaluation effort.
The SFRs have all been drawn from NDPP as amended by Errata #3. As a result, refinements and operations already
performed in the protection profile (PP) are not identified (for example, highlighted) here. Rather the requirements
have been copied from the PP and any residual operations have been completed herein. Of particular note, NDPP
makes a number of refinements and completed some of the SFR operations defined in the CC and the reader should
consult that PP 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. Since this ST does not redefine the extended SFRs, the reader should consulted NDPP 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 1.0, 2/16/2016
21
5.2 TOE Security Functional Requirements
The following table identifies the SFRs that are satisfied by the Hewlett Packard Enterprise MSR Routers.
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 3 TOE Security Functional Components
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 4.
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
Security Target Version 1.0, 2/16/2016
22
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 4.
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. Reason for failure.
Establishment/Termination of an IPsec
SA.
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
Establishment/Termination of an SSH
session.
Non-TOE endpoint of connection (IP
address) for both successes and
failures.
FDP_RIP.2 None.
FIA_PMG_EXT.1 None.
FIA_PSK_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.
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.
Security Target Version 1.0, 2/16/2016
23
Requirement Auditable Events Additional Audit Record Contents
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 4 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-56A, “Recommendation for Pair-Wise Key
Establishment Schemes Using Discrete Logarithm Cryptography” for elliptic
curve-based key establishment schemes and implementing “NIST curves” P-256,
P-384 and [P-521] (as defined in FIPS PUB 186-3, “Digital Signature Standard”)
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, GCM, [CTR]] and
cryptographic key sizes 128-bits and 256-bits that meets the following:
 FIPS PUB 197, 'Advanced Encryption Standard (AES)'
 [NIST SP 800-38A, NIST SP 800-38D].
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 [
(2) RSA Digital Signature Algorithm (rDSA) with a key size (modulus) of 2048
bits or greater or
Security Target Version 1.0, 2/16/2016
24
(3) Elliptic Curve Digital Signature Algorithm (ECDSA) with a key size of 256
bits or greater]
that meets the following:
[Case: RSA Digital Signature Algorithm
 FIPS PUB 186-2 or FIPS PUB 186-3, 'Digital Signature Standard'.
Case: Elliptic Curve Digital Signature Algorithm
 FIPS PUB 186-3, 'Digital Signature Standard'.
 The TSF shall implement “NIST curves” P-256, P-384 and [P-521] (as
defined in 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-384, SHA-512] and message
digest sizes [160, 256, 384, 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, SHA-384, SHA-
512], key size [160, 256, 384, 512 bits], and message digest sizes [160, 256, 384, 512]
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,
 AES-GCM-128 as specified in RFC 4106,
 AES-GCM-256 as specified in RFC 4106,
].
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]; IKEv2 as defined in RFCs 5996 (with mandatory support for NAT traversal
as specified in section 2.23), 4307, and [RFC 4868 for hash functions]].
FCS_IPSEC_EXT.1.6 The TSF shall ensure the encrypted payload in the [IKEv1, IKEv2] protocol uses the
cryptographic algorithms AES-CBC-128, AES-CBC-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 [IKEv2 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
Security Target Version 1.0, 2/16/2016
25
hours for Phase 15
SAs and 8 hours for Phase 26
SAs]; 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 [24 (2048-bit MODP with 256-bit POS), 19 (256-bit Random ECP) (IKEv2 only),
and 20 (384-bit Random ECP (IKEv2 only))].
FCS_IPSEC_EXT.1.10 The TSF shall ensure that all IKE protocols perform Peer Authentication using the [RSA,
ECDSA (IKEv2 only)] algorithm and Pre-shared Keys.
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]7
.
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, [AEAD_AES_128_GCM,
AEAD_AES_256_GCM].
FCS_SSH_EXT.1.5 The TSF shall ensure that the SSH transport implementation uses [SSH_RSA, ecdsa-
sha2-nistp256] and [ecdsa-sha2-nistp384] 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, hmac-sha2-256, hmac-sha2-512].
FCS_SSH_EXT.1.7 The TSF shall ensure that diffie-hellman-group14-sha1 and [ecdh-sha2-nistp256, ecdh-
sha2-nistp384] 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
That is, IKE_SA_INIT and IKE_AUTH exchanges in IKEv2.
6
That is, CREATE_CHILD_SA exchange in IKEv2.
7
Marked as a selection per NIAP Technical Decision TD0032 (https://www.niap-
ccevs.org/Documents_and_Guidance/view_td.cfm?td_id=34)
Security Target Version 1.0, 2/16/2016
26
5.2.4 Identification and authentication (FIA)
5.2.4.1 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;
5.2.4.2 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 [use no other
pre-shared keys].
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 routing 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:
Security Target Version 1.0, 2/16/2016
27
 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.
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.
Security Target Version 1.0, 2/16/2016
28
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.
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 1.0, 2/16/2016
29
5.3 TOE Security Assurance Requirements
The security assurance requirements for the TOE are included by reference to 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 5 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, as well as all of the events identified in Table 4 (which corresponds to
the audit events specified in NDPP). Note that the only protocol (that is, SSH, IPsec) failures auditable by the TOE
are authentication failures for user-level connections (including both human user and peer connections).
The logged 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 responsible for the
event (that is, user name for administrator and IP address for network host). The logged audit records also include
event-specific content that includes at least all of the content required in Table 4.
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 the network-admin user
can access to 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. 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:
Security Target Version 1.0, 2/16/2016
30
 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 4. 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 4.
 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
 ECC key pair generation(NIST
curves P-256, P-384 and P-521)
NIST Special Publication 800-56A #834
 RSA key generation (key size 2048
bits)
NIST Special Publication 800-56B #1969
Encryption/Decryption
 AES CBC, CTR, and GCM (128,
256 bits)
FIPS PUB 197
NIST SP 800-38A
NIST SP 800-38D
Firmware: #3855
Kernel: #3854
HW Accelerators: #3850
Cryptographic signature services
 RSA Digital Signature Algorithm
(rDSA) (modulus 2048)
 ECDSA (NIST curves P-256, P-384
and P-521)
FIPS PUB 186-2
FIPS PUB 186-3
Firmware:
#1969 (RSA),
#834(ECDSA)
Cryptographic hashing
 SHA-1, SHA-256, SHA-384 and
SHA-512 (digest sizes 160, 256, 384
and 512 bits)
FIPS Pub 180-3 Firmware: #3177
Kernel: #3176
HW Accelerators: ##3172
Keyed-hash message authentication
 HMAC-SHA-1 (block size 512 bits,
key size 160 bits and digest size 160
bits)
 HMAC-SHA-256 (block size 512
bits, key Size 256 bits and digest
size 256 bits)
 HMAC-SHA-384 (block size 1024
bits, key Size 384 bits and digest
size 384 bits)
 HMAC-SHA-512 (block size 1024
bits, key Size 512 bits and digest
size 512 bits)
FIPS Pub 198-1
FIPS Pub 180-3
Firmware: #2503
Kernel: #2502
HW Accelerators: #2498
Random bit generation
 CTR_DRBG (AES) with one
independent software-based noise
source of 256 of non-determinism
NIST Special Publication 800-90 Firmware: #1094
Table 6 Cryptographic Functions
Security Target Version 1.0, 2/16/2016
31
The TOE implements a random number generator for RSA key establishment schemes, finite field-based key
establishment schemes, and for elliptic curve-based key establishment (conformant to NIST SP 800-56B and to
NIST SP 800-56A). The following table demonstrates that the TSF complies with SP 800-56B. The table identifies
the sections in 800-56B that are implemented by the TSF. While the TOE generally fulfills all of the NIST SP 800-
56B requirements without extensions, the following table specifically identifies 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
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
Security Target Version 1.0, 2/16/2016
32
NIST SP800-56B
Section Reference
“should”, “should not”, or
“shall not”
Implemented
accordingly?
Rationale for deviation
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 7 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 source is a 256-bit value derived from the Comware entropy pool. 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
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. Table 8 identifies the applicable secret and private keys and CSPs and
summarizes, how and when they are deleted. 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
ECDSA private
key
CTR_DRBG(AE
S)/ECDSA
NIST P256,
P384, P521
Identity certificates for the
security appliance itself
and also used in IPsec,
SSH and SSL.
FLASH
(cipher text
/AES-CTR
256)
Using CLI command
“public-key local
destroy ecdsa …” to
zeroize.
CSP1-3 RSA Public keys RSA
RSA:1024 ~
2048 bits
Note: 192 –
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.
CSP1-4
ECDSA Public
keys
ECDSA
NIST P256,
P384, P521
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
Security Target Version 1.0, 2/16/2016
33
#
Key/
CSP Name
Generation/
Algorithm
Key Size Description Storage Zeroization
zeroize the public
keys.
IPsec
CSP2-1
IPsec
authentication
keys
Generated using
IKE protocol
(CTR_DRBG
(AES)+HMAC-
SHA1/HMAC-
SHA256/SHA38
4/SHA512+DH).
Algorithms:
HMAC-SHA1-96
HMAC-SHA-
256-128
HMAC-SHA-
384-192
HMAC-SHA-
512-256
AES-GMAC
160 bits
256 bits
384 bits
512 bits
AES-GMAC:
128, 256 bits
Note: GMAC
is not used
in any of the
evaluated
mechanisms
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/SHA38
4/SHA512+DH).
Algorithms:
AES-CBC, AES-
GCM
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.
CSP2-3
IPsec
authentication
keys
HMAC-SHA1-96
HMAC-SHA-
256-128
HMAC-SHA-
384-192
HMAC-SHA-
512-256
160 bits
256 bits
384 bits
512 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”,
IKEv1
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
(cipher 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
RSA: 2048
bits
private key used for
IKE protocol during
the handshake
RAM(plain
text)
Automatically
zeroized upon
handshake finishing
Security Target Version 1.0, 2/16/2016
34
#
Key/
CSP Name
Generation/
Algorithm
Key Size Description Storage Zeroization
CSP3-3
IKE Diffie-
Hellman Key
Pairs
CTR_DRBG
(AES) / DH
2048 bits Key agreement for IKE
RAM (plain
text)
Automatically
zeroized upon
handshake finishing
CSP3-4 IKE Integrity key
Generated using
IKE
(CTR_DRBG
(AES)+HMAC-
SHA1/HMAC-
SHA256/SHA38
4/SHA512+DH).
Algorithms:
HMAC-SHA1,
HMAC-SHA256
HMAC-SHA384,
HMAC-SHA512
160 bits
256 bits
Used for integrity test of
IKE negotiations
RAM (plain
text)
Zeroized upon
deleting the IKE
session.
CSP3-5
IKE Encryption
Key
Generated using
IKE
(CTR_DRBG
(AES)+HMAC-
SHA1/HMAC-
SHA256/SHA38
4/SHA512+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.
IKEv2
CSP4-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”,
CSP4-2
IKE RSA
Authentication
private Key
RSA
ECDSA
RSA:2048
bits
ECDSA:P-
256, P-384,
P-521
private key used for
IKE protocol during
the handshake
RAM(plain
text)
Automatically
zeroized upon
handshake finishing
CSP4-3
IKE Diffie-
Hellman Key
Pairs
CTR_DRBG
(AES) /
DH,ECDH
DH:2048
bits
ECDH:P-
256, P-384
Key agreement for IKE
RAM (plain
text)
Automatically
zeroized upon
handshake finishing
CSP4-4 IKE Integrity key
Generated using
IKE
(CTR_DRBG
(AES)+DH/ECD
H + HMAC-
SHA1/HMAC-
SHA256/HMAC-
SHA384).
Algorithms:
HMAC-SHA1,
HMAC-SHA256-
128
HMAC-SHA384-
192
160 bits
256 bits
384 bits
Used for integrity test of
IKE negotiations
RAM (plain
text)
Zeroized upon
deleting the IKE
session.
Security Target Version 1.0, 2/16/2016
35
#
Key/
CSP Name
Generation/
Algorithm
Key Size Description Storage Zeroization
CSP4-5
IKE Encryption
Key
Generated using
IKE
(CTR_DRBG
(AES)+DH/ECD
H + HMAC-
SHA1/HMAC-
SHA256/HMAC-
SHA384).
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
CSP5-1
SSH
Private key
RSA
ECDSA
RSA:2048
bits
ECDSA: P-
256, P-384
private key used for
SSH protocol during
handshake
RAM(plain
text)
Automatically
zeroized upon
finishing
handshake.
CSP5-2
SSH Diffie-
Hellman Key
Pairs
CTR_DRBG
(AES) /
DH/ECDH
DH: 2048
bits
ECDH: P-
256, P-384
Key agreement for SSH
sessions.
RAM (plain
text)
Automatically
zeroized upon
finishing
handshake.
CSP5-3
SSH Session
encryption key
Generated using
the SSH
protocol(CTR_D
RBG(AES)+SHA
1+DH)
Algorithms:
AES-CBC, AES-
GCM
128 bits,
256 bits
Key used for encrypting
SSH session.
RAM (plain
text)
Automatically
zeroized when SSH
session terminated.
CSP5-4
SSH Session
authentication
key
Generated using
the SSH
protocol(CTR_D
RBG(AES)+SHA
1+DH)
Algorithms:
HMAC-SHA1,
HMAC-SHA1-
96, hmac-
sha256, hmac-
sha512
AES-GCM
SHA1: 160
bits
AES-GCM:
128 bits, 256
bits
Key used for
authenticating SSH
session.
RAM (plain
text)
Automatically
zeroized when SSH
session terminated.
AAA
CSP6-1 User Passwords Secret
15 ~ 63
bytes
Critical security
parameters used to
authenticate the
administrator login.
FLASH
(hashed
text/SHA-
512) 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.
CSP6-2 Super password Secret
15 ~ 63
bytes
Critical security
parameters used to
authenticate privilege
promoting.
FLASH
(hashed
text/SHA-
512) and
RAM (plain)
Use CLI command
“undo super
password” to
zeroize the super
password.
Security Target Version 1.0, 2/16/2016
36
#
Key/
CSP Name
Generation/
Algorithm
Key Size Description Storage Zeroization
CSP6-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
(cipher 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”.
CSP6-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
(cipher 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
CSP7-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
CSP7-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
CSP7-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
Table 8 Key/CSP Zeroization Summary
These supporting cryptographic functions are included to support the IPsec, IKE, and SSHv2 (RFCs 4251, 4252,
4253, 4254, and 5656) secure communication protocols. The TOE implements SHA-1, SHA-256, SHA-384 and
SHA-512 (digest sizes 160, 256, 384 and 512 bits) in accordance with FIPS Pub 180-3 for cryptographic hashing.
Security Target Version 1.0, 2/16/2016
37
The TOE supports SSHv2 with AES (CBC, GCM) 128 or 256 bit ciphers, in conjunction with HMAC-SHA-1,
HMAC-SHA-1-96, hmac-sha2-256, or hmac-sha2-512. The TOE supports public key algorithms RSA, ecdsa-sha2-
nistp256, and ecdsa-sha2-nistp384. It supports diffie-hellman-group14-sha1, ecdh-sha2-nistp256 and with ecdh-
sha2-nistp384 key exchange methods. 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 authentication timeout period is 90 seconds
allowing clients to retry only 3 times. Both public-key and password based authentication can be configured.
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 and transport modes. Furthermore, ESP mode “confidentiality only” is disabled by default. The
TOE implements the Encapsulating Security Payload (ESP) IPsec protocol, as defined by RFC 4303, supporting
AES-CBC-128, AES-CBC-256 (both specified by RFC 3602) with HMAC-SHA1 and HMAC-SHA-256; and AES-
GCM-128, and AES-GCM-256 (both specified by 4106). The TOE implements both versions 1 and 2 of Internet
Key Exchange (IKEv1, IKEv2).
IKEv1 is implemented as defined in RFCs 2407, 2408, 2409, and 4109, and 4868 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), HMAC SHA-256 (key size 256 bits), HMAC SHA-384 (key size 384 bits)
and HMAC-512 (key size 512 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 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’s implementation of IKEv2 conforms with RFCs 5996 (with mandatory support for NAT traversal as
specified in section 2.23), 4307, and 4868 for hash functions. IKEv2 supports the same algorithms as for IKEv1
described above. Table 8 sections IPsec and IKEv2 identify HMAC support for key generation, authentication, and
integrity. The TOE supports the 128-bit and 256-bit AES for both IKE_SA and CHILD_SAs.
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 (for example,
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 packet
filtering ACL based on protocol, source IP address and destination IP address. The rules in the packet filtering ACL
can be ordered in the same fashion as in a Security ACL. In the packet filtering ACL, a permit rule equates to
BYPASS, and a deny rule equates to DISCARD. By default, the packet filter permits packets that do not match any
ACL rule to permit. In the evaluated configuration, an administrator changes this action to deny.
Security Target Version 1.0, 2/16/2016
38
IKEv1 and IKEv2 SA lifetime and volume limits can be configured by an authorized administrator. IKEv1 SA
lifetimes can be limited to 24 hours (any value between 60 and 604,800 seconds) for phase 1 and 8 hours any value
from 180 to 604,800 seconds) for phase 2 and also to as little as 2.5 MB (any value between 2,560 and
4,294,967,295 KB) of traffic for phase 2. IKEv2_SA lifetime can be limited to 24 hours (any value between 120 and
86,400 seconds). CHILD_SA lifetimes can be limited to 8 hours (any value from 180 to 604,800 seconds). Volume
can be limited to as little as 2.5 MB (any value between 2,560 and 4,294,967,295 KB).
The IKEv1 protocols implemented by the TOE include DH Groups 2 (1024-bit MODP), 5 (1536-bit MODP), 14
(2048-bit MODP), and 24 (2048-bit MODP with 256-bit POS) and use RSA (aka rDSA) peer authentication.
However, when the TOE is operating in FIPS mode, only DH Groups 14 and 24 are 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 IKEv2 protocol
implemented by the TOE includes DH 14 (2048-bit MODP), 24 (2048-bit MODP with 256-bit POS), 19 (256-bit
Random ECP), and 20 (384-bit Random ECP) using RSA and ECDSA peer authentication. In the IKE_SA_INIT
and CREATE_CHILD_SA 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.
The TOE can be configured to use pre-shared keys with a given peer. When a pre-shared key is configured, IKE
peer authentication will be performed using the configured pre-shared key, provided that the peer also has the pre-
shared key. Text-based pre-shared keys used for IKE can be constructed of essentially any alphabetic character
(upper and lower case), numerals, and special characters (for example, “!”, “@”, “#”, “$”, “%”, “^”, “&”, “*”, “(“,
and “)”) and can be anywhere from 15 to 128 characters in length (including, for example, 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 IKE peer 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 above.
 FCS_CKM_EXT.4: See table above.
 FCS_COP.1(1): See table above.
 FCS_COP.1(2): See table above.
 FCS_COP.1(3): See table above.
 FCS_COP.1(4): See table above.
 FCS_IPSEC_EXT.1: The TOE supports IPsec cryptographic network communication protection.
 FCS_RBG_EXT.1: See table 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 (for example, 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 zeros.
Security Target Version 1.0, 2/16/2016
39
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 routing 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. CLI and SSHv2 both support password authentication as described below. SSHv2 also supports
public key authentication methods as identified in section 6.2 above. Note that the only capabilities allowed prior to
users authenticating are the display of the warning banner before authentication, and network routing services.
In order to log in using password authentication, the user must provide an identity along with authentication data
corresponding to the provided identity. Users can be defined locally within the TOE with a user identity, password,
and user role. Alternately, users can be defined within an external RADIUS or TACACS+ server configured to be
used by the TOE, each of which also defines the user’s role in the TOE. 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 (for example, 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.
For IPsec, the TOE supports peer authentication with RSA, ECDSA, and pre-shared keys. The TOE can use either
bit-based or text-based pre-shared keys.
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 utilize external RADIUS and TACACS+ authentication
servers.
 FIA_UIA_EXT.1: The TOE only displays the warning banner and allows for network routing 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 admin roles, 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
management capabilities. 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.
Security Target Version 1.0, 2/16/2016
40
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 pre-define roles network-admin and level-15 admin that 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.
While the administrative interface is function rich, the TOE is designed specifically to provide access only to
locally-stored, hashed (and not plain text) passwords. In the evaluated configuration (that is, with FIPS mode
enabled), the TOE protects user passwords by saving a SHA-512 hash of the password. Also, while cryptographic
keys can be entered, the TOE does not disclose any keys stored in the TOE. See Table 8 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.
The TOE is a hardware appliance that includes a hardware-based real-time clock (except for MSR 1000 Series) ).
The real-time clock is a battery-powered clock that is included in a microchip in a computer motherboard. When a
device starts up, the device gets the time from the real-time clock and synchronizes it to the CPU. When the device
is powered off, the real-time clock still keeps track of the current time. Since the MSR 1000 Series does not have a
real-time clock, the TOE maintains time by adding CPU ticks to the default time of the system. The TOE’s
embedded OS manages the clock and exposes administrator clock-related functions. The 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 (that is, 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.
The TOE is designed to support upgrades to the boot ROM program and system boot file as well as to support
software hotfixes. In MSR4000, the upgrade process upgrades both service processing units and main processing
units. There is not a separate upgrade for service processing units. 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. The Basic BootROM and extended BootROM menus provide access to the BootROM program.
Basic BootROM can be accessed by pressing CTRL+D while the device is booting. Note that this can only be
performed while accessing the network device through the Serial Console. Extended BootROM menu can be
accessed by pressing CTRL+B while the device is booting. 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 (Hewlett Packard
Enterprise 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
Security Target Version 1.0, 2/16/2016
41
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 Hewlett Packard Enterprise. 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 hashed 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 TOE includes its own hardware clock (except for MSR 1000 Series, which uses CPU
ticks to maintain time).
 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 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. The banner will be displayed when accessing the
TOE via the console or SSH interfaces.
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 (that is, 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.
An authorized administrator can set an inactivity time limit for IPsec SA. Time limits can be set globally or per
IPsec policy (ipsec sa idle-time and sa idle-time, respectively.
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 banner before
establishing an administrative user session.
Security Target Version 1.0, 2/16/2016
42
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 (for
example, 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 ensure that any authentication operations and exported audit
records are sent only to the configured servers via IPsec communications channels so they are not subject to
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 1.0, 2/16/2016
43
7. Protection Profile Claims
This ST is conformant to the Protection Profile for Network Devices, Version 1.1, 8 June 2012 (NDPP), with the
optional SSH, IPsec and pre-shared key requirements as amended by Errata #3.
The TOE includes Ethernet router 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
support
FCS_CKM.1: Cryptographic Key Generation (for asymmetric keys) NDPP
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
and authentication
FIA_PMG_EXT.1: Password Management NDPP
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
management
FMT_MTD.1: Management of TSF Data (for general TSF data) NDPP
FMT_SMF.1: Specification of Management Functions NDPP
FMT_SMR.2: Restrictions on Security Roles NDPP
FPT: Protection of
the TSF
FPT_APW_EXT.1: Extended: Protection of Administrator Passwords NDPP
FPT_SKP_EXT.1: Extended: Protection of TSF Data (for reading of all
symmetric keys)
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 9 SFR Protection Profile Sources
Security Target Version 1.0, 2/16/2016
44
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 10 Security Functions vs. Requirements Mapping
demonstrates the relationship between security requirements and security functions.
Security Target Version 1.0, 2/16/2016
45
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_PSK_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
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 10 Security Functions vs. Requirements Mapping
Appendix A: Documentation for Hewlett Packard Enterprise MSR1000,
MSR2000, MSR3000, and MSR4000 Routers
The following documents for the MSR Router series can be found under the General Reference section of the Router
Series documentation page for each model on the Hewlett Packard Enterprise Web site. The links are provided
below.
 HP MSR Router Series Security Command Reference (V7), 2015
 HP MSR Router Series Fundamentals Command Reference (V7), 2015
 HP MSR Router Series Network Management and Monitoring Command Reference (V7), 2015
Security Target Version 1.0, 2/16/2016
46
 HP MSR Router Series ACL and QoS Command Reference (V7), 2015
 HP MSR Router Series Layer 3 - IP Services Command Reference (V7), 2015
The following documents for the MSR Router series can be found under the Setup and Install section of the Router
Series documentation page on the Hewlett Packard Enterprise Web site. The links are provided below.
 HP MSR Router Series Security Configuration Guide (V7), 2015
 HP MSR Router Series Fundamentals Configuration Guide (V7), 2015
 HP MSR Router Series Network Management and Monitoring Configuration Guide (V7), 2015
 HP MSR Router Series ACL and QoS Configuration Guide (V7), 2015
 HP MSR Router Series Layer 3 - IP Services Configuration Guide (V7), 2015
MSR1000
http://h20566.www2.hpe.com/portal/site/hpsc/public/psi/home/?sp4ts.oid=6796027&ac.admitted=1453386164725.1
25225703.1938120508#manuals
MSR2000
http://h20565.www2.hpe.com/portal/site/hpsc/public/psi/home/?sp4ts.oid=5408894&ac.admitted=1453386765488.1
25225703.1851288163#manuals
MSR3000
http://h20565.www2.hpe.com/portal/site/hpsc/public/psi/home/?sp4ts.oid=5408895&ac.admitted=1453387059829.1
25225703.1851288163#manuals
MSR4000
http://h20566.www2.hpe.com/portal/site/hpsc/public/psi/home/?sp4ts.oid=5408896&ac.admitted=1453822860455.1
25225703.1938120508#manuals