© 2025 Cisco Systems, Inc. All rights reserved. This document may be reproduced in full without any modification.
-
Cisco MDS 9000 Series Switches Running
NX-OS 9.4
Security Target
Version: 1.1
Date: 3/12/2025
Cisco MDS 9000 Series Switches Security Target
2
Table of Contents
1 SECURITY TARGET INTRODUCTION ................................................................................................................ 8
1.1 ST AND TOE REFERENCE ............................................................................................................................................ 8
1.2 TOE OVERVIEW................................................................................................................................................................ 8
1.2.1 TOE Product Type....................................................................................................................................................... 9
1.2.2 Supported non-TOE Hardware/ Software/ Firmware ................................................................................ 9
1.3 TOE DESCRIPTION........................................................................................................................................................10
1.4 TOE EVALUATED CONFIGURATION .....................................................................................................................11
1.5 PHYSICAL SCOPE OF THE TOE................................................................................................................................11
1.6 LOGICAL SCOPE OF THE TOE...................................................................................................................................13
1.6.1 Security Audit.............................................................................................................................................................14
1.6.2 Cryptographic Support...........................................................................................................................................15
1.6.3 Identification and authentication......................................................................................................................16
1.6.4 Security Management .............................................................................................................................................16
1.6.5 Protection of the TSF...............................................................................................................................................17
1.6.6 TOE Access...................................................................................................................................................................18
1.6.7 Trusted path/Channels...........................................................................................................................................18
1.7 EXCLUDED FUNCTIONALITY ...................................................................................................................................18
2 CONFORMANCE CLAIMS......................................................................................................................................19
2.1 COMMON CRITERIA CONFORMANCE CLAIM...................................................................................................19
2.2 PROTECTION PROFILE CONFORMANCE............................................................................................................19
2.2.1 Protection Profile Additions .................................................................................................................................20
2.3 PROTECTION PROFILE CONFORMANCE CLAIM RATIONALE ..................................................................20
2.3.1 TOE Appropriateness...............................................................................................................................................20
2.3.2 TOE Security Problem Definition Consistency...............................................................................................21
2.3.3 Statement of Security Requirements Consistency........................................................................................21
3 SECURITY PROBLEM DEFINITION...................................................................................................................22
3.1 ASSUMPTIONS ................................................................................................................................................................22
3.2 THREATS...........................................................................................................................................................................23
3.3 ORGANIZATIONAL SECURITY POLICIES.............................................................................................................25
4 SECURITY OBJECTIVES........................................................................................................................................26
4.1 SECURITY OBJECTIVES FOR THE TOE.................................................................................................................26
4.2 SECURITY OBJECTIVES FOR THE ENVIRONMENT.........................................................................................26
5 SECURITY REQUIREMENTS................................................................................................................................27
5.1 CONVENTIONS................................................................................................................................................................27
5.2 TOE SECURITY FUNCTIONAL REQUIREMENTS ..............................................................................................27
5.2.1 Security audit (FAU)................................................................................................................................................28
5.2.1.1 FAU_GEN.1 Audit data generation............................................................................................................28
5.2.1.2 FAU_GEN.2 User Identity Association.......................................................................................................30
5.2.1.3 FAU_STG_EXT.1 External Audit Trail Storage .......................................................................................30
5.2.2 Cryptographic Support (FCS)...............................................................................................................................31
5.2.2.1 FCS_CKM.1 Cryptographic Key Generation (Refinement).................................................................31
5.2.2.2 FCS_CKM.2 Cryptographic Key Establishment (Refinement)...........................................................31
5.2.2.3 FCS_CKM.4 Cryptographic Key Destruction...........................................................................................31
5.2.2.4 FCS_COP.1/DataEncryption Cryptographic Operation (AES Data Encryption/Decryption).32
5.2.2.5 FCS_COP.1/SigGen Cryptographic Operation (Signature Generation and Verification)........32
5.2.2.6 FCS_COP.1/Hash Cryptographic Operation (Hash Algorithm) .......................................................32
5.2.2.7 FCS_COP.1/KeyedHash Cryptographic Operation (Keyed Hash Algorithm) ..............................33
5.2.2.8 FCS_RBG_EXT.1 Random Bit Generation.................................................................................................33
5.2.2.9 FCS_SSHS_EXT.1 SSH Server Protocol.......................................................................................................33
5.2.2.10 FCS_TLSC_EXT TLS Client Protocol ............................................................................................................34
5.2.3 Identification and authentication (FIA) ..........................................................................................................35
5.2.3.1 FIA_AFL.1 Authentication Failure Handling..........................................................................................35
Cisco MDS 9000 Series Switches Security Target
3
5.2.3.2 FIA_PMG_EXT.1 Password Management.................................................................................................35
5.2.3.3 FIA_UIA_EXT.1 User Identification and Authentication.....................................................................35
5.2.3.4 FIA_UAU_EXT.2 Password-based Authentication Mechanism.........................................................35
5.2.3.5 FIA_UAU.7 Protected Authentication Feedback....................................................................................35
5.2.3.6 FIA_X509_EXT.1/Rev X.509 Certificate Validation ..............................................................................36
5.2.3.7 FIA_X509_EXT.2 X.509 Certificate Authentication...............................................................................36
5.2.4 Security management (FMT)...............................................................................................................................37
5.2.4.1 FMT_MOF.1/ManualUpdate Management of security functions behaviour...............................37
5.2.4.2 FMT_MTD.1 CoreData Management of TSF Data.................................................................................37
5.2.4.3 FMT_MTD.1/CryptoKeys Management of TSF data ............................................................................37
5.2.4.4 FMT_SMF.1 Specification of Management Functions..........................................................................37
5.2.4.5 FMT_SMR.2 Restrictions on Security Roles ............................................................................................38
5.2.5 Protection of the TSF (FPT)..................................................................................................................................38
5.2.5.1 FPT_SKP_EXT.1 Extended: Protection of TSF Data (for reading of all symmetric keys) ........38
5.2.5.2 FPT_APW_EXT.1 Protection of Administrator Passwords.................................................................38
5.2.5.3 FPT_STM_EXT.1 Reliable time stamps .....................................................................................................38
5.2.5.4 FPT_TST_EXT.1: TSF Testing (Extended).................................................................................................38
5.2.5.5 FPT_TUD_EXT.1 Trusted Update................................................................................................................39
5.2.6 TOE Access (FTA)......................................................................................................................................................39
5.2.6.1 FTA_SSL_EXT.1 TSF-initiated Session Locking ......................................................................................39
5.2.6.2 FTA_SSL.3 TSF-initiated Termination (Refinement)...........................................................................39
5.2.6.3 FTA_SSL.4 User-initiated Termination (Refinement).........................................................................39
5.2.6.4 FTA_TAB.1 Default TOE Access Banners (Refinement)......................................................................39
5.2.7 Trusted Path/Channels (FTP)..............................................................................................................................39
5.2.7.1 FTP_ITC.1 Inter-TSF trusted channel.......................................................................................................39
5.2.7.2 FTP_TRP.1/Admin Trusted Path (Refinement) ....................................................................................40
5.3 TOE SFR DEPENDENCIES RATIONALE................................................................................................................40
5.4 SECURITY ASSURANCE REQUIREMENTS...........................................................................................................40
5.4.1 SAR Requirements ....................................................................................................................................................40
5.4.2 Security Assurance Requirements Rationale .................................................................................................41
5.5 ASSURANCE MEASURES.............................................................................................................................................41
6 TOE SUMMARY SPECIFICATION.......................................................................................................................43
6.1 TOE SECURITY FUNCTIONAL REQUIREMENT MEASURES........................................................................43
6.2 KEY ZEROIZATION........................................................................................................................................................56
6.3 CAVP CERTIFICATE EQUIVALENCE......................................................................................................................58
7 ANNEX A: REFERENCES .......................................................................................................................................59
Cisco MDS 9000 Series Switches Security Target
4
List of Tables
TABLE 1 ACRONYMS ....................................................................................................................................................................................5
TABLE 2 TERMINOLOGY..............................................................................................................................................................................6
TABLE 3 ST AND TOE IDENTIFICATION...................................................................................................................................................8
TABLE 4 IT ENVIRONMENT COMPONENTS..............................................................................................................................................9
TABLE 5 HARDWARE MODELS AND SPECIFICATIONS ......................................................................................................................... 12
TABLE 6 CAVP CERTIFICATES................................................................................................................................................................ 15
TABLE 7 EXCLUDED FUNCTIONALITY .................................................................................................................................................... 18
TABLE 8 PROTECTION PROFILES............................................................................................................................................................ 19
TABLE 9 TECHNICAL DECISIONS............................................................................................................................................................. 19
TABLE 10 TOE ASSUMPTIONS ............................................................................................................................................................... 22
TABLE 11 THREATS................................................................................................................................................................................. 23
TABLE 12 ORGANIZATIONAL SECURITY POLICIES............................................................................................................................... 25
TABLE 13 SECURITY OBJECTIVES FOR THE ENVIRONMENT............................................................................................................... 26
TABLE 14 SECURITY FUNCTIONAL REQUIREMENTS ........................................................................................................................... 27
TABLE 15 AUDITABLE EVENTS............................................................................................................................................................... 29
TABLE 16 ASSURANCE MEASURES......................................................................................................................................................... 40
TABLE 17 APPLIED ASSURANCE MEASURES........................................................................................................................................ 41
TABLE 18 HOW TOE SFRS ARE MET ................................................................................................................................................... 43
TABLE 19: TOE KEY ZEROIZATION....................................................................................................................................................... 56
TABLE 20: REFERENCES .......................................................................................................................................................................... 59
List of Figures
FIGURE 1 MDS 9000 TOE AND ENVIRONMENT ................................................................................................................................ 10
Cisco MDS 9000 Series Switches Security Target
5
Acronyms
The following acronyms and abbreviations are common and may be used in this
Security Target:
Table 1 Acronyms
Acronyms /
Abbreviations
Definition
AES Advanced Encryption Standard
CC Common Criteria for Information Technology Security Evaluation
CEM Common Evaluation Methodology for Information Technology Security
CM Configuration Management
DCNM Data Center Network Manager
DHCP Dynamic Host Configuration Protocol
HTTP Hyper-Text Transport Protocol
HTTPS Hyper-Text Transport Protocol Secure
ICMP Internet Control Message Protocol
IT Information Technology
NDcPP collaborative Network Device Protection Profile
OS Operating System
PP Protection Profile
PTP Precision Time Protocol
SA Security Association
SAN Storage Area Network
SHS Secure Hash Standard
SIP Session Initiation Protocol
SSHv2 Secure Shell (version 2)
ST Security Target
TCP Transport Control Protocol
TOE Target of Evaluation
TSC TSF Scope of Control
TSF TOE Security Function
TSP TOE Security Policy
UDP User datagram protocol
VRF Virtual Routing and Forwarding
WAN Wide Area Network
© 2025 Cisco Systems, Inc. All rights reserved. This document may be reproduced in full without any modification.
-
Terminology
Table 2 Terminology
Term Definition
Authorized
Administrator
Any user which has been assigned to a privilege level that is permitted to
perform all TSF-related functions.
Peer switch Another switch on the network that the TOE interfaces with.
Security
Administrator
Synonymous with Authorized Administrator for the purposes of this evaluation.
User Any entity (human user or external IT entity) outside the TOE that interacts
with the TOE.
VTY vty is a term used by Cisco to describe a single terminal (whereas Terminal is
more of a verb or general action term).
Cisco MDS 9000 Series Switches Security Target
7
DOCUMENT INTRODUCTION
Prepared By:
Cisco Systems, Inc.
170 West Tasman Dr.
San Jose, CA 95134
This document provides the basis for an evaluation of a specific Target of Evaluation
(TOE), the Cisco MDS 9000 Series Switches (Cisco MDS 9K Series). This Security Target
(ST) defines a set of assumptions about the aspects of the environment, a list of threats
that the product intends to counter, a set of security objectives, a set of security
requirements, and the IT security functions provided by the TOE which meet the set of
requirements. Administrators of the TOE will be referred to as administrators,
Authorized Administrators, TOE administrators, semi-privileged, privileged
administrators, and security administrators in this document.
Cisco MDS 9000 Series Switches Security Target
8
1 SECURITY TARGET INTRODUCTION
The Security Target contains the following sections:
 Security Target Introduction [Section 1]
 Conformance Claims [Section 2]
 Security Problem Definition [Section 3]
 Security Objectives [Section 4]
 IT Security Requirements [Section 5]
 TOE Summary Specification [Section 6]
The structure and content of this ST comply with the requirements specified in the
Common Criteria (CC), Part 1, Annex A, and Part 2.
1.1 ST and TOE Reference
This section provides information needed to identify and control this ST and its TOE.
Table 3 ST and TOE Identification
Name Description
ST Title Cisco MDS 9000 Series Switches Running NX-OS 9.4 Security Target
ST Version 1.1
Publication Date 3/12/2025
Vendor and ST
Author
Cisco Systems, Inc.
TOE Reference Cisco MDS 9000 Series Switches
TOE Hardware
Models
Cisco MDS 9200 Multiservice Switches
Cisco MDS 9100 and 9300 Fabric Switches
Cisco MDS 9700 Series Multilayer Director
TOE Software
Version
Cisco NX-OS version 9.4
Keywords Switch, Data Protection, Audit, Authentication, Encryption, Network
Device, Secure Administration
TOE Guidance Cisco MDS 9000 Series Switches Running NX-OS 9.4 Common Criteria
Operational User Guidance and Preparative Procedures
Cisco MDS 9000 Series Fundamentals Configuration Guide
1.2 TOE Overview
The Target of Evaluation (TOE) is the Cisco MDS 9000 Series Switches running Cisco
NX-OS 9.4 (herein after referred to as Cisco MDS 9K Series, or the TOE).
Cisco MDS 9000 Series Switches Security Target
9
The TOE is comprised of both software and hardware. The hardware is comprised of the
following model series: 9100, 9200, 9300, and 9700. The software is comprised of the
Cisco 9.4 software image Release 9.4.
The TOE is a storage networking-class switch for use in small fabrics and large data
centers with state-of-the-art multiprotocol and distributed multiservice convergence.
The TOE includes the hardware models as defined in Table 3 in Section 1.5.
Cisco 9.4 is a Cisco-developed highly configurable proprietary operating system that
provides for efficient and effective routing and switching. Although Cisco 9.4 performs
many networking functions, this TOE only addresses the functions that provide for the
security of the TOE itself as described in 1.6 Logical Scope of the TOE below.
1.2.1 TOE Product Type
The Cisco MDS 9K Series are storage networking-class switches for use in small fabrics
and large data centers with intelligent SANs. The Cisco MDS 9K Series provides
multilayer support, greater performance and enhanced operations through features
including intelligent services, programmability, automation, analytics, and
manageability.
The Cisco MDS 9100 platform consists of fixed-port switches designed for small,
midsize, and large enterprises that are rapidly deploying cloud-scale applications using
extremely dense virtualized servers. They are Layer 2 and 3 nonblocking Fibre Channel
switches with 32-Gbps of dedicated bandwidth per port. The switch contains 32 ports
with an optional port expansion module to add 16 additional ports.
The Cisco MDS 9200 platform consists of fixed-port switches designed for deploying
high-performance SAN-extension solutions, distributed intelligent fabric services, and
cost-effective multiprotocol connectivity for both open systems and mainframe
environments. They are Layer 2 and 3 nonblocking switches which offer up to twelve
32-Gbps Fibre Channel ports, four 10-, two 25-, and one 40-Gbps Ethernet IP storage
services ports, in a fixed One-Rack-Unit (1RU) form factor.
The Cisco MDS 9300 platform consists of fixed-port switches that are ideal for medium
to large departmental SANs. They are Layer 2 and 3 nonblocking switches that offer up
to 96 Fibre Channel ports with 32-Gbps and 64-Gbps of dedicated bandwidth per port in
a fixed Two-Rack-Unit (2RU) form factor.
The Cisco MDS 9700 platform consists of director-class SAN switches designed for
deployment in small to medium-sized storage networks. They are modular chasses that
that offer up to 192 Fibre Channel ports with up to 64-Gbps of dedicated bandwidth per
port in a fixed Nine-Rack-Unit (9RU) form factor.
1.2.2 Supported non-TOE Hardware/ Software/ Firmware
The TOE supports the following hardware, software, and firmware in its environment
when the TOE is configured in its evaluated configuration:
Table 4 IT Environment Components
Cisco MDS 9000 Series Switches Security Target
10
Component Required Usage/Purpose Description for TOE performance
Local Console Yes This includes any IT Environment Console that is directly connected
to the TOE via the Serial Console Port and is used by the TOE
administrator to support TOE administration.
Management
Workstation with
SSH Client
Yes This includes any IT Environment Management workstation with a
SSH client installed that is used by the TOE administrator to support
TOE administration through SSH protected channels. Any SSH client
that supports SSHv2 may be used.
Syslog Server Yes This includes any syslog server to which the TOE would transmit
syslog messages.
1.3 TOE DESCRIPTION
This section provides an overview of the Cisco MDS 9K Series Target of Evaluation
(TOE). The TOE is comprised of both software and hardware. The hardware is
comprised of the following model series: 9100, 9200, 9300, and 9700. The software is
comprised of the Cisco NX-OS software image Release 9.4.
The Cisco MDS 9000 Series Switches that comprise the TOE have common hardware
characteristics. These characteristics affect only non-TSF relevant functions of the
switches (such as throughput and amount of storage) and therefore support security
equivalency of the switches in terms of hardware.
Cisco NX-OS is a Cisco-developed highly configurable proprietary operating system that
provides for efficient and effective routing and switching. Although Cisco NX-OS
performs many networking functions, this TOE only addresses the functions that
provide for the security of the TOE itself as described in 1.6 Logical Scope of the TOE
below.
The following figure provides a visual depiction of an example TOE deployment. The
TOE boundary is surrounded with a hashed red line.
Figure 1 MDS 9000 TOE and Environment
Cisco MDS 9000 Series Switches Security Target
11
The figure above includes the following:
• The TOE model:
o Cisco MDS 9000 Series Switches
The following are considered to be in the IT Environment:
o Management Workstation
o Syslog Server
For management purposes the TOE provides command line access to administer the
TOE and remote access over SSH.
1.4 TOE Evaluated Configuration
The TOE consists of one or more switches as specified in section 1.5 below and includes
the Cisco NX-OS software. The TOE has two or more network interfaces and is
connected to at least one internal and one external network. The Cisco NX-OS
configuration determines how packets are handled to and from the TOE’s network
interfaces. The switch configuration will determine how traffic flows received on an
interface will be handled. Typically, packet flows are passed through the
internetworking device and forwarded to their configured destination.
If the TOE is to be remotely administered, then the management workstation must be
connected to an internal network and SSHv2 must be used to securely connect to the
TOE. Audit records are stored locally and are also remotely backed up to a remote
syslog server. If these servers are used, they must be attached to the internal (trusted)
network. The internal (trusted) network is meant to be separated effectively from
unauthorized individuals and user traffic; one that is in a controlled environment where
implementation of security policies can be enforced.
All supported modules for the 9100, 9200, and 9300 are considered part of the TOE
evaluated configuration. Supervisor-4 for the 9700 Series is considered part of the TOE
evaluated configuration.
1.5 Physical Scope of the TOE
The TOE is a hardware and software solution that makes up the switch models as
follows: MDS 9100, 9200, 9300, and 9700 series. The network, on which they reside, is
considered part of the environment.
The TOE is comprised of the following physical specifications as described in Table 5
below:
Cisco MDS 9000 Series Switches Security Target
12
Table 5 Hardware Models and Specifications
Model Processor Software Interfaces
Cisco MDS 9100 Series
DS-C9148T-K9-24EK9,
DS-C9148T-K9-24IK9
Intel Xeon D-
1530
(Broadwell DE)
Cisco NX-OS 9.4 Management ports: 2 (1 x
10/100/1000BASE-T and 1 x 1/10G
SFP+)
Console serial port: 1 RS-232
connector
Cisco MDS 9200 Series
DS-C9220I-4PEK9,
DS-C9220I-4PIK9
Intel Xeon D-
1623N
(Broadwell)
Cisco NX-OS 9.4 Management ports: 1 (1 x 10/100
Gigabit Ethernet)
Console serial port: 1 RS-232
connector
Cisco MDS 9300 Series
DS-C9396T-48EK9, DS-
C9396T-48IK9
DS-C9396V-48EK9, DS-
C9396V-48IK9
9396T:
Intel Xeon D-
1530
(Broadwell DE)
9396V:
Intel Xeon D-
1573N
(Broadwell)
Cisco NX-OS 9.4 Management ports: 2 (1 x
10/100/1000BASE-T and 1 x 1/10G
SFP+)
Console serial port: 1 RS-232
connector
USB port (1)
Management ports: 1 (1 x
10/100/1000BASE-T)
Console serial port: 1 RS-232
connector
USB port (1)
Cisco MDS 9700 Series
(any of three chassis models,
each with one or a pair of
Supervisor-4)
Intel Xeon D-
1564N
(Broadwell)
Cisco NX-OS 9.4 DS-X97-SF4-K9 (“Supervisor-4”)
Management ports: 1 (1 x
10/100/1000 Ethernet)
Console serial port: 1 RS-232
Cisco MDS 9000 Series Switches Security Target
13
DS-C9706 with
DS-X97-SF4-K9
DS-C9710 with
DS-X97-SF4-K9
DS-C9718 with
DS-X97-SF4-K9
DS-C9706
6-slot modular chassis
(Supports up to 12.3-Tbps front-panel
Fibre Channel switching and 10.5
Tbps of FCoE)
DS-C9710
10-slot modular chassis
(Supports up to 24-Tbps front-panel
Fibre Channel switching and 21 Tbps
of FCoE)
DS-C9718
18-slot modular chassis
(Supports up to 48-Tbps front-panel
Fibre Channel switching and 42 Tbps
of FCoE)
1.6 Logical Scope of the TOE
The TOE is comprised of several security features. Each of the security features
identified above consists of several security functionalities, as identified below.
1. Security Audit
2. Cryptographic Support
3. Identification and Authentication
4. Security Management
5. Protection of the TSF
6. TOE Access
7. Trusted Path/Channels
Cisco MDS 9000 Series Switches Security Target
14
These features are described in more detail in the subsections below. In addition, the
TOE implements all RFCs of the NDcPPv2.2e as necessary to satisfy testing/assurance
measures prescribed therein.
1.6.1 Security Audit
The Cisco MDS 9000 Series Switches provide extensive auditing capabilities. The TOE
can audit events related to cryptographic functionality, identification and
authentication, enforcement of information flow control policies and administrative
actions. The Cisco MDS 9000 Series Switches generate an audit record for each
auditable event. For each event, the TOE records the date, timestamp, event description,
subject identity that triggered the event and the outcome of the event.
The auditable events include:
• failure on invoking cryptographic functionality such as establishment,
termination and failure of cryptographic session establishments and
connections;
• modifications to the group of users that are part of the authorized administrator
roles;
• all use of the user identification mechanism;
• any use of the authentication mechanism;
• Administrator lockout due to excessive authentication failures;
• any change in the configuration of the TOE;
• changes to time;
• initiation of TOE update;
• indication of completion of TSF self-test;
• maximum sessions being exceeded;
• termination of a remote session;
• attempts to unlock a termination session and
• initiation and termination of a trusted channel.
The authorized administrator configures auditable events, performs back-up
operations, and manages audit data storage. The TOE is configured to transmit the audit
messages to an external syslog server. Communication with the syslog server is
protected by using TLS and the TOE can determine when communication with the
syslog server fails. In the presence of a TLS communication failure,
Cisco MDS 9000 Series Switches Security Target
15
the TOE will continuously and automatically re-attempt to reestablish the syslog
connection in case of a network disruption. In the case of a TLS protocol failure the
administrator should review the configuration of both the TOE and the syslog server.
The audit logs can be viewed on the TOE using the appropriate Cisco NX-OS commands.
The records include the date/time the event occurred, the event/type of event, the user
associated with the event, and additional information of the event and its success
and/or failure. The TOE does not have an interface to modify audit records, though
there is an interface available for the authorized administrator to clear (delete) audit
data stored locally on the TOE.
1.6.2 Cryptographic Support
The TOE provides cryptography in support of other TOE security functionality. All the
algorithms claimed have CAVP certificates (Operation Environment – Intel Xeon
processor). All the algorithms claimed have CAVP certificates.
The NX-OS software calls the CiscoSSL FOM Cryptographic implementation version 7.3a
and has been validated for conformance to the requirements of FIPS 140-2 Level 1.
Refer to Table 6 below for algorithm certificate references.
Table 6 CAVP Certificates
SFR Selection Algorithm Implementation Certificate
Number
FCS_CKM.1 -
Cryptographic
Key Generation
2048 RSA KeyGen CiscoSSL FOM
7.3a
A4446
P-256
P-384
P-521
ECDSA KeyGen and KeyVer CiscoSSL FOM
7.3a
A4446
3072 FFC KeyGen CiscoSSL FOM
7.3a
A4446
FCS_CKM.2 –
Cryptographic
Key
Establishment
2048 RSA key establishment CiscoSSL FOM
7.3a
Testing
using a
known-good
implementat
ion.
P-256
P-384
P-521
KAS-ECC-SSC SP800-
56Ar3
CiscoSSL FOM
7.3a
A4446
3072 KAS-FFC-SSC Sp800-56Ar3 CiscoSSL FOM
7.3a
A4446
FCS_COP.1/
DataEncryption
AES-CBC-128
AES-CBC-256
AES-CTR-128
AES-CTR-256
AES-GCM-128
AES-GCM-256
AES-CBC Encrypt/Decrypt
AES-CTR Encrypt/Decrypt
AES-GCM Encrypt/Decrypt
CiscoSSL FOM
7.3a
A4446
Cisco MDS 9000 Series Switches Security Target
16
SFR Selection Algorithm Implementation Certificate
Number
FCS_COP.1/
SigGen
2048 RSA SigGen and SigVer CiscoSSL FOM
7.3a
A4446
P-256
P-384
P-521
ECDSA SigGen and SigVer CiscoSSL FOM
7.3a
A4446
FCS_COP.1/
Hash
SHA1
SHA-256
SHA-384
SHA-512
SHS CiscoSSL FOM
7.3a
A4446
FCS_COP.1/
KeyedHash
HMAC-SHA1
HMAC-SHA-256
HMAC-SHA-384
HMAC-SHA-512
HMAC CiscoSSL FOM
7.3a
A4446
FCS_RBG_EXT.1
– Random Bit
Generation
HMAC_DRBG
(any)
256 bits
DRBG CiscoSSL FOM
7.3a
A4446
The TOE provides cryptography in support of remote administrative management via
SSHv2 and secure the session between the TOE and remote syslog server using TLS.
1.6.3 Identification and authentication
The TOE performs one type of authentication: authentication for the Authorized
Administrator of the TOE using a local user database.
The TOE provides authentication services for administrative users wishing to connect
to the TOE’s secure CLI administrator interface. The TOE requires Authorized
Administrators to authenticate prior to being granted access to any of the management
functionality. The TOE is configured to require a minimum password length of 8
characters as well as password-strength checking that disables the use of weak
passwords. The TOE provides administrator authentication against a local user
database. Password-based authentication can be performed on the serial console or
SSH interfaces. The SSHv2 interface also supports authentication using SSH keys.
After a configurable number of incorrect login attempts, Cisco MDS 9K Series will
lockout the account until an Authorized Administrator takes action.
The TOE uses X.509v3 certificates as defined by RFC 5280 to support authentication for
TLS connections.
1.6.4 Security Management
The TOE provides secure administrative services for management of general TOE
configuration and the security functionality provided by the TOE. All TOE
administration occurs either through a secure SSHv2 session or via a local console
connection. The TOE provides the ability to securely manage:
• Administration of the TOE locally and remotely;
Cisco MDS 9000 Series Switches Security Target
17
• Configuration of warning and consent access banners;
• Configuration of session inactivity thresholds;
• Updates of the TOE software;
• Configuration of authentication failures;
• Configuration of the audit functions of the TOE;
• Configuration of the TOE provided services; and
• Configuration of the cryptographic functionality of the TOE.
The Cisco MDS 9K Series switch supports the following predefined roles:
• network-admin – This role is a super administrative role. This role has read and
write privileges for any configuration item on the MDS 9000 Series.
• network-operator - This role has read access to the entire Cisco NX-OS device.
• server-admin - Complete read access to the entire Cisco NX-OS device and
upgrade capability.
All administrators are considered to be security administrators in this ST. The Cisco
MDS 9K Series has a CLI that can be administered either remotely using SSHv2 or locally
via a console that is directly connected via a serial cable.
1.6.5 Protection of the TSF
The TOE protects against interference and tampering by untrusted subjects by
implementing identification, authentication, and access controls to limit configuration
and access to Authorized Administrators. The TOE prevents reading of cryptographic
passwords. Additionally, Cisco NX-OS is not a general-purpose operating system and
access to Cisco NX-OS memory space is restricted to only Cisco NX-OS functions.
Use of separate VLANs is used to ensure routing protocol communications between the
TOE and neighbor switches including routing table updates and neighbor switch
authentication will be logically isolated from traffic on other VLANs.
The TOE is able to verify any software updates prior to the software updates being
installed on the TOE to avoid the installation of unauthorized software.
The TOE internally maintains the date and time. This date and time are used as the
timestamp that is applied to audit records generated by the TOE. Administrators can
update the TOE’s clock manually. Finally, the TOE performs power-up self-tests and
conditional self-tests to verify correct operation of the switch itself and that of the
cryptographic module.
Cisco MDS 9000 Series Switches Security Target
18
1.6.6 TOE Access
The TOE can terminate inactive sessions after an Authorized Administrator
configurable time-period. Once a session has been terminated, the TOE requires the
user to re-authenticate to establish a new session. The administrator can also terminate
their own session by exiting out of the CLI.
The TOE can also be configured to display an Authorized Administrator specified
banner on the CLI management interface prior to allowing any administrative access to
the TOE.
1.6.7 Trusted path/Channels
The TOE allows trusted paths to be established to itself from remote administrators
over SSHv2 for remote CLI access. MDS 9K also allows a trusted channel to be
established with a syslog server using TLS.
1.7 Excluded Functionality
The following functionality is excluded from the evaluation.
Table 7 Excluded Functionality
Excluded Functionality Exclusion Rationale
Non-FIPS 140-2 mode of operation This mode of operation includes non-FIPS allowed
operations.
Telnet Telnet will be disabled in the evaluated configuration.
SNMP SNMP will be disabled in the evaluated configuration.
NTP NTP will be disabled in the evaluated configuration.
DCNM GUI The DCNM GUI was not included in the evaluated
configuration.
Bash shell Bash shell interface was not included in the
evaluation.
PTP PTP is not included in the evaluation.
HTTP Server HTTP web server will be disabled in the evaluated
configuration.
IPsec IPsec is not included in the evaluated configuration.
LDAP LDAP is not included in the evaluated configuration.
RADIUS RADIUS is not included in the evaluation.
TACACS+ TACACS+ will be disabled in the evaluated
configuration.
These services will be disabled by configuration settings as described in the Guidance
documents (AGD). The exclusion of this functionality does not affect the compliance to
the collaborative Protection Profile for Network Devices Version 2.2e.
Cisco MDS 9000 Series Switches Security Target
19
2 Conformance Claims
2.1 Common Criteria Conformance Claim
The TOE and ST are compliant with the Common Criteria (CC) Version 3.1, Release 5.
For a listing of Assurance Requirements claimed see section 5.4.
The TOE and ST are CC Part 2 extended and CC Part 3 conformant.
2.2 Protection Profile Conformance
The TOE and ST are conformant with the Protection Profiles as listed in Table 10 below.
Table 8 Protection Profiles
Protection Profile Version Date
collaborative Protection Profile for Network Devices 2.2e 23 March 2020
The following NIAP Technical Decisions (TD) have also been applied to the claims in this
document. Each posted TD was reviewed and considered based on the TOE product
type, the PP claims and the security functions claimed in this document.
Table 9 Technical Decisions
TD # TD Name Protection
Profile
Applicable Exclusion
Rationale
TD0800 Updated NIT Technical Decision for IPsec
IKE/SA Lifetimes Tolerance
NDcPPv2.2e No FCS_IPSEC_EXT.1
is not claimed
TD0792 NIT Technical Decision: FIA_PMG_EXT.1 - TSS
EA not in line with SFR
NDcPPv2.2e Yes
TD0790 NIT Technical Decision: Clarification
Required for testing IPv6
NDcPPv2.2e Yes
TD0738 NIT Technical Decision for Link to Allowed-
With List
NDcPPv2.2e Yes
TD0670 NIT Technical Decision for Mutual and Non-
Mutual Auth TLSC Testing
NDcPPv2.2e Yes
TD0639 NIT Technical Decision for Clarification for
NTP MAC Keys
NDcPPv2.2e No FCS_NTP_EXT.1 is
not claimed
TD0638 NIT Technical Decision for Key Pair
Generation for Authentication
NDcPPv2.2e Yes
TD0636 NIT Technical Decision for Clarification of
Public Key User Authentication for SSH
NDcPPv2.2e No FCS_SSHC_EXT.1
is not claimed
TD0635 NIT Technical Decision for TLS Server and
Key Agreement Parameters
NDcPPv2.2e No FCS_TLSS_EXT.1 is
not claimed
TD0632 NIT Technical Decision for Consistency with
Time Data for vNDs
NDcPPv2.2e No The TOE is not a
vND
TD0631 NIT Technical Decision for Clarification of
public key authentication for SSH Server
NDcPPv2.2e Yes
TD0592 NIT Technical Decision for Local Storage of
Audit Records
NDcPPv2.2e Yes
TD0591 NIT Technical Decision for Virtual TOEs and
hypervisors
NDcPPv2.2e No The TOE is not a
vND
Cisco MDS 9000 Series Switches Security Target
20
TD0581 NIT Technical Decision for Elliptic curve-
based key establishment and NIST SP 800-
56Arev3
NDcPPv2.2e Yes
TD0580 NIT Technical Decision for clarification about
use of DH14 in NDcPPv2.2e
NDcPPv2.2e Yes
TD0572 NiT Technical Decision for Restricting
FTP_ITC.1 to only IP address identifiers
NDcPPv2.2e Yes
TD0571 NiT Technical Decision for Guidance on how
to handle FIA_AFL.1
NDcPPv2.2e Yes
TD0570 NiT Technical Decision for Clarification about
FIA_AFL.1
NDcPPv2.2e Yes
TD0569 NIT Technical Decision for Session ID Usage
Conflict in FCS_DTLSS_EXT.1.7
NDcPPv2.2e No FCS_DTLS_EXT.1
and
FCS_TLSS_EXT.1
are not claimed
TD0564 NiT Technical Decision for Vulnerability
Analysis Search Criteria
NDcPPv2.2e Yes
TD0563 NiT Technical Decision for Clarification of
audit date information
NDcPPv2.2e Yes
TD0556 NIT Technical Decision for RFC 5077 question NDcPPv2.2e No FCS_TLSS_EXT.1 is
not claimed
TD0555 NIT Technical Decision for RFC Reference
incorrect in TLSS Test
NDcPPv2.2e No FCS_TLSS_EXT.1 is
not claimed
TD0547 NIT Technical Decision for Clarification on
developer disclosure of AVA_VAN
NDcPPv2.2e Yes
TD0546 NIT Technical Decision for DTLS –
clarification of Application Note 63
NDcPPv2.2e No FCS_DTLS_EXT.1
is not claimed
TD0537 NIT Technical Decision for Incorrect
reference to FCS_TLSC_EXT.2.3
NDcPPv2.2e Yes
TD0536 NIT Technical Decision for Update
Verification Inconsistency
NDcPPv2.2e Yes
TD0528 NIT Technical Decision for Missing EAs for
FCS_NTP_EXT.1.4
NDcPPv2.2e No FCS_NTP_EXT.1 is
not claimed
TD0527 Updates to Certificate Revocation Testing
(FIA_X509_EXT.1)
NDcPPv2.2e Yes
2.2.1 Protection Profile Additions
The ST claims exact conformance to the collaborative Protection Profile for Network
Devices (NDcPP), Version 2.2e. The ST does not include any additions to the
functionality described in the NDcPPv2.2e.
2.3 Protection Profile Conformance Claim Rationale
2.3.1 TOE Appropriateness
The TOE provides all of the functionality at a level of security commensurate with that
identified in the U.S. Government Protection Profile:
• collaborative Protection Profile for Network Devices (NDcPP), Version 2.2e
Cisco MDS 9000 Series Switches Security Target
21
2.3.2 TOE Security Problem Definition Consistency
The Assumptions, Threats, and Organization Security Policies included in the Security
Target represent the Assumptions, Threats, and Organization Security Policies specified
in the collaborative Protection Profile for Network Devices (NDcPP) for which
conformance is claimed verbatim. All concepts covered in the Protection Profile Security
Problem Definition are included in the Security Target Statement of Security Objectives
Consistency.
The Security Objectives included in the Security Target represent the Security
Objectives specified in the NDcPPv2.2e, for which conformance is claimed verbatim. All
concepts covered in the Protection Profile’s Statement of Security Objectives are
included in the Security Target.
2.3.3 Statement of Security Requirements Consistency
The Security Functional Requirements included in the Security Target represent the
Security Functional Requirements specified in the NDcPP, Version 2.2e, for which
conformance is claimed verbatim. All concepts covered in the Protection Profile’s
Statement of Security Requirements are included in this Security Target. Additionally,
the Security Assurance Requirements included in this Security Target are identical to
the Security Assurance Requirements included in the NDcPP, Version 2.2e.
Cisco MDS 9000 Series Switches Security Target
22
3 SECURITY PROBLEM DEFINITION
This chapter identifies the following:
 Significant assumptions about the TOE’s operational environment.
 IT related threats to the organization countered by the TOE.
 Environmental threats requiring controls to provide sufficient protection.
 Organizational security policies for the TOE as appropriate.
This document identifies assumptions as A.assumption with “assumption” specifying a
unique name. Threats are identified as T.threat with “threat” specifying a unique name.
Organizational Security Policies (OSPs) are identified as P.osp with “osp” specifying a
unique name.
3.1 Assumptions
The specific conditions listed in the following subsections are assumed to exist in the
TOE’s environment. These assumptions include both practical realities in the
development of the TOE security requirements and the essential environmental
conditions on the use of the TOE.
Table 10 TOE Assumptions
Assumption Assumption Definition
A.PHYSICAL_PROTECTION The network device is assumed to be physically protected in its
operational environment and not subject to physical attacks
that compromise the security and/or interfere with the device’s
physical interconnections and correct operation. This protection
is assumed to be sufficient to protect the device and the data it
contains. As a result, the cPP will not include any requirements
on physical tamper protection or other physical attack
mitigations. The cPP will not expect the product to defend
against physical access to the device that allows unauthorized
entities to extract data, bypass other controls, or otherwise
manipulate the device.
A.LIMITED_FUNCTIONALITY The device is assumed to provide networking functionality as its
core function and not provide functionality/ services that could
be deemed as general purpose computing. For example the
device should not provide computing platform for general
purpose applications (unrelated to networking functionality).
A.NO_THRU_TRAFFIC_PROTECTION A standard/generic network device does not provide any
assurance regarding the protection of traffic that traverses it.
The intent is for the network device to protect data that
originates on or is destined to the device itself, to include
administrative data and audit data. Traffic that is traversing the
network device, destined for another network entity, is not
covered by the ND cPP. It is assumed that this protection will be
covered by cPPs for particular types of network devices (e.g.,
firewall).
A.TRUSTED_ADMINISTRATOR The Security Administrator(s) for the network device are
assumed to be trusted and to act in the best interest of security
Cisco MDS 9000 Series Switches Security Target
23
Assumption Assumption Definition
for the organization. This includes being appropriately trained,
following policy, and adhering to guidance documentation.
Administrators are trusted to ensure passwords/credentials
have sufficient strength and entropy and to lack malicious intent
when administering the device. The network device is not
expected to be capable of defending against a malicious
Administrator that actively works to bypass or compromise the
security of the device.
A.REGULAR_UPDATES The network device firmware and software is assumed to be
updated by an administrator on a regular basis in response to
the release of product updates due to known vulnerabilities.
A.ADMIN_CREDENTIALS_SECURE The administrator’s credentials (private key) used to access the
network device are protected by the platform on which they
reside.
A.RESIDUAL_INFORMATION The Administrator must ensure that there is no unauthorized
access possible for sensitive residual information (e.g.
cryptographic keys, keying material, PINs, passwords etc.) on
networking equipment when the equipment is discarded or
removed from its operational environment.
3.2 Threats
The following table lists the threats addressed by the TOE and the IT Environment. The
assumed level of expertise of the attacker for all the threats identified below is
Enhanced-Basic.
Table 11 Threats
Threat Threat Definition
T.UNAUTHORIZED_ADMINISTRATOR_ACCESS Threat agents may attempt to gain Administrator
access to the network device by nefarious means such
as masquerading as an Administrator to the device,
masquerading as the device to an Administrator,
replaying an administrative session (in its entirety, or
selected portions), or performing man-in-the-middle
attacks, which would provide access to the
administrative session, or sessions between network
devices. Successfully gaining Administrator access
allows malicious actions that compromise the
security functionality of the device and the network
on which it resides.
T.WEAK_CRYPTOGRAPHY Threat agents may exploit weak cryptographic
algorithms or perform a cryptographic exhaust
against the key space. Poorly chosen encryption
algorithms, modes, and key sizes will allow attackers
to compromise the algorithms, or brute force exhaust
the key space and give them unauthorized access
allowing them to read, manipulate and/or control the
traffic with minimal effort.
Cisco MDS 9000 Series Switches Security Target
24
Threat Threat Definition
T.UNTRUSTED_COMMUNICATION_CHANNELS Threat agents may attempt to target network devices
that do not use standardized secure tunnelling
protocols to protect the critical network traffic.
Attackers may take advantage of poorly designed
protocols or poor key management to successfully
perform man-in-the-middle attacks, replay attacks,
etc. Successful attacks will result in loss of
confidentiality and integrity of the critical network
traffic, and potentially could lead to a compromise of
the network device itself.
T.WEAK_AUTHENTICATION_ENDPOINTS Threat agents may take advantage of secure protocols
that use weak methods to authenticate the endpoints
– e.g. a shared password that is guessable or
transported as plaintext. The consequences are the
same as a poorly designed protocol, the attacker
could masquerade as the Administrator or another
device, and the attacker could insert themselves into
the network stream and perform a man-in-the-middle
attack. The result is the critical network traffic is
exposed and there could be a loss of confidentiality
and integrity, and potentially the network device
itself could be compromised.
T.UPDATE_COMPROMISE Threat agents may attempt to provide a compromised
update of the software or firmware which
undermines the security functionality of the device.
Non-validated updates or updates validated using
non-secure or weak cryptography leave the update
firmware vulnerable to surreptitious alteration.
T.UNDETECTED_ACTIVITY Threat agents may attempt to access, change, and/or
modify the security functionality of the network
device without Administrator awareness. This could
result in the attacker finding an avenue (e.g.,
misconfiguration, flaw in the product) to compromise
the device and the Administrator would have no
knowledge that the device has been compromised.
T.SECURITY_FUNCTIONALITY_COMPROMISE Threat agents may compromise credentials and
device data enabling continued access to the network
device and its critical data. The compromise of
credentials includes replacing existing credentials
with an attacker’s credentials, modifying existing
credentials, or obtaining the Administrator or device
credentials for use by the attacker.
T.PASSWORD_CRACKING Threat agents may be able to take advantage of weak
administrative passwords to gain privileged access to
the device. Having privileged access to the device
provides the attacker unfettered access to the
network traffic, and may allow them to take
advantage of any trust relationships with other
network devices.
T.SECURITY_FUNCTIONALITY_FAILURE An external, unauthorized entity could make use of
failed or compromised security functionality and
might therefore subsequently use or abuse security
functions without prior authentication to access,
change or modify device data, critical network traffic
or security functionality of the device.
Cisco MDS 9000 Series Switches Security Target
25
3.3 Organizational Security Policies
The following table lists the Organizational Security Policies imposed by an organization
to address its security needs.
Table 12 Organizational Security Policies
Policy Name Policy Definition
P.ACCESS_BANNER The TOE shall display an initial banner describing restrictions of use, legal
agreements, or any other appropriate information to which users consent by
accessing the TOE.
Cisco MDS 9000 Series Switches Security Target
26
4 SECURITY OBJECTIVES
This Chapter identifies the security objectives of the TOE and the IT Environment. The
security objectives identify the responsibilities of the TOE and the TOE’s IT
environment in meeting the security needs.
This document identifies objectives of the TOE as O.objective with objective specifying a
unique name. Objectives that apply to the IT environment are designated as
OE.objective with objective specifying a unique name.
4.1 Security Objectives for the TOE
The collaborative Protection Profile for Network Devices v2.2e does not define any
security objectives for the TOE.
4.2 Security Objectives for the Environment
All of the assumptions stated in section 3.1 are considered to be security objectives for
the environment. The following are the Protection Profile non-IT security objectives,
which, in addition to those assumptions, are to be satisfied without imposing technical
requirements on the TOE. That is, they will not require the implementation of functions
in the TOE hardware and/or software. Thus, they will be satisfied largely through
application of procedural or administrative measures.
Table 13 Security Objectives for the Environment
Environment Security Objective IT Environment Security Objective Definition
OE.PHYSICAL Physical security, commensurate with the value of the
TOE and the data it contains, is provided by the
environment
OE.NO_GENERAL_PURPOSE There are no general-purpose computing capabilities (e.g.,
compilers or user applications) available on the TOE,
other than those services necessary for the operation,
administration and support of the TOE.
OE.NO_THRU_TRAFFIC_PROTECTION The TOE does not provide any protection of traffic that
traverses it. It is assumed that protection of this traffic
will be covered by other security and assurance measures
in the operational environment.
OE.TRUSTED_ADMIN Security Administrators are trusted to follow and apply all
guidance documentation in a trusted manner.
OE.UPDATES The TOE firmware and software is updated by an
Administrator on a regular basis in response to the
release of product updates due to known vulnerabilities.
OE.ADMIN_CREDENTIALS_SECURE The administrator’s credentials (private key) used to
access the TOE must be protected on any other platform
on which they reside.
OE.RESIDUAL_INFORMATION The Security Administrator ensures that there is no
unauthorized access possible for sensitive residual
information (e.g. cryptographic keys, keying material,
PINs, passwords etc.) on networking equipment when the
equipment is discarded or removed from its operational
environment.
Cisco MDS 9000 Series Switches Security Target
27
5 SECURITY REQUIREMENTS
This section identifies the Security Functional Requirements for the TOE. The Security
Functional Requirements included in this section are derived from Part 2 of the
Common Criteria for Information Technology Security Evaluation, Version 3.1, Revision 5,
dated: April 2017 and all international interpretations.
5.1 Conventions
The CC defines operations on Security Functional Requirements. This document uses
the following conventions to identify the operations permitted by [NDcPP] and NIAP
Technical Decisions.
Convention Indication
Assignment Indicated with italicized text
Refinement Indicated with bold text and strikethroughs
Selection Indicated with underlined text
Assignment within a Selection Indicated with italicized and underlined text
Iteration Indicated by adding a string starting with “/” (e.g.
‘FCS_COP.1/Hash’)
Where operations were completed in the [NDcPP] itself, the formatting used in the
[NDcPP] has been retained. Formatting used in [NDcPP] that is inconsistent with the
listed conventions has not been retained in the ST.
5.2 TOE Security Functional Requirements
This section identifies the Security Functional Requirements for the TOE. The TOE
Security Functional Requirements that appear in the following table are described in
more detail in the following subsections.
Table 14 Security Functional Requirements
Class Name Component Identification Component Name
FAU: Security
audit
FAU_GEN.1 Audit data generation
FAU_GEN.2 User Identity Association
FAU_STG_EXT.1 Protected Audit Event Storage
FCS:
Cryptographic
support
FCS_CKM.1 Cryptographic Key Generation (Refined)
FCS_CKM.2 Cryptographic Key Establishment (Refined)
FCS_CKM.4 Cryptographic Key Destruction
FCS_COP.1/DataEncryption Cryptographic Operation (AES Data
Encryption/Decryption)
FCS_COP.1/SigGen Cryptographic Operation (Signature Generation and
Verification)
FCS_COP.1/Hash Cryptographic Operation (Hash Algorithm)
FCS_COP.1/KeyedHash Cryptographic Operation (Keyed Hash Algorithm)
FCS_RBG_EXT.1 Random Bit Generation
Cisco MDS 9000 Series Switches Security Target
28
Class Name Component Identification Component Name
FCS_SSHS_EXT.1 SSH Server Protocol
FCS_TLSC_EXT.1 TLS Client Protocol
FIA:
Identification
and
authentication
FIA_AFL.1 Authentication Failure Management (Refinement)
FIA_PMG_EXT.1 Password Management
FIA_UIA_EXT.1 User Identification and Authentication
FIA_UAU_EXT.2 Password-based Authentication Mechanism
FIA_UAU.7 Protected Authentication Feedback
FIA_X509_EXT.1/Rev X.509 Certificate Validation
FIA_X509_EXT.2 X.509 Certificate Authentication
FMT: Security
management
FMT_MOF.1/ManualUpdate Management of security functions behaviour
FMT_MTD.1/CoreData Management of TSF Data
FMT_MTD.1/CryptoKeys Management of TSF Data
FMT_SMF.1 Specification of Management Functions
FMT_SMR.2 Restrictions on Security Roles
FPT: Protection
of the TSF
FPT_SKP_EXT.1 Extended: Protection of TSF Data (for reading of all
symmetric keys)
FPT_APW_EXT.1 Extended: Protection of Administrator Passwords
FPT_STM_EXT.1 Reliable Time Stamps
FPT_TUD_EXT.1 Trusted update
FPT_TST_EXT.1 TSF Testing (Extended)
FTA: TOE Access FTA_SSL_EXT.1 TSF-initiated Session Locking
FTA_SSL.3 TSF-initiated Termination
FTA_SSL.4 User-initiated Termination
FTA_TAB.1 Default TOE Access Banners
FTP: Trusted
path/channels
FTP_ITC.1 Inter-TSF trusted channel
FTP_TRP.1 Trusted Path
5.2.1 Security audit (FAU)
5.2.1.1 FAU_GEN.1 Audit data generation
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 administrator actions comprising:
• Administrative login and logout (name of user account shall be logged if
individual user accounts are required for Administrators).
• Changes to TSF data related to configuration changes (in addition to the
information that a change occurred it shall be logged what has been
changed).
• Generating/import of, changing, or deleting of cryptographic keys (in
addition to the action itself a unique key name or key reference shall be
logged).
• Resetting passwords (name of related user account shall be logged).
• [no other actions, [no other uses]];
d) Specifically defined auditable events listed in Table 15.
FAU_GEN.1.2 The TSF shall record within each audit record at least the following
information:
Cisco MDS 9000 Series Switches Security Target
29
a) Date and time of the event, type of event, subject identity, and the outcome
(success or failure) of the event; and
b) For each audit event type, based on the auditable event definitions of the
functional components included in the cPP/ST, [information specified in columns
two and three of Table 15].
Table 15 Auditable Events
SFR Auditable Event Additional Audit Record
Contents
FAU_GEN.1 None. None.
FAU_GEN.2 None. None.
FAU_STG_EXT.1 None. None.
FCS_CKM.1 None. None.
FCS_CKM.2 None. None.
FCS_CKM.4 None. None.
FCS_COP.1/DataEncryption None. None.
FCS_COP.1/SigGen None. None.
FCS_COP.1/Hash None. None.
FCS_COP.1/KeyedHash None. None.
FCS_RBG_EXT.1 None. None.
FCS_SSHS_EXT.1 Failure to establish an SSH
session.
Reason for failure
FCS_TLSC_EXT.1 Failure to establish an TLS
session.
Reason for failure
FIA_AFL.1 Unsuccessful login attempts
limit is met or exceeded.
Origin of the attempt (e.g., IP
address).
FIA_PMG_EXT.1 None. None.
FIA_UIA_EXT.1 All use of the identification
and authentication
mechanism.
Origin of the attempt (e.g., IP
address).
FIA_UAU_EXT.2 All use of the authentication
mechanism.
Origin of the attempt (e.g., IP
address).
FIA_UAU.7 None. None.
FIA_X509_EXT.1/Rev Unsuccessful attempt to
validate a certificate
Any addition, replacement, or
removal of trust anchors in
the TOE’s trust store.
Reason for failure of certificate
validation
Identification of certificates
needed, replaced, or removed as
trust anchor in the TOE’s trust
store
FIA_X509_EXT.2 None. None.
FMT_MOF.1/ ManualUpdate Any attempt to initiate a
manual update
None.
FMT_MOF.1/Services None. None.
FMT_MTD.1/CoreData None. None.
FMT_MTD.1/CryptoKeys None. None.
FMT_SMF.1 All management activities of
TSF data.
None.
FMT_SMR.2 None. None.
FPT_APW_EXT.1 None. None.
FPT_SKP_EXT.1 None. None.
FPT_STM_EXT.1 Discontinuous changes to time
- either Administrator
actuated or changed via an
automated process. (Note that
For discontinuous changes to
time: The old and new values
for the time. Origin of the
attempt to change time for
Cisco MDS 9000 Series Switches Security Target
30
SFR Auditable Event Additional Audit Record
Contents
no continuous changes to time
need to be logged. See also
application note on
FPT_STM_EXT.1)
success and failure (e.g., IP
address).
FPT_TST_EXT.1 None. None.
FPT_TUD_EXT.1 Initiation of update. result of
the update attempt (success
or failure)
None.
FTA_SSL_EXT.1 (if “terminate the
session” is selected)
The termination of a local
session by the session locking
mechanism.
None.
FTA_SSL.3 The termination of a remote
session by the session locking
mechanism.
None.
FTA_SSL.4 The termination of an
interactive session.
None.
FTA_TAB.1 None. None.
FTP_ITC.1 Initiation of the trusted
channel.
Termination of the trusted
channel.
Failure of the trusted channel
functions.
Identification of the initiator
and target of failed trusted
channels establishment attempt
FTP_TRP.1/Admin Initiation of the trusted path.
Termination of the trusted
path.
Failure of the trusted path
functions.
None.
5.2.1.2 FAU_GEN.2 User Identity Association
FAU_GEN.2.1 For audit events resulting from actions of identified users, the TSF shall
be able to associate each auditable event with the identity of the user that caused the
event.
5.2.1.3 FAU_STG_EXT.1 External Audit Trail Storage
FAU_STG_EXT.1.1 The TSF shall be able to transmit the generated audit data to an
external IT entity using a trusted channel according to FTP_ITC.1.
FAU_STG_EXT.1.2 The TSF shall be able to store generated audit data on the TOE itself.
In addition [
The TOE shall consist of a single standalone component that stores data locally].
FAU_STG_EXT.1.3 The TSF shall [overwrite previous audit records according to the
following rule: [the newest audit record will overwrite the oldest audit record]] when the
local storage space for audit data is full.
Cisco MDS 9000 Series Switches Security Target
31
5.2.2 Cryptographic Support (FCS)
5.2.2.1 FCS_CKM.1 Cryptographic Key Generation (Refinement)
FCS_CKM.1.1 Refinement: The TSF shall generate asymmetric cryptographic keys in
accordance with a specified cryptographic key generation algorithm: [
• RSA schemes using cryptographic key sizes of 2048-bit or greater that meet the
following: FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Appendix B.3;
• ECC schemes using “NIST curves” [P-256, P-384, P-521] that meet the following:
FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Appendix B.4;
• FFC schemes using cryptographic key sizes of 2048-bit or greater that meet the
following: FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Appendix B.1
] and specified cryptographic key sizes [assignment: cryptographic key sizes] that meet
the following: [assignment: list of standards].
5.2.2.2 FCS_CKM.2 Cryptographic Key Establishment (Refinement)
FCS_CKM.2.1 The TSF shall perform cryptographic key establishment in accordance
with a specified cryptographic key establishment method: [
• RSA-based key establishment schemes that meet the following: RSAES-PKCS1-
v1_5 as specified in Section 7.2 of RFC 3447, “Public-Key Cryptography
Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1”;
• Elliptic curve-based key establishment schemes that meet the following: NIST
Special Publication 800-56A Revision 3, “Recommendation for Pair-Wise Key
Establishment Schemes Using Discrete Logarithm Cryptography”;
• Finite field-based key establishment schemes that meet the following: NIST
Special Publication 800-56A Revision 2, 'Recommendation for Pair-Wise Key
Establishment Schemes Using Discrete Logarithm Cryptography']
] that meets the following: [assignment: list of standards].
5.2.2.3 FCS_CKM.4 Cryptographic Key Destruction
FCS_CKM.4.1 The TSF shall destroy cryptographic keys in accordance with a specified
cryptographic key destruction method
• For plaintext keys in volatile storage, the destruction shall be executed by a [single
overwrite consisting of [ zeroes]];
• For plaintext keys in non-volatile storage, the destruction shall be executed by the
invocation of an interface provided by a part of the TSF that [
Cisco MDS 9000 Series Switches Security Target
32
o logically addresses the storage location of the key and performs a [single
[pass] overwrite consisting of [zeroes]]];
that meets the following: No Standard.
5.2.2.4 FCS_COP.1/DataEncryption Cryptographic Operation (AES Data
Encryption/Decryption)
FCS_COP.1.1/DataEncryption: The TSF shall perform encryption/decryption in
accordance with a specified cryptographic algorithm AES used in [CBC, CTR, GCM] mode
and cryptographic key sizes [128 bits, 256-bits] that meet the following: AES as specified
in ISO 18033-3, [CBC as specified in ISO 10116, CTR as specified in ISO 10116, GCM as
specified in ISO 19772].
5.2.2.5 FCS_COP.1/SigGen Cryptographic Operation (Signature Generation and
Verification)
FCS_COP.1.1/SigGen: The TSF shall perform cryptographic signature services
(generation and verification) in accordance with a specified cryptographic algorithm
[
• RSA Digital Signature Algorithm and cryptographic key sizes (modulus) [2048
bits],
• Elliptic Curve Digital Signature Algorithm and cryptographic key sizes [256 bits,
384 bits, 521 bits]
]
that meet the following:
[
• For RSA schemes: FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Section
5.5, using PKCS #1 v2.1 Signature Schemes RSASSA-PSS and/or RSASSA-
PKCS1v1_5; ISO/IEC 9796-2, Digital signature scheme 2 or Digital Signature
scheme 3,
• For ECDSA schemes: FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Section
6 and Appendix D, Implementing “NIST curves” [P-256, P-384, and P-521];
ISO/IEC 14888-3, Section 6.4
].
5.2.2.6 FCS_COP.1/Hash Cryptographic Operation (Hash Algorithm)
FCS_COP.1.1/Hash The TSF shall perform cryptographic hashing services in accordance
with a specified cryptographic algorithm [SHA-1, SHA-256, SHA-384, SHA-512] and
cryptographic key sizes [assignment: cryptographic key sizes] and message digest sizes
[160, 256, 384, 512] bits that meet the following: ISO/IEC 10118-3:2004.
Cisco MDS 9000 Series Switches Security Target
33
5.2.2.7 FCS_COP.1/KeyedHash Cryptographic Operation (Keyed Hash Algorithm)
FCS_COP.1.1/KeyedHash The TSF shall perform keyed-hash message authentication in
accordance with a specified cryptographic algorithm [HMAC-SHA-1, HMAC-SHA-256,
HMAC-SHA-384, HMAC-SHA-512] and cryptographic key sizes [160-bit, 256-bit, 384-bit,
512-bit] and message digest sizes [160, 256, 384, 512] bits that meet the following:
ISO/IEC 9797-2:2011, Section 7 “MAC Algorithm 2”.
5.2.2.8 FCS_RBG_EXT.1 Random Bit Generation
FCS_RBG_EXT.1.1 The TSF shall perform all deterministic random bit generation
services in accordance with ISO/IEC 18031:2011 using [HMAC_DRBG (any)].
FCS_RBG_EXT.1.2 The deterministic RBG shall be seeded by at least one entropy source
that accumulates entropy from [[1]: platform-based noise source] with minimum of
[256 bits] of entropy at least equal to the greatest security strength, according to
ISO/IEC 18031:2011 Table C.1 “Security Strength Table for Hash Functions”, of the keys
and hashes that it will generate.
5.2.2.9 FCS_SSHS_EXT.1 SSH Server Protocol
FCS_SSHS_EXT.1.1 The TSF shall implement the SSH protocol that complies with RFCs
4251, 4252, 4253, 4254, [4344, 5656, 6668, 8308 section 3.1, 8332].
FCS_SSHS_EXT.1.2 The TSF shall ensure that the SSH protocol implementation supports
the following user authentication methods as described in RFC 4252: public key-based,
[password-based].
FCS_SSHS_EXT.1.3 The TSF shall ensure that, as described in RFC 4253, packets greater
than [262,149] bytes in an SSH transport connection are dropped.
FCS_SSHS_EXT.1.4 The TSF shall ensure that the SSH transport implementation uses
the following encryption algorithms and rejects all other encryption algorithms:
[aes128-ctr, aes256-ctr, aes128-gcm@openssh.com, aes256-gcm@openssh.com].
FCS_SSHS_EXT.1.5 The TSF shall ensure that the SSH public-key based authentication
implementation uses [rsa-sha2-256, ecdsa-sha2-nistp256, ecdsa-sha2-nistp384, ecdsa-
sha2-nistp521] as its public key algorithm(s) and rejects all other public key algorithms.
FCS_SSHS_EXT.1.6 The TSF shall ensure that the SSH transport implementation uses
[hmac-sha2-256, hmac-sha2-512, implicit] as its MAC algorithm(s) and rejects all other
MAC algorithm(s).
FCS_SSHS_EXT.1.7 The TSF shall ensure that [ecdh-sha2-nistp256] and [ecdh-sha2-
nistp384, ecdh-sha2-nistp521] are the only allowed key exchange methods used for the
SSH protocol.
FCS_SSHS_EXT.1.8 The TSF shall ensure that within SSH connections, the same session
keys are used for a threshold of no longer than one hour, and each encryption key is
used to protect no more than one gigabyte of transmitted data. After either of the
thresholds are reached, a rekey needs to be performed.
Cisco MDS 9000 Series Switches Security Target
34
5.2.2.10 FCS_TLSC_EXT TLS Client Protocol
FCS_TLSC_EXT.1.1 The TSF shall implement [TLS 1.2 (RFC 5246)] and reject all other
TLS and SSL versions. The TLS implementation will support the following ciphersuites:
[
TLS_RSA_WITH_AES_128_CBC_SHA as defined in RFC 3268,
TLS_RSA_WITH_AES_256_CBC_SHA as defined in RFC 3268,
TLS_DHE_RSA_WITH_AES_128_CBC_SHA as defined in RFC 3268,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA as defined in RFC 4492,
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA as defined in RFC 4492,
TLS_RSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5246,
TLS_RSA_WITH_AES_256_CBC_ SHA256 as defined in RFC 5246,
TLS_RSA_WITH_AES_128_GCM_SHA256 as defined in RFC 5288,
TLS_RSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5288,
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5246,
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 as defined in RFC 5246,
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 as defined in RFC 5288,
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5288,
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5289,
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 as defined in RFC 5289,
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 as defined in RFC 5289,
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5289,
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 as defined in RFC 5289,
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5289,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5289,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 as defined in RFC 5289
]
and no other ciphersuites.
FCS_TLSC_EXT.1.2 The TSF shall verify that the presented identifier matches [the
reference identifier per RFC 6125 section 6, IPv4 address in SAN].
FCS_TLSC_EXT.1.3 When establishing a trusted channel, by default the TSF shall not
establish a trusted channel if the server certificate is invalid. The TSF shall also [
• Not implement any administrator override mechanism
].
FCS_TLSC_EXT.1.4 The TSF shall [present the Supported Elliptic Curves Extension with
the following NIST curves: [secp256r1, secp384r1, secp521r1] and no other
curves/groups] in the Client Hello.
Cisco MDS 9000 Series Switches Security Target
35
5.2.3 Identification and authentication (FIA)
5.2.3.1 FIA_AFL.1 Authentication Failure Handling
FIA_AFL.1.1 The TSF shall detect when an Administrator configurable positive integer
within [1-65535] unsuccessful authentication attempts occur related to Administrators
attempting to authenticate remotely using a password.
FIA_AFL.1.2 When the defined number of unsuccessful authentication attempts has
been met, the TSF shall [prevent the offending Administrator from successfully
establishing a remote session using any authentication method that involves a
password until [unblocking action] is taken by an Administrator, prevent the offending
Administrator from successfully establishing a remote session using any authentication
method that involves a password until an Administrator defined time period has
elapsed].
5.2.3.2 FIA_PMG_EXT.1 Password Management
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: [“@”, “$”,
“%”, “^”, “&”, “*”, “(“, “)”, [“+”, “=”, “_”, “-“, “\”, “.”]];
2. Minimum password length shall be configurable to between [8] and [127]
characters.
5.2.3.3 FIA_UIA_EXT.1 User Identification and Authentication
FIA_UIA_EXT.1.1 The TSF shall allow the following actions prior to requiring the non-
TOE entity to initiate the identification and authentication process:
• Display the warning banner in accordance with FTA_TAB.1;
• [no other actions.]
FIA_UIA_EXT.1.2 The TSF shall require each administrative user to be successfully
identified and authenticated before allowing any other TSF-mediated action on behalf of
that administrative user.
5.2.3.4 FIA_UAU_EXT.2 Password-based Authentication Mechanism
FIA_UAU_EXT.2.1 The TSF shall provide a local [password-based, SSH public key-
based] authentication mechanism to perform local administrative user authentication.
5.2.3.5 FIA_UAU.7 Protected Authentication Feedback
FIA_UAU.7.1 The TSF shall provide only obscured feedback to the administrative user
while the authentication is in progress at the local console.
Cisco MDS 9000 Series Switches Security Target
36
5.2.3.6 FIA_X509_EXT.1/Rev X.509 Certificate Validation
FIA_X509_EXT.1.1 The TSF shall validate certificates in accordance with the following
rules:
• RFC 5280 certificate validation and certificate path validation supporting a
minimum path length of three certificates.
• The certificate path must terminate with a trusted CA certificate designated as a
trust anchor.
• The TSF shall validate a certification path by ensuring that all CA certificates in
the certification path contain the basicConstraints extension with the CA flag set
to TRUE.
• The TSF shall validate the revocation status of the certificate using [the Online
Certificate Status Protocol (OCSP) as specified in RFC 6960].
• The TSF shall validate the extendedKeyUsage field according to the following
rules:
o Certificates used for trusted updates and executable code integrity
verification shall have the Code Signing purpose (id-kp 3 with OID
1.3.6.1.5.5.7.3.3) in the extendedKeyUsage field.
o Server certificates presented for TLS shall have the Server Authentication
purpose (id-kp 1 with OID 1.3.6.1.5.5.7.3.1) in the extendedKeyUsage
field.
o Client certificates presented for TLS shall have the Client Authentication
purpose (id-kp 2 with OID 1.3.6.1.5.5.7.3.2) in the extendedKeyUsage
field.
o OCSP certificates presented for OCSP responses shall have the OCSP
Signing purpose (id-kp 9 with OID 1.3.6.1.5.5.7.3.9) in the
extendedKeyUsage field.
FIA_X509_EXT.1.2/Rev The TSF shall only treat a certificate as a CA certificate if the
basicConstraints extension is present and the CA flag is set to TRUE.
5.2.3.7 FIA_X509_EXT.2 X.509 Certificate Authentication
FIA_X509_EXT.2.1 The TSF shall use X.509v3 certificates as defined by RFC 5280 to
support authentication for [TLS], and [no additional uses].
FIA_X509_EXT.2.2 When the TSF cannot establish a connection to determine the
validity of a certificate, the TSF shall [not accept the certificate].
Cisco MDS 9000 Series Switches Security Target
37
5.2.4 Security management (FMT)
5.2.4.1 FMT_MOF.1/ManualUpdate Management of security functions behaviour
FMT_MOF.1.1/ManualUpdate The TSF shall restrict the ability to enable the functions
to perform manual update to Security Administrators .
5.2.4.2 FMT_MTD.1 CoreData Management of TSF Data
FMT_MTD.1.1/CoreData The TSF shall restrict the ability to manage the TSF data to
the Security Administrators.
5.2.4.3 FMT_MTD.1/CryptoKeys Management of TSF data
FMT_MTD.1.1/CryptoKeys The TSF shall restrict the ability to manage the
cryptographic keys to Security Administrators.
5.2.4.4 FMT_SMF.1 Specification of Management Functions
FMT_SMF.1.1 The TSF shall be capable of performing the following management
functions:
• Ability to administer the TOE locally and remotely;
• Ability to configure the access banner;
• Ability to configure the session inactivity time before session termination or
locking;
• Ability to update the TOE, and to verify the updates using [digital signature]
capability prior to installing those updates;
• Ability to configure the authentication failure parameters for FIA_AFL.1;
• [
o Ability to configure audit behaviour (e.g. changes to storage
locations for audit; changes to behaviour when local audit storage space
is full);
o Ability to modify the behaviour of the transmission of audit data to
an external IT entity;
o Ability to manage the cryptographic keys;
o Ability to configure the cryptographic functionality;
o Ability to configure thresholds for SSH rekeying;
o Ability to re-enable an Administrator account;
o Ability to set the time which is used for time-stamps;
o Ability to manage the TOE's trust store and designate X509.v3
certificates as trust anchors;
o Ability to import X.509v3 certificates to the TOE's trust store;
o Ability to manage the trusted public keys database;
].
Cisco MDS 9000 Series Switches Security Target
38
5.2.4.5 FMT_SMR.2 Restrictions on Security Roles
FMT_SMR.2.1 The TSF shall maintain the roles:
• Security Administrator.
FMT_SMR.2.2 The TSF shall be able to associate users with roles.
FMT_SMR.2.3 The TSF shall ensure that the conditions:
• The Security Administrator role shall be able to administer the TOE locally;
• The Security Administrator role shall be able to administer the TOE
remotely
are satisfied.
5.2.5 Protection of the TSF (FPT)
5.2.5.1 FPT_SKP_EXT.1 Extended: Protection of TSF Data (for reading of all
symmetric keys)
FPT_SKP_EXT.1.1 The TSF shall prevent reading of all pre-shared keys, symmetric keys,
and private keys.
5.2.5.2 FPT_APW_EXT.1 Protection of Administrator Passwords
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.5.3 FPT_STM_EXT.1 Reliable time stamps
FPT_STM_EXT.1.1 The TSF shall be able to provide reliable time stamps for its own use.
FPT_STM_EXT.1.2 The TSF shall [allow the Security Administrator to set the time].
5.2.5.4 FPT_TST_EXT.1: TSF Testing (Extended)
FPT_TST_EXT.1.1 The TSF shall run a suite of the following self-tests [during
initial start-up (on power on)] to demonstrate the correct operation of the TSF: [
• AES Known Answer Test
• HMAC Known Answer Test
• RNG/DRBG Known Answer Test
• SHA-1/SHA-256/SHA-384/SHA-512 Known Answer Test
• RSA Signature Known Answer Test (both signature/verification)
• Software Integrity Test
].
Cisco MDS 9000 Series Switches Security Target
39
5.2.5.5 FPT_TUD_EXT.1 Trusted Update
FPT_TUD_EXT.1.1 The TSF shall provide Security Administrators the ability to query the
currently executing version of the TOE firmware/software and [the most recently
installed version of the TOE firmware/software].
FPT_TUD_EXT.1.2 The TSF shall provide Security Administrators the ability to manually
initiate updates to TOE firmware/software and [no other update mechanism].
FPT_TUD_EXT.1.3 The TSF shall provide a means to authenticate firmware/software
updates to the TOE using a [digital signature] prior to installing those updates.
5.2.6 TOE Access (FTA)
5.2.6.1 FTA_SSL_EXT.1 TSF-initiated Session Locking
FTA_SSL_EXT.1.1 The TSF shall, for local interactive sessions, [terminate the session]
after a Security Administrator-specified time period of inactivity.
5.2.6.2 FTA_SSL.3 TSF-initiated Termination (Refinement)
FTA_SSL.3.1: The TSF shall terminate a remote interactive session after a Security
Administrator-configurable time interval of session inactivity.
5.2.6.3 FTA_SSL.4 User-initiated Termination (Refinement)
FTA_SSL.4.1 The TSF shall allow Administrator-initiated termination of the
Administrator’s own interactive session.
5.2.6.4 FTA_TAB.1 Default TOE Access Banners (Refinement)
FTA_TAB.1.1 Before establishing an administrative user session the TSF shall display
a Security Administrator-specified advisory notice and consent warning message
regarding use of the TOE.
5.2.7 Trusted Path/Channels (FTP)
5.2.7.1 FTP_ITC.1 Inter-TSF trusted channel
FTP_ITC.1.1 The TSF shall be capable of using [TLS] to provide a trusted
communication channel between itself and authorized IT entities supporting the
following capabilities: audit server, [[no other capabilities]] that is logically distinct
from other communication channels and provides assured identification of its end
points and protection of the channel data from disclosure and detection of modification
of the channel data.
FTP_ITC.1.2 The TSF shall permit the TSF or the authorized IT entities to initiate
communication via the trusted channel.
FTP_ ITC.1.3 The TSF shall initiate communication via the trusted channel for
[communications with the following:
Cisco MDS 9000 Series Switches Security Target
40
• Syslog server over TLS
].
5.2.7.2 FTP_TRP.1/Admin Trusted Path (Refinement)
FTP_TRP.1.1/Admin The TSF shall be capable of using [SSH] to provide a
communication path between itself and authorized remote Administrators that is
logically distinct from other communication paths and provides assured identification
of its end points and protection of the communicated data from disclosure and
provides detection of modification of the channel data.
FTP_TRP.1.2/Admin The TSF shall permit remote Administrators to initiate
communication via the trusted path.
FTP_TRP.1.3/Admin The TSF shall require the use of the trusted path for initial
Administrator authentication and all remote administration actions.
5.3 TOE SFR Dependencies Rationale
The NDcPPv2e contains all the requirements claimed in this Security Target. As such
the dependencies are not applicable since the PP itself has been approved.
5.4 Security Assurance Requirements
5.4.1 SAR Requirements
The TOE assurance requirements for this ST are taken directly from the NDcPPv2.2e
which are derived from Common Criteria Version 3.1, Revision 5. The assurance
requirements are summarized in the table below.
Table 16 Assurance Measures
Assurance Class Assurance Components
Security Target (ASE) Conformance claims (ASE_CCL.1)
Extended components definition (ASE_ECD.1)
ST introduction (ASE_INT.1)
Security objectives for the operational environment (ASE_OBJ.1)
Stated security requirements (ASE_REQ.1)
Security Problem Definition (ASE_SPD.1)
TOE summary specification (ASE_TSS.1)
Development (ADV) Basic functional specification (ADV_FSP.1)
Guidance Documents (AGD) Operational user guidance (AGD_OPE.1)
Preparative procedures (AGD_PRE.1)
Life Cycle Support (ALC) Labelling of the TOE (ALC_CMC.1)
TOE CM coverage (ALC_CMS.1)
Tests (ATE) Independent testing – conformance (ATE_IND.1)
Vulnerability Assessment (AVA) Vulnerability survey (AVA_VAN.1)
Cisco MDS 9000 Series Switches Security Target
41
5.4.2 Security Assurance Requirements Rationale
The Security Assurance Requirements (SARs) in this Security Target represent the SARs
identified in the NDcPPv2e. As such, the NDcPP SAR rationale is deemed acceptable
since the PP itself has been validated.
5.5 Assurance Measures
The TOE satisfies the identified assurance requirements. This section identifies the
Assurance Measures applied by Cisco to satisfy the assurance requirements. The table
below lists the details.
Table 17 Applied Assurance Measures
Component How requirement will be met
ASE_CCL.1 /
ASE_ECD.1 /
ASE_INT.1 /
ASE_OBJ.1 /
ASE_REQ.1 /
ASE_SPD.1 /
ASE_TSS.1
Section 2 of this ST includes the TOE and ST conformance claim to CC Version 3.1,
Revision 5, dated: April 2017, CC Part 2 extended and CC Part 3 conformant and
NDcPPv2.2e, and the rationale of how the TOE provides all of the functionality at a level
of security commensurate with that identified in NDcPPv2.2e. Section 2 also includes the
consistency rationale for the TOE Security Problem Definition and the Security
Requirements to include the extended components definition.
Section 1 of this ST provides the introduction of the ST, the TOE and its references, an
overview of the TOE, the TOE product type, and the description of the TOE to include the
evaluated configuration and the physical and logical cope of the TOE.
Section 5 of this ST identifies the security functional requirements, the assurance
requirements and how the assurance requirements are met. Section 6 provides the
rationale of how the Security Functional Requirements are met by the TOE.
ADV_FSP.1 There are no specific assurance activities associated with ADV_FSP.1. The requirements
on the content of the functional specification information are implicitly assessed by
virtue of the other assurance activities being performed. The functional specification is
comprised of the information contained in the AGD_OPE and AGD_PRE documentation,
coupled with the information provided in the TSS of the ST. The assurance activities in
the functional requirements point to evidence that should exist in the documentation and
TSS section; since these are directly associated with the SFRs, the tracing in element
ADV_FSP.1.2D is implicitly already done and no additional documentation is necessary.
AGD_OPE.1 The Administrative Guide provides the descriptions of the processes and procedures of
how the administrative users of the TOE can securely administer the TOE using the
interfaces that provide the features and functions detailed in the guidance.
AGD_PRE.1 The Installation Guide describes the installation, generation, and startup procedures so
that the users of the TOE can put the components of the TOE in the evaluated
configuration.
ALC_CMC.1 The AGD and ST implicitly meet this assurance requirement. The evaluator shall check
the ST to ensure that it contains an identifier (such as a product name/version number)
that specifically identifies the version that meets the requirements of the ST. Further, the
evaluator shall check the AGD guidance and TOE samples received for testing to ensure
that the version number is consistent with that in the ST.
ALC_CMS.1
ATE_IND.1 Cisco will provide the TOE for testing.
AVA_VAN.1 Cisco will provide the TOE for testing.
Cisco MDS 9000 Series Switches Security Target
42
Cisco MDS 9000 Series Switches Security Target
43
6 TOE Summary Specification
6.1 TOE Security Functional Requirement Measures
This chapter identifies and describes how the Security Functional Requirements
identified above are met by the TOE.
Table 18 How TOE SFRs are Met
TOE SFRs How the SFR is Met
FAU_GEN.1 The TOE generates an audit record that is stored internally within the
TOE whenever an audited event occurs. The types of events that cause
audit records to be generated include, cryptography related events,
events related to the enforcement of information flow policies,
identification and authentication related events, and administrative
events (the specific events and the contents of each audit record are listed
in Table 16. Each of the events is specified in the syslog which is stored
internal to the TOE in enough detail to identify the user for which the
event is associated, when the event occurred, where the event occurred,
the outcome of the event, and the type of event that occurred.
Each time an administrative user logs into or off the MDS 9000 Series
switch, an audit record is generated. The audit record contains the Day of
Week, the Date, the Action, the User ID, and terminal information (where
applicable) of the user logging into the MDS 9000 Series switch.
Whenever an administrative user makes a configuration change to the
MDS 9000 Series switch, an audit record is generated on a per-command
basis. Likewise, the audit record contains the Day of Week, the Date, the
Action, the User ID, the outcome of the event, and terminal information
(where applicable) of the user making the configuration change.
In addition to information such as this for the administrative task of
generating/import of, changing, or deleting of cryptographic keys a
unique key name is included in the audit record.
Auditing cannot be disabled except by shutting down the TOE and is
automatically available upon the startup of the TOE. The TOE startup and
shutdown is captured in the audit trail and servers as the audit records
for these events.
Example audit events are included below:
Sun Mar 31 02:50:39
2024:type=update:id=10.1.2.3@pts/0:user=admin:cmd=configure
terminal ; username user1 password 0 ****
**** (SUCCESS)
In the above log event a date and timestamp is displayed as well as an
event description “cmd=configure terminal”. The subject identity where a
command is directly run by a user is displayed “user=admin.” The
outcome of the command is displayed: “SUCCESS”
To configure the TOE to send audit records to a syslog server, the
“logging server name [severity-level] [port number ] [ secure [trustpoint
client-identity name]] [facility facility-name]” command is used. A
maximum of three syslog servers can be configured. Refer to the
Cisco MDS 9000 Series Switches Security Target
44
TOE SFRs How the SFR is Met
Common Criteria Operational User Guidance and Preparative Procedures
for command description and usage information. The audit records are
transmitted using TLS to the syslog server. If the communications to the
syslog server is lost, the TOE generates an audit record and all permit
traffic is denied until the communications is re-established.
FAU_GEN.2 The TOE shall ensure that each auditable event is associated with the user
that triggered the event and as a result they are traceable to a specific
user. For example a human user, user identity, or related session ID
would be included in the audit record. When the event is related to a
remote user or entity, the IP address, MAC address, host name, or other
configured identification included in the message. A sample audit record
is below:
Sun Mar 31 05:49:59
2024:type=update:id=10.1.2.3@pts/0:user=admin:cmd=configure
terminal ; no username user1 (SUCCESS)
FAU_STG_EXT.1 Access to the audit records stored on the TOE is only through a TSF
Mediated interface. Only users explicitly authorized to access the audit
records are given access to the audit records. There is no interface which
may be used to perform audit record modification. In addition, logs can
only be cleared by an authorized administrator.
The TOE is configured to export syslog records to a specified, external
syslog server. Once the configuration is complete, the audit records are
automatically sent to the external syslog server at the same time as they
are written to the logging buffer. The TOE protects communications with
an external syslog server via TLS. If the TLS connection fails, the TOE will
store audit records on the TOE when it discovers it can no longer
communicate with its configured syslog server. When the connection is
restored, the TOE will transmit the buffer contents to the syslog server.
For the MDS 9000 Series, logs are written to NVRAM. By default, a
maximum of 100 system messages of severity 0, 1, or 2 (emergency, alert,
or critical) are logged to NVRAM (#show logging nvram).
Log messages are not saved across system reboots.
The logging logfile global configuration command enables copying of
system messages to an internal log file in flash, allows for setting the level
of logging (0-7) and optionally the size of the file can be set in bytes as
well as the name of the log file.
The severity levels are:
0 – Emergency (System unusable)
1 – Alert (Immediate action required)
2 – Critical (Critical condition)
3 – Error (Error condition)
4 – Warning (Warning Condition)
5 – Notification (Normal but significant condition)
6 – Informational (informational messages only)
7 – Debugging (Appears during debugging only)
Example
# logging logfile my_log 6
Cisco MDS 9000 Series Switches Security Target
45
TOE SFRs How the SFR is Met
The logging to NVRAM and flash provide persistent logging data after a
system reload. By default, the logs are circular and once the log files reach
capacity of the flash storage, they are overwritten. With NX-OS, there is
logging of event-histories that run in the background by default. The
event-history log size is configurable.
FCS_CKM.1
FCS_CKM.2
The following table describes the key generation algorithms the TOE
implements to generate asymmetric keys used for device authentication:
Scheme Standard Key
Size/
NIST
Curve
SFR Service
RSA FIPS PUB
186-4
2048 FCS_SSHS_EXT.1 SSH Remote
Administration
ECC FIPS PUB
186-4
P-256
P-384
P-521
FCS_SSHS_EXT.1 SSH Remote
Administration
The following table shows the key generation algorithms implemented by
the TOE to generate asymmetric keys used for key establishment:
Scheme Standard Key
Size/
NIST
Curve
SFR Service
RSA FIPS PUB
186-4
2048 FCS_TLSC_EXT.1 Transmit audit
data to an
external syslog
server
ECC FIPS PUB
186-4
P-256
P-384
P-521
FCS_SSHS_EXT.1 SSH Remote
Administration
FCS_TLSC_EXT.1 Transmit audit
data to an
external syslog
server
FFC FIPS PUB
186-4
3072 FCS_TLSC_EXT.1 Transmit audit
data to an
external syslog
server
The following table shows the methods that the TOE implements for key
establishment:
Scheme Standard Key
Size/
NIST
Curve
SFR Service
RSA FIPS PUB
186-4
2048 FCS_TLSC_EXT.1 Transmit audit
data to an
external syslog
server
ECC FIPS PUB
186-4
P-256
P-384
P-521
FCS_SSHS_EXT.1 SSH Remote
Administration
FCS_TLSC_EXT.1 Transmit audit
data to an
Cisco MDS 9000 Series Switches Security Target
46
TOE SFRs How the SFR is Met
external syslog
server
FFC FIPS PUB
186-4
3072 FCS_TLSC_EXT.1 Transmit audit
data to an
external syslog
server
The TOE implements RSA key establishment schemes that are
conformant to NIST SP 800-56B. The TOE complies with section 6 and all
subsections regarding RSA key pair generation and key establishment in
the NIST SP 800-56B. The TOE implements Elliptic Curve Diffie-Hellman
(ECDH) (ecdh-sha2-nistp256, ecdh-sha2-nistp384, ecdh-sha2-nistp521)
key establishment schemes in SSH. The ECDH key generation meets the
NIST FIPS PUB 186-4 Appendix B.1. ECC schemes are used with P-256, P-
384, and P-521.
The TOE also supports FFC schemes for key establishment with a size of
3072 bits.
The key pair generation portions of "The RSA Validation System" for FIPS
186-4 were used as a guide in testing the FCS_CKM.1 during the FIPS
validation.
The TOE employs RSA-based key establishment used in cryptographic
operations with support for 2048-bit keys.
For details on each protocol, see the related SFR.
FCS_CKM.4 The TOE meets all requirements specified in FIPS 140-2 for destruction of
keys and Critical Security Parameters (CSPs) in that none of the
symmetric keys, pre-shared keys, or private keys are stored in plaintext.
Through the implementation of cryptographic module, the TOE zeroizes
all of the cryptographic keys used within the TOE after the key is no
longer of use to the TOE. The key and CSP zeroization capabilities of the
TOE have been verified as part of the TOE’s FIPS 140-2 validation. See
Table 6 and Table 19 for more information.
FCS_COP.1/DataEncryption The TOE provides symmetric encryption and decryption capabilities
using AES in CBC, CTR and GCM mode (128, 256 bits) as described in ISO
18033-3, ISO 10116, ISO 19772. AES is implemented in the following
protocols: SSHv2 and TLS.
Through the implementation of the FIPS validated cryptographic module,
the TOE provides AES encryption and decryption in support of SSHv2,
and TLS for secure communications. Management of the cryptographic
algorithms is provided through the CLI with auditing of those commands.
FCS_COP.1/SigGen The TOE provides cryptographic signature services using the following:
• RSA Digital Signature Algorithm with key size of 2048 as
specified in FIPS PUB 186-4, “Digital Signature Standard”.
• Elliptic Curve Digital Signature Algorithm and cryptographic key
sizes 256 bits, 384 bits, 521 bits.
Cisco MDS 9000 Series Switches Security Target
47
TOE SFRs How the SFR is Met
Through the implementation of the FIPS validated cryptographic module,
the TOE provides cryptographic signatures in support of SSHv2 and TLS
for secure communications. Management of the cryptographic algorithms
is provided through the CLI with auditing of those commands. The TOE
provides the RSA option in support of SSHv2 and TLS key establishment.
RSA (2048-bit) is used in the establishment of SSHv2 key establishment.
For SSHv2, RSA and ECDSA host keys are supported.
In addition, the TOE provides cryptographic signature verification of RSA
and X509 certificates used for TLS authentication by the external syslog
server.
FCS_COP.1/Hash The TOE provides cryptographic hashing services using SHA-1, SHA-256,
SHA-384, and SHA-512 as specified in ISO/IEC 10118-3:2004.
Through the implementation of the FIPS validated cryptographic module,
the TOE provides Secure Hash Standard (SHS) hashing in support of TLS,
for secure communications. Management of the cryptographic algorithms
is provided through the CLI with auditing of those commands.
FCS_COP.1/KeyedHash The TOE provides keyed-hashing message authentication services using
HMAC-SHA-1 that operates on 160-bit blocks, HMAC-SHA-256 that
operates on 512-bit blocks, HMAC-SHA384 that operates on 1024-bit
blocks, and HMAC-SHA-512 that operates on 1024-bit blocks of data with
key sizes and message digest sizes of 160, 256, 384, and 512 bits,
respectively as specified in ISO/IEC 9797-2:2011, Section 7 “MAC
Algorithm 2”.
Through the implementation of the FIPS validated cryptographic module,
the TOE provides SHS hashing and HMAC message authentication in
support of SSHv2, and TLSv1.2 for secure communications. Management
of the cryptographic algorithms is provided through the CLI with auditing
of those commands.
SHS hashing and HMAC message authentication (SHA-1) is used in the
establishment of TLS/HTTPS, and SSHv2 sessions.
FCS_SSHS_EXT.1 The TOE implements SSHv2 (telnet is disabled in the evaluated
configuration). SSHv2 is implemented according to the following RFCs:
4251, 4252, 4253, 4254, 4344, 5656, 6668, 8308 section 3.1, and 8332.
The TOE supports both public key-based and password-based
authentication. The TOE’s implementation of SSHv2 supports public key
algorithm rsa-sha2-256, ecdsa-sha2-nistp256, ecdsa-sha2-nistp384,
ecdsa-sha2-nistp521 for public key-based authentication for
administrative users. For public-key authentication, the TOE ensures and
verifies that the SSH client's presented public key matches one that is
stored within the TOE's SSH server's authorized keys file. Remote CLI
SSHv2 sessions are limited to an administrator configurable session
timeout period and used for a threshold of no longer than one hour, and
no more than one gigabyte of transmitted data. After either of the
thresholds are reached a rekey needs to be performed.
RSA or ECDSA SSH host keys are generated by using the “ssh key”
command.
SSHv2 connections will be dropped if the TOE receives a packet larger
than 262,149 bytes. Large packets are detected by the SSH
Cisco MDS 9000 Series Switches Security Target
48
TOE SFRs How the SFR is Met
implementation and dropped internal to the SSH process. The key
exchange methods used by the TOE is a configurable option but rsa-sha2-
256, ecdh-sha2-nistp256, ecdh-sha2-nistp384, and ecdh-sha2-nistp521
are the only allowed methods within the evaluated configuration. Any
session where the SSH client offers only non-compliant algorithms or key
sizes per the NDcPPv2.2e will be rejected by the SSH server. SSH sessions
can only be established when compliant algorithms and key sizes can be
negotiated.
The TOE implementation of SSHv2 supports the following:
• public key algorithms for authentication as described in RFC
4252
• password-based authentication for administrative users
accessing the TOE's CLI through SSHv2.
• encryption algorithms aes128-ctr, aes256-ctr, aes128-
gcm@openssh.com, and aes256-gcm@openssh.com to ensure
confidentiality of the session.
• hashing algorithms hmac-sha2-256 and hmac-sha2-512 to
ensure the integrity of the session.
• SSH transport implementation public key algorithms: rsa-sha2-
256, ecdsa-sha2-nistp256, ecdsa-sha2-nistp384, and ecdsa-sha2-
nistp521.The same algorithms are used for both client and host
public key authentication.
• Key exchange algorithms: ecdh-sha2-nistp256, ecdh-sha2-
nistp384, and ecdh-sha2-nistp521
FCS_RBG_EXT.1 The TOE implements an HMAC_DRBG (as defined in section 10.1.2 of NIST
SP 800-90A (6), using HMAC w/SHA-256) from CiscoSSL’s FIPS Object
Module (FOM) to generate its cryptographic keys. The deterministic RBG
is seeded with a minimum of 256 bits of entropy, which is at least equal to
the greatest security strength of the keys and hashes that it will generate.
The TOE uses CPU Jitter Entropy (JENT), a platform-based entropy
source, to provide entropy to seed its DRBGs. JENT is based on the
assumption that a small set of instructions (written in C), when executed
repeatedly, will take a slightly different amount of time to execute each
time. The time variance is due to a multitude of factors, including:
• CPU instruction pipelines
• The fact that the CPU clock cycle is different than the memory bus
clock speed
• CPU frequency scaling (which alters the instructions’ processing
speed)
• CPU power management, which may disable certain CPU features
Cisco MDS 9000 Series Switches Security Target
49
TOE SFRs How the SFR is Met
• Instruction and data caches with their varying information
• CPU topology and caches used jointly by multiple CPUs
• Branch prediction units
• TLB caches
• Processes being moved from one CPU to another by the scheduler
• HW interrupts
• Memory segments whose access times vary due to their physical
distance from the CPU
The boundary of the entropy source is the entire TOE platform. An
adversary on the outside is not able to affect the entropy rate in any
determinable way, because of the number of sources, and the fact that the
only one of the sources (allocated packet buffer) is populated with data
that came from outside of the system.
FCS_TLSC_EXT.1 The supported ciphersuites including the following:
• TLS_RSA_WITH_AES_128_CBC_SHA as defined in RFC 3268
• TLS_RSA_WITH_AES_256_CBC_SHA as defined in RFC 3268
• TLS_DHE_RSA_WITH_AES_128_CBC_SHA as defined in RFC
3268
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA as defined in RFC
4492
• TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA as defined in
RFC 4492,
• TLS_RSA_WITH_AES_128_CBC_SHA256 as defined in RFC
5246
• TLS_RSA_WITH_AES_256_CBC_ SHA256 as defined in RFC
5246
• TLS_RSA_WITH_AES_128_GCM_SHA256 as defined in RFC
5288
• TLS_RSA_WITH_AES_256_GCM_SHA384 as defined in RFC
5288
• TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 as defined in
RFC 5246
• TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 as defined in
RFC 5246
• TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 as defined in
RFC 5288
• TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 as defined in
RFC 5288
• TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 as defined
in RFC 5289
• TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 as defined
in RFC 5289
Cisco MDS 9000 Series Switches Security Target
50
TOE SFRs How the SFR is Met
• TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 as defined
in RFC 5289,
• TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 as defined
in RFC 5289,
• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 as defined in
RFC 5289
• TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 as defined in
RFC 5289
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 as defined in
RFC 5289,
• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 as defined in
RFC 5289
The following NIST curves are supported by default on the TOE:
secp256r1, secp384r1, and secp521r1. No administrator configuration is
required in order to use these curves.
When establishing a TLS connection, the TOE supports reference
identifiers of type DNS-ID and IP address and will seek a match to the
DNS domain name or IP address respectively in the subjectAltName
extension. If the TOE determines there is a mismatch in the presented
identifier, it will not establish the TLS trusted channel connection. The
TOE does support the use of wildcards within certificates, but does not
support certificate pinning.
Trusted CA certificates that are uploaded to the TOE must include the
basicConstraints extension with the CA flag set to True to be validated by
the TOE.
Client certificates must include the ‘Client Auth’ purpose in the
extendedKeyUsage field, and server certificates must include the ‘Server
Auth’ purpose to be validated by the TOE. The OCSP Responder must
include the ‘OCSP Signing’ purpose.
The TOE performs the following steps when verifying peer certificates:
• Verifies that the peer certificate is issued by one of the locally
trusted CAs.
• Verifies that the peer certificate is valid (not expired) with
respect to current time.
• Verifies that the peer certificate is not yet revoked by the issuing
CA.
OCSP is used for certificate revocation checking by the TOE to confirm
validity on the entire certificate chain. This occurs both during the initial
upload of trusted CA certificates and during the Server Hello for new
connections.
The TOE uses TLS for outbound syslog connections. Any session where
the server offers the following in the server hello: SSL 2.0, SSL 3.0, TLS 1.0
and TLS 1.1 will be rejected by the TOE.
FIA_AFL.1 The TOE enforces a timed lockout after an Administrator defined number
of unsuccessful password attempts is exceeded. TOE supports setting the
Cisco MDS 9000 Series Switches Security Target
51
TOE SFRs How the SFR is Met
limit to any number in the range from 1-65535 failed login attempts
within an admin-defined time period of 1-65535 seconds, and to lock the
account for an admin-defined number of period of 1-65535 seconds.
For example, an authorized administrator can be blocked from a range of
1 to 65535 seconds when 3 login attempts fail within a period of 60
seconds.
Additionally, a locked account can be unlocked by another authorized
administrator using the command:
clear aaa local user blocked {username username | all}
FIA_PMG_EXT.1 The TOE supports the configuration of passwords to be composed of any
combination of upper- and lower-case letters, numbers, and special
characters (that include: “@”, “$”, “%”, “^”, “&”, “*”, “(“,“)”,“+”, “=”, “_”, “-“,
“\”, and “.”. Minimum password length is settable by the Authorized
Administrator and can be configured for minimum password lengths of
15 characters.
FIA_UIA_EXT.1
FIA_UAU_EXT.2
The TOE requires all users to be successfully identified and authenticated
before allowing any TSF mediated actions to be performed.
Administrative access to the TOE is facilitated through the TOE’s Nexus
9000 Series CLI. The TOE mediates all administrative actions through the
CLI. Once a potential administrative user attempts to access the CLI of the
TOE through either a directly connected console or remotely through an
SSHv2 connection, the TOE prompts the user for a username and
password which must match what is stored by the TOE. SSHv2
connections also allow for public key authentication where the user
supplies a private key and it must match a public key stored by the TOE
Only after the administrative user presents the correct authentication
credentials will access to the TOE administrative functionality be granted.
No access is allowed to the administrative functionality of the TOE until
an administrator is successfully identified and authenticated.
Authentication may be provided by:
• Authentication against a local database.
FIA_UAU.7 When a user enters their password at the local console or via SSH, the
TOE does not echo any of the characters of the password or any
representation of the characters.
FIA_X509_EXT.1/Rev
FIA_X509_EXT.2
The TOE uses X.509v3 certificates as defined by RFC 5280 to support
authentication for TLS connections. The certificate validation checking
takes place during the TLS session setup.
The TOE uses trustpoints to map an identity certificate to a CA or CA
chain for authentication purposes to an external syslog server.
The TOE supports the following methods to obtain a certificate from a CA:
• Manual cut-and-paste - MDS displays the Certificate Request
Message via the CLI interface. This allows the administrator to
copy the certificate request and in a secure offline manner, send
Cisco MDS 9000 Series Switches Security Target
52
TOE SFRs How the SFR is Met
the request to a Certification Authority to be transformed into an
X.509v3 public-key certificate.
• Both the certificate request message and the certificates
themselves provide protection in that they are digitally signed. If
a certificate is modified in any way, it would be invalidated. The
digital signature verifications process would show that the
certificate had been tampered with when the hash value would
be invalid.
• The certificate chain establishes a sequence of trusted
certificates, from a peer certificate to the root CA certificate.
Within the PKI hierarchy, all enrolled peers can validate the
certificate of one another if the peers share a trusted root CA
certificate or a common subordinate CA. When a certificate chain
is received from a peer, the default processing of a certificate
chain path continues until the first trusted certificate is reached.
• The authorized administrator can also configure one or more
certificate fields together with their matching criteria to match.
Such as:
• alt-subject-name
• issuer-name
• name
• serial-number
• subject-name
To ensure all certificate validation requirements are met, the TOE must
leverage an RSA CA in its trustpoint. The use of ECDSA CA certificates in
the trustpoint is not allowed in the evaluated configuration.
The physical security of the TOE (A.PHYSICAL_PROTECTION) protects the
switch and the certificates from being tampered with or deleted. In
addition, the TOE identification and authentication security functions
protect an unauthorized user from gaining access to the TOE.
The use of CRL is configurable and may be used for certificate revocation.
OCSP is used for certificate revocation. The TOE will act accordingly
based on the Authority Info Access extension in the CA or Peer certificate.
Revocation checking is performed on the leaf and intermediate
certificate(s) when authenticating a certificate chain provided by the
remote peer. There are no functional differences if a full certificate chain
or only a leaf certificate is presented.
Checking is also done for the basicConstraints extension and the CA flag
to determine whether they are present and set to TRUE. The local
certificate that was imported must contain the basic constraints extension
with the CA flag set to true, the check also ensure that the key usage
extension is present, and the keyEncipherment bit or the keyAgreement
bit or both are set. If they are not, the certificate is not accepted.
If the connection to determine the certificate validity cannot be
established, the certificate is not accepted.
FMT_MOF.1/ManualUpdate
FMT_MTD.1/CoreData
FMT_MTD.1/CryptoKeys
Manual software updates can only be performed by the authorized
administrator through the CLI. These updates include software upgrades.
Cisco MDS 9000 Series Switches Security Target
53
TOE SFRs How the SFR is Met
Cisco NX-OS devices use role-based access control (RBAC). The MDS 9000
Series switch supports the following predefined roles:
• network-admin – This role is a super administrative role. This
role has read and write privileges for any configuration item on
the TOE.
• network-operator - This role has read access to the entire TOE.
• server-admin - Complete read access to the entire Cisco NX-OS
device and upgrade capability.
The TOE provides the ability for Authorized Administrators to access TOE
data, such as audit data, configuration data, security attributes, session
thresholds, cryptographic keys and updates. Each of the predefined and
administratively configured privilege roles are considered to be security
administrators in this ST but have different levels of privileges as noted
above.
This access takes the form of management activity that will create keys,
import keys, configuring the use of keys and destroy (zeroize) keys. The
keys that can be managed are associated with a CSR (see
FIA_X509_EXT.1/Rev in this table), x509v3 certificates, and SSH public
keys which can be imported and deleted for authentication purpose.
The Authorized Administrators can query the software version running
on the TOE and can initiate updates to (replacements of) software images.
When software updates are made available by Cisco, the Authorized
Administrators can obtain, verify the integrity of, and install those
updates.
In addition, the warning and access banner may also be displayed prior to
the identification and authentication of an Authorized Administrator. No
administrative functionality is available prior to administrative login.
FMT_SMF.1 The TOE provides all the capabilities necessary to securely manage the
TOE. The Authorized Administrators user can connect to the TOE using
the CLI to perform these functions via SSHv2 secured connection, a
terminal server, or at the local console. The console port is an
asynchronous serial port that allows you to connect to the device for
initial configuration through a standard RS-232 port with an RJ-45
connector. The TOE does not provide services other than displaying the
warning banner prior to authentication
The specific management capabilities available from the TOE include:
• Local and remote administration of the TOE
• The ability to manage the warning banner message content
which allows the Authorized Administrator the ability to define
warning banner text that is displayed prior to establishing a
session (note this applies to the interactive (human) users; e.g.
administrative users);
• The ability to update the NX-OS software. The validity of the
image is provided using digital signature prior to installing the
update;
Cisco MDS 9000 Series Switches Security Target
54
TOE SFRs How the SFR is Met
• The ability to manage the time limits of session inactivity which
allows the Authorized Administrator the ability to set and modify
the inactivity time threshold;
• The ability to manage termination of a local session due to
exceeding the threshold of authentication failure attempts. The
account is locked until the Authorized Administrator unlocks the
account;
• The ability to manage audit behavior and the audit logs which
allows the Authorized Administrator to view the audit logs and to
clear the audit logs;
• The ability to manage the cryptographic functionality which
allows the Authorized Administrator the ability to identify and
configure the algorithms used to provide protection of the data,
such as generating the RSA keys to enable SSHv2 and to
configure thresholds for SSH rekeying;
• The ability to manage the trusted public key database for SSH
user public key authentication.
• The ability to configure and set the time clock;
• The ability to manage the TOE’s trust store and designate
X.509v3 certificates as trust anchors;
• The ability to import X.509v3 certificates to the TOE’s trust store.
FMT_SMR.2 The TOE platform maintains both privileged and semi-privileged
administrator roles. The terms “Authorized Administrator” and "Security
Administrator" are used interchangeable in this ST to refer to any user
that has been assigned to a privilege level that is permitted to perform the
relevant action; therefore, has the appropriate privileges to perform the
requested functions. The assigned role determines the functions the user
can perform; hence the authorized administrator with the appropriate
privileges.
The TOE supports both local administration via a directly connected
console and remote authentication via SSH.
FPT_SKP_EXT.1 The TOE stores all private keys in a secure directory that is not readily
accessible to administrators. All pre-shared and symmetric keys are
stored in encrypted form using AES encryption to additionally obscure
access. This functionality is configured on the TOE using the ‘feature
password encryption aes’ command.
The TOE is configured to not display configured keys as part of
configuration files using the ‘hidekeys’ command.
FPT_APW_EXT.1 The TOE prevents reading of cryptographic passwords. AES password
encryption can be configured by an authorized administrator to encrypt
stored passwords using the "feature password encryption aes" command.
In this manner, the TOE ensures that plaintext user passwords will not be
disclosed even to administrators.
Cisco MDS 9000 Series Switches Security Target
55
TOE SFRs How the SFR is Met
FPT_STM_EXT.1 The MDS 9000 Series switch can provide hardware-based timestamp that
are used to provide that timestamp in audit records. The TOE provides
the use the of internally generated time stamps.
The date and time are used as the time stamp that is applied to TOE
generated audit records and used to track inactivity of administrative
sessions. This function can only be accessed from within the configuration
exec mode via the privileged mode of operation of the TOE. The clock
function is reliant on the system clock provided by the underlying
hardware.
FPT_TUD_EXT.1 An Authorized Administrator can query the software version running on
the TOE and can initiate updates to (replacements of) software images.
When software updates are made available by Cisco, an administrator can
obtain, verify the integrity of, and install those updates. The updates can
be downloaded from the software.cisco.com.
The validity of the image is verified using digital signature prior to
installing the update.
The TOE image files are digitally signed so their integrity can be verified
during the boot process, and an image that fails an integrity check will not
be loaded. The digital certificates used by the update verification
mechanism are contained on the TOE. Detailed instructions for how to do
this verification are provided in the administrator guidance for this
evaluation.
The TOE is performing the integrity verification functions related to this
SFR using RSA-2048 with SHA-512
FPT_TST_EXT.1 The TOE runs a suite of self-tests during initial start-up to verify its
correct operation. Refer to the FIPS Security Policy for available options
and management of the cryptographic self-test.
For testing of the TSF, the TOE automatically runs checks and tests at
startup and during resets to ensure the TOE is operating correctly. Refer
to the Guidance documentation for installation configuration settings and
information and troubling shooting if issues are identified.
When the system is booted up in FIPS mode, the FIPS power-up self-tests
run on the supervisor and line card modules. If any of these FIPS self-tests
fail, the whole system is moved to the FIPS error state. In this state, as per
the FIPS requirement, all cryptographic keys are deleted, and all line
cards are shut down. This mode is exclusively meant for debugging
purposes.
Once the switch is in the FIPS error state, any reload of a line card moves
it to the failure state. To move the switch back to FIPS mode, it has to be
rebooted. However, once the switch is in FIPS mode, any power-up self-
test failure on a subsequent line card reload or insertion affects only that
line card, and only the corresponding line card is moved to the failure
state.
If any of the self-tests fail, the TOE transitions into an error state. In the
error state, all secure data transmission is halted and the TOE outputs
status information indicating the failure.
Cisco MDS 9000 Series Switches Security Target
56
TOE SFRs How the SFR is Met
The following cryptographically self-tests tests are run:
• AES Known Answer Test
• HMAC Known Answer Test
• RNG/DRBG Known Answer Test
• SHA-1/SHA-256/SHA-384/SHA-512 Known Answer Test
• RSA Signature Known Answer Test (both signature/verification)
• Software Integrity Test
FTA_SSL_EXT.1 An administrator can configure maximum inactivity times individually for
both local and remote administrative sessions through the use of the
“session-timeout” setting applied to the console. These settings are not
immediately activated for the current session. The current line console
session must be exited. When the user logs back in, the inactivity timer
will be activated for the new session. If a local user session is inactive for
a configured period of time, the session will be terminated. The local user
will need to re-authentication to start a new session. If a remote user
session is inactive for a configured period of time, the session will be
terminated and will require authentication to establish a new session.
The allowable inactivity timeout range is from 0 to 525600 minutes,
although a value of 0 should not be used to ensure an inactivity timeout is
enforced. Administratively configurable timeouts are also available for
the EXEC level access (access above level 1) through use of the “exec-
timeout” setting.
FTA_SSL.3
FTA_SSL.4 An administrator is able to exit out of both local and remote
administrative sessions by using the “exit” command.
FTA_TAB.1 The TOE displays a customizable login banner on the local and remote CLI
management interface prior to allowing any administrative access to the
TOE.
FTP_ITC.1 The TOE protects communications between the TOE and the remote audit
server using TLS. This provides a secure channel to transmit the log
events.
FTP_TRP.1 All remote administrative communications take place over a secure
encrypted SSH session. The SSH session is encrypted using AES
encryption. A remote authorized administrator is able to initiate SSH
communications with the TOE.
6.2 Key Zeroization
The following table describes the key zeroization referenced by FCS_CKM_EXT.4
provided by the TOE.
Table 19: TOE Key Zeroization
Cisco MDS 9000 Series Switches Security Target
57
Name Description Zeroization
SSH Private Key Once the function has completed the operations requiring
the RSA key object, the module overwrites the entire
object (no matter its contents) using memset. This
overwrites the key with all 0’s.
Zeroized using the
following command:
# crypto key zeroize rsa
Overwritten with: 0x00
SSH Session Key The results zeroized using the free operation with the
poisoning mechanism to overwrite the values with 0x00.
This is called by the ssh_close function when a session is
ended.
Automatically when the
SSH session is terminated.
Overwritten with: 0x00
User Password This is a variable 15+ character password that is used to
authenticate local users. The password is stored in
NVRAM.
Zeroized by overwriting
with new password
Enable
Password (if
used)
This is a variable 15+ character password that is used to
authenticate local users at a higher privilege level. The
password is stored in NVRAM.
Zeroized by overwriting
with new password
RNG Seed This seed is for the RNG. The seed is stored in DRAM. Zeroized upon power
cycle the device
RNG Seed Key This is the seed key for the RNG. The seed key is stored in
DRAM.
Zeroized upon power
cycle the device
AES Key The results zeroized using the poisoning in free to
overwrite the values with 0x00. This is called by the
ssh_close function when a session is ended.
Automatically when the
SSH/TLS session is
terminated.
Overwritten with: 0x00
User Password This is a variable 15+ character password that is used to
authenticate local users. The password is stored in
NVRAM.
Zeroized by overwriting
with new password
TLS server
private key
This key is used for authentication, so the server can prove
who it is. The private key used for SSLv3.1/TLS secure
connections. The key is stored in NVRAM.
CLI command zeroize RSA
Command: crypto key
zeroise
verify with command:
show crypto key
mypubkey all
TLS server
public key
This key is used to encrypt the data that is used to
compute the secret key. The public key used for
SSLv3.1/TLS secure connection. The key is stored in
NVRAM.
CLI command zeroize RSA
Command: crypto key
zeroize
verify with command:
show crypto key
mypubkey all
TLS pre-master
secret
The pre-master secret is the client and server exchange of
random numbers and a special number, the pre-master
secret, This pre-master secret is using asymmetric
cryptography from which new TLS session keys can be
created. The key is stored in SDRAM.
Automatically after TLS
session terminated.
Cisco MDS 9000 Series Switches Security Target
58
Name Description Zeroization
TLS session
encryption key
The session encryption key is unique for each session and
is based on the shared secrets that were negotiated at the
start of the session. The Key is used to encrypt TLS
session data. The key is stored in SDRAM.
Automatically after TLS
session terminated.
TLS session
integrity key
This key is used to provide the privacy and TLS data
integrity protection. The key is stored in SDRAM.
Automatically after TLS
session terminated. The
entire object is
overwritten with zeros
6.3 CAVP Certificate Equivalence
The TOE models and processors included in the evaluation are shown in Table 6.
Cisco MDS 9000 Series Switches Security Target
59
7 Annex A: References
The following documentation was used to prepare this ST:
Table 20: References
Identifier Description
[CC_PART1] Common Criteria for Information Technology Security Evaluation – Part 1:
Introduction and general model, dated April 2017, version 3.1, Revision 5
[CC_PART2] Common Criteria for Information Technology Security Evaluation – Part 2: Security
functional components, dated April 2017, version 3.1, Revision 5
[CC_PART3] Common Criteria for Information Technology Security Evaluation – Part 3: Security
assurance components, dated April 2017, version 3.1, Revision 5
[CEM] Common Methodology for Information Technology Security Evaluation – Evaluation
Methodology, dated April 2017, version 3.1, Revision 5
[NDcPP] collaborative Protection Profile for Network Devices, Version 2.2e, 23 March 2020
[800-56A] NIST Special Publication 800-56A Rev 2, May 2013
[800-56B] NIST Special Publication 800-56B Recommendation for Pair-Wise, August 2009
[FIPS 140-2] FIPS PUB 140-2 Federal Information Processing Standards Publication
Security Requirements for Cryptographic Modules May 25, 2001
[FIPS PUB 186-3] FIPS PUB 186-3 Federal Information Processing Standards Publication Digital
Signature Standard (DSS) June, 2009
[FIPS PUB 186-4] FIPS PUB 186-4 Federal Information Processing Standards Publication Digital
Signature Standard (DSS) July 2013
[NIST SP 800-90A
Rev 1]
NIST Special Publication 800-90A Recommendation for Random Number Generation
Using Deterministic Random Bit Generators January 2015
[FIPS PUB 180-3] FIPS PUB 180-3 Federal Information Processing Standards Publication Secure Hash
Standard (SHS) October 2008
[FIPS PUB 198-1] Federal Information Processing Standards Publication The Keyed-Hash Message
Authentication Code (HMAC) July 2008