Americas Headquarters: Cisco Systems, Inc., 170 West Tasman Drive, San Jose, CA 95134-1706 USA © 2018 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public. Cisco Catalyst 4500 Series Wired Access Switches running IOS-XE 3.10 Common Criteria Security Target Version 1.0 16 November 2018 Cisco Catalyst 4500 Wired Access Switches 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...................................................................................................... 9 1.4 TOE Evaluated Configuration ...................................................................................... 11 1.5 Physical Scope of the TOE ........................................................................................... 12 1.6 Logical Scope of the TOE............................................................................................. 15 1.6.1 Security Audit....................................................................................................... 16 1.6.2 Cryptographic Support.......................................................................................... 16 1.6.3 Identification and authentication........................................................................... 18 1.6.4 Security Management ........................................................................................... 18 1.6.5 Protection of the TSF............................................................................................ 19 1.6.6 TOE Access .......................................................................................................... 19 1.6.7 Trusted path/Channels .......................................................................................... 19 1.7 Excluded Functionality................................................................................................. 19 2 Conformance Claims.............................................................................................................21 2.1 Common Criteria Conformance Claim......................................................................... 21 2.2 Protection Profile Conformance ................................................................................... 21 2.2.1 Protection Profile Additions ................................................................................. 24 2.3 Protection Profile Conformance Claim Rationale ........................................................ 24 2.3.1 TOE Appropriateness............................................................................................ 24 2.3.2 TOE Security Problem Definition Consistency.................................................... 24 2.3.3 Statement of Security Requirements Consistency................................................ 24 3 SECURITY PROBLEM DEFINITION................................................................................26 3.1 Assumptions.................................................................................................................. 26 3.2 Threats........................................................................................................................... 27 3.3 Organizational Security Policies................................................................................... 28 4 SECURITY OBJECTIVES...................................................................................................29 4.1 Security Objectives for the TOE................................................................................... 29 4.2 Security Objectives for the Environment...................................................................... 29 5 SECURITY REQUIREMENTS ...........................................................................................30 5.1 Conventions .................................................................................................................. 30 5.2 TOE Security Functional Requirements ....................................................................... 30 5.2.1 Security audit (FAU)............................................................................................. 31 5.2.2 Cryptographic Support (FCS)............................................................................... 34 5.2.3 Identification and authentication (FIA) ................................................................ 38 5.2.4 Security management (FMT)................................................................................ 40 5.2.5 Protection of the TSF (FPT) ................................................................................. 41 5.2.6 TOE Access (FTA) ............................................................................................... 42 5.2.7 Trusted Path/Channels (FTP)................................................................................ 43 5.3 TOE SFR Dependencies Rationale for SFRs Found in NDcPPv2.0e .......................... 43 Cisco Catalyst 4500 Wired Access Switches 3 5.4 Security Assurance Requirements ................................................................................ 44 5.4.1 SAR Requirements................................................................................................ 44 5.4.2 Security Assurance Requirements Rationale........................................................ 44 5.5 Assurance Measures...................................................................................................... 44 6 TOE Summary Specification ................................................................................................46 6.1 TOE Security Functional Requirement Measures ........................................................ 46 7 Annex A: Key Zeroization....................................................................................................60 7.1 Key Zeroization ............................................................................................................ 60 8 Annex B: References.............................................................................................................62 Cisco Catalyst 4500 Wired Access Switches 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 CISCO CATALYST 4503-E, 4506-E, 4507R+E, 4510R+E HARDWARE MODELS AND SPECIFICATIONS ......................12 TABLE 6 FIPS REFERENCES.............................................................................................................................................................................16 TABLE 7 TOE PROVIDED CRYPTOGRAPHY ...................................................................................................................................................17 TABLE 8 EXCLUDED FUNCTIONALITY ............................................................................................................................................................19 TABLE 9 NIAP TECHNICAL DECISIONS (TD)......................................................................................................................................21 TABLE 10 PROTECTION PROFILES ..................................................................................................................................................................24 TABLE 11 TOE ASSUMPTIONS ........................................................................................................................................................................26 TABLE 12 THREATS..........................................................................................................................................................................................27 TABLE 13 ORGANIZATIONAL SECURITY POLICIES.......................................................................................................................................28 TABLE 14 SECURITY OBJECTIVES FOR THE ENVIRONMENT........................................................................................................................29 TABLE 15 SECURITY FUNCTIONAL REQUIREMENTS....................................................................................................................................30 TABLE 16 AUDITABLE EVENTS.......................................................................................................................................................................32 TABLE 17 ASSURANCE MEASURES..................................................................................................................................................................44 TABLE 18 ASSURANCE MEASURES..................................................................................................................................................................44 TABLE 19 HOW TOE SFRS MEASURES.........................................................................................................................................................46 TABLE 20 TOE KEY ZEROIZATION .................................................................................................................................................................60 TABLE 21 REFERENCES.....................................................................................................................................................................................62 List of Figures FIGURE 1 TOE EXAMPLE DEPLOYMENT .......................................................................................................................................................11 FIGURE 2 CISCO CATALYST 4503-E, 4506-E, 4507R+E, 4510R+E CHASSIS AND MODULES........................................................12 FIGURE 3 CISCO CATALYST 4500-X SERIES CHASSIS AND MODULES ......................................................................................................14 FIGURE 4 32 X 10 GIGABIT ETHERNET PORT SWITCH WITH OPTIONAL UPLINK MODULE SLOT.......................................................14 FIGURE 5 16 X 10 GIGABIT ETHERNET PORT SWITCH WITH OPTIONAL UPLINK MODULE SLOT.......................................................14 FIGURE 6 8 X 10 GIGABIT ETHERNET PORT UPLINK MODULE..................................................................................................................14 FIGURE 7 FRONT-TO-BACK AIRFLOW REAR VIEW ......................................................................................................................................15 FIGURE 8 BACK-TO-FRONT AIRFLOW REAR VIEW ......................................................................................................................................15 Cisco Catalyst 4500 Wired Access Switches 5 Acronyms The following acronyms and abbreviations are common and may be used in this Security Target: Table 1 Acronyms Acronyms / Abbreviations Definition AAA Administration, Authorization, and Accounting ACL Access Control Lists AES Advanced Encryption Standard BRI Basic Rate Interface CC Common Criteria for Information Technology Security Evaluation CEM Common Evaluation Methodology for Information Technology Security CM Configuration Management DHCP Dynamic Host Configuration Protocol EAL Evaluation Assurance Level EHWIC Ethernet High-Speed WIC ESP Encapsulating Security Payload GE Gigabit Ethernet port HTTP Hyper-Text Transport Protocol HTTPS Hyper-Text Transport Protocol Secure ICMP Internet Control Message Protocol IEEE Institute of Electrical and Electronics Engineers IGMP Internet Group Management Protocol IOS The proprietary operating system developed by Cisco Systems. IP Internet Protocol IPsec IP Security ISDN Integrated Services Digital Network IT Information Technology MAC Media Access Control NDcPP collaborative Network Device Protection Profile NVRAM Non-volatile random access memory, specifically the memory in the switch where the configuration parameters are stored. OS Operating System Packet A block of data sent over the network transmitting the identities of the sending and receiving stations, error-control information, and message. PBKDF2 Password-Based Key Derivation Function version 2 PoE Power over Ethernet PP Protection Profile PRNG Pseudo Random Number Generator RADIUS Remote Authentication Dial In User Service RNG Random Number Generator RSA Rivest, Shamir and Adleman (algorithm for public-key cryptography) SA Security Association SFP Small–form-factor pluggable port SHS Secure Hash Standard SM Service Module SSHv2 Secure Shell (version 2) ST Security Target TCP Transport Control Protocol TCP/IP Transmission Control Protocol/Internet Protocol Cisco Catalyst 4500 Wired Access Switches 6 Acronyms / Abbreviations Definition TOE Target of Evaluation TSC TSF Scope of Control TSF TOE Security Function TSP TOE Security Policy UDP User datagram protocol WAN Wide Area Network WIC WAN Interface Card 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). Firmware (per NIST for FIPS validated cryptographic modules) The programs and data components of a cryptographic module that are stored in hardware (e.g., ROM, PROM, EPROM, EEPROM or FLASH) within the cryptographic boundary and cannot be dynamically written or modified during execution. Cisco Catalyst 4500 Wired Access Switches 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 Catalyst 4500 Series Wired Access Switches (Cat4K WAS). 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 Catalyst 4500 Wired Access Switches 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 Catalyst 4500 Series Wired Access Switches running IOS-XE 3.10 ST Version 1.0 Publication Date 16 November 2018 Vendor and ST Author Cisco Systems, Inc. TOE Reference Cisco Catalyst 4500 Series Wired Access Switches TOE Hardware Models 4503-E, 4506-E, 4507R+E, 4510R+E, 4500-X and 4500-XF TOE Software Version IOS-XE 3.10 Keywords Audit, Authentication, Encryption, Network Device, Secure Administration 1.2 TOE Overview The Cisco Catalyst Switches 4503-E, 4506-E, 4507R+E, 4510R+E, 4500-X and 4500-XF running IOS-XE 3.10 (herein after referred to as Cat4K WAS). The TOE is a purpose-built, switching and routing platform with OSI Layer2 and Layer3 traffic filtering capabilities. The TOE is a switching and routing platform used to construct IP networks by interconnecting multiple smaller networks or network segments. As a Layer2 switch, it performs analysis of incoming frames, makes forwarding decisions based on information contained in the frames, and forwards the frames toward the destination. As a Layer3 switch/router, it supports routing of traffic based on tables identifying available routes, conditions, distance, and costs to determine the best route for a given packet. The TOE includes the hardware models as defined in Table 3 in Section 1.1. Cisco IOS-XE software is a Cisco-developed highly configurable proprietary operating system that provides for efficient and effective switching and routing. Although IOS-XE performs many networking functions, this Security Target only addresses the functions that provide for the security of the TOE itself as described in Section 1.6 TOE logical scope below. Cisco Catalyst 4500 Wired Access Switches 9 1.2.1 TOE Product Type The Cisco Cat4K WAS are switching and routing platforms that provide connectivity and security services onto a single, secure device. These switches offer broadband speeds and simplified management to small businesses, and enterprise small branch and teleworkers. The Cisco Cat4K WAS is single-device security and switching solutions for protecting the network. 1.2.2 Supported non-TOE Hardware/ Software/ Firmware The TOE supports the following hardware, software, and firmware components in its operational environment. Each component is identified as being required or not based on the claims made in this Security Target. All of the following environment components are supported by all TOE evaluated configurations. Table 4 IT Environment Components Component Required Usage/Purpose Description for TOE performance Audit (Syslog) Server Yes This includes any syslog server to which the TOE would transmit syslog messages over IPsec. 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 that is used by the TOE administrator to support TOE administration using SSHv2 protected channels. Any SSH client that supports SSHv2 may be used. RADIUS AAA Server Yes This includes any IT environment RADIUS AAA server that provides authentication services to TOE administrators Certification Authority (CA) Yes This includes any IT Environment Certification Authority on the TOE network. This can be used to provide the TOE with a valid certificate during certificate enrollment. 1.3 TOE DESCRIPTION This section provides an overview of the Catalyst 4500 Wired Access Switches Target of Evaluation (TOE). The TOE is comprised of both software and hardware. The hardware is comprised of the following: 4503-E, 4506-E, 4507R+E, 4510R+E, 4500-X and 4500-XF. The software is comprised of the Universal Cisco Internet Operating System (IOS) software image Release IOS-XE 3.10. The Cat4K WAS that comprises the TOE has 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. The Cat4K WAS primary features include the following:  Central processor that supports all system operations; Cisco Catalyst 4500 Wired Access Switches 10  Dynamic memory, used by the central processor for all system operation.  Flash memory (EEPROM), used to store the Cisco IOS image (binary program).  USB port (v2.0) (note, none of the USB devices are included in the TOE). o Type A for Storage, all Cisco supported USB flash drives.  Non-volatile read-only memory (ROM) is used to store the bootstrap program and power- on diagnostic programs.  Non-volatile random-access memory (NVRAM) is used to store switch configuration parameters that are used to initialize the system at start-up.  Physical network interfaces (minimally two) (e.g. RJ45 serial and standard 10/100/1000 Ethernet ports). Some models have a fixed number and/or type of interfaces; some models have slots that accept additional network interfaces.  10 Gigabit Ethernet (GE) uplinks and supports Power over Ethernet Plus (PoE+) and Universal POEP (UPOE). (Universal POEP is an enhancement to the PoEP (802.3at) standard to allow powered devices up to 60W.  Redundant power supplies and fans Cisco IOS-XE is a Cisco-developed highly configurable proprietary operating system that provides for efficient and effective routing and switching. Although IOS-XE performs many networking functions, this TOE only addresses the functions that provide for the security of the TOE itself as described in Section 1.6 Logical Scope of the TOE below. The following figure provides a visual depiction of an example TOE deployment: Cisco Catalyst 4500 Wired Access Switches 11 = TOE Boundary Figure 1 TOE Example Deployment The previous figure includes the following:  Identifies the TOE Models o Catalyst Switches 4503-E, 4506-E, 4507R+E, 4510R+E, 4500-X and 4500-XF running IOS-XE 3.10  The following IT entities are considered to be in the IT Environment: o Authentication Server o Local Console o Management Workstation o Syslog Server o CA Server 1.4 TOE Evaluated Configuration The TOE consists of a physical device as specified in section 1.5 below and includes the Cisco IOS-XE software. The TOE has two or more network interfaces and is connected to at least one TOE Syslog Server (Mandatory) Management Workstation (Mandatory) AAA Server (Mandatory) CA (Mandatory) Local Console (Mandatory) Cisco Catalyst 4500 Wired Access Switches 12 internal and one external network. The Cisco IOS-XE 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 Cat4K WAS is to be remotely administered, then the management station must be connected to an internal network, SSHv2 may be used to connect to the switch. A syslog server is also used to store audit records. 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. 1.5 Physical Scope of the TOE The TOE is a hardware and software solution that makes up the switch models as follows: 4503- E, 4506-E, 4507R+E, 4510R+E, 4500-X and 4500-XF running Cisco IOS-XE 3.10. The network, on which they reside, is considered part of the environment. The TOE guidance documentation that is considered to be part of the TOE can be found listed in the Cisco Cat4K WAS Common Criteria Operational User Guidance and Preparative Procedures document and are downloadable from the http://cisco.com web site. The TOE is comprised of the following physical specifications as illustrated and described in the Figures and Tables below: Figure 2 Cisco Catalyst 4503-E, 4506-E, 4507R+E, 4510R+E Chassis and Modules Table 5 Cisco Catalyst 4503-E, 4506-E, 4507R+E, 4510R+E Hardware Models and Specifications Feature 4503-E 4506-E 4507R+E 4510R+E Software IOS-XE 3.10 IOS-XE 3.10 IOS-XE 3.10 IOS-XE 3.10 Dimensions (H x W x D) Weight w/fan tray 12.25 x 17.31 x 12.50 in. 32.25lb 17.38 x 17.31 x 12.50 in. 40.50lb 19.19 x 17.31 x 12.50 in. 44.50lb 24.35 x 17.31 x 12.50 in. 54.50lb Supervisor engines supported (SUP9-E, SUP8-E, Sup8L-E) Supervisor Engines 8-E, 8L-E, 9-E Supervisor Engines 8-E, 8L-E, 9-E Supervisor Engines 8-E, 8L-E, 9-E Supervisor Engines 8-E, 8L-E, 9-E Line-card slots available 2 5 5 8 Cisco Catalyst 4500 Wired Access Switches 13 Feature 4503-E 4506-E 4507R+E 4510R+E Number of power supply bays 2 2 2 2 Integrated PoE Yes Yes Yes Yes Maximum PoE per slot 1500W 1500W 1500W 1500W slots 1 and 2; 750W slots 3, 4, and 7-10 Switched 10/100 Fast Ethernet (RJ-45) w/48 interfaces per line card 96 240 240 384 Switched 10/100 Fast Ethernet (RJ-45) with IEEE 802.3af at Power over Ethernet (PoE/PoE+) w/48 interfaces per line card 96 240 240 384 Switched 100 FX Fast Ethernet (MT-RJ) w/48 interfaces per line card 96 240 240 384 Switched 1000BASE- X (fiber) w/6, 18 or 48 interfaces per line card 100 244 244 388 Switched 10/100/1000BASE-T Gigabit Ethernet w/48 interfaces per line card 96 240 240 384 Switched 10/100/1000BASE-T Gigabit Ethernet with IEEE 802.3af at PoE/PoE+ w/48 interfaces per line card 96 240 240 384 Switched 10/100/1000BASE-T Gigabit Ethernet with UPOE w/48 interfaces per line card 96 240 240 384 Switched 10 Gigabit Ethernet w/6 or 12 interfaces per line card 32 68 68 104 The Cisco Catalyst 4500-X Series Switch are fixed aggregation platform that provides flexibility through two versions of base switches along with optional uplink module. Both the 32- and 16- port versions can be configured with optional network modules and offer similar features. The Small Form-Factor Pluggable Plus (SFP+) interface supports both 10 Gigabit Ethernet and 1 Gigabit Ethernet ports, allowing upgrades to 10 Gigabit Ethernet when organizational demands change. The uplink module is hot swappable. Deployment Options include:  Front to Back Airflow (4500X) Cisco Catalyst 4500 Wired Access Switches 14  32 x 10 Gigabit Ethernet Port switch with optional Small Form-Factor Pluggable Plus (SFP+) models  16 x 10 Gigabit Ethernet Port switch with optional Small Form-Factor Pluggable Plus (SFP+) models  Back to Front Airflow (4500X-F)  32 x 10 Gigabit Ethernet Port switch with optional Small Form-Factor Pluggable Plus (SFP+) models  16 x 10 Gigabit Ethernet Port switch with optional Small Form-Factor Pluggable Plus (SFP+) models  8 x 10 Gigabit Ethernet SFP+ removable uplink module  Dual-redundant AC/DC power supply and five field-replaceable unit (FRU) fans  External USB support for flexible storage options (up-to 4GB)  10/100/1000 RJ-45 console and management port The figure below shows the Cisco Catalyst 4500-X Series Switch with and without the optional 8-port uplink module, front-to-back airflow, and the uplink module. Figure 3 Cisco Catalyst 4500-X Series Chassis and Modules Figure 4 32 x 10 Gigabit Ethernet Port Switch with Optional Uplink Module Slot Figure 5 16 x 10 Gigabit Ethernet Port Switch with Optional Uplink Module Slot Figure 6 8 x 10 Gigabit Ethernet Port Uplink Module Cisco Catalyst 4500 Wired Access Switches 15 Figure 7 Front-to-Back Airflow Rear View Figure 8 Back-to-Front Airflow Rear View 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.  Security Audit  Cryptographic Support  Identification and Authentication  Security Management  Protection of the TSF  TOE Access  Trusted Path/Channels These features are described in more detail in the subsections below. In addition, the TOE implements all SFRs of the NDcPPv2.0e as necessary to satisfy testing/assurance measures prescribed therein. Cisco Catalyst 4500 Wired Access Switches 16 1.6.1 Security Audit The Cisco Cat4K WAS provides extensive auditing capabilities. The TOE generates a comprehensive set of audit logs that identify specific TOE operations. For each event, the TOE records the date and time of each event, the type of event, the subject identity, and the outcome of the event. 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 TOE is configured to transmit its audit messages to an external syslog server. Communication with the syslog server is protected using IPsec and the TOE can determine when communication with the syslog server fails. If that should occur, the TOE can be configured to block new permit actions. The audit logs can be viewed on the TOE using the appropriate IOS-XE 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 audit data stored locally on the TOE. 1.6.2 Cryptographic Support The TOE provides cryptography in support of other Cisco Cat4K WAS security functionality. This IOS-XE software calls the IOS Common Cryptographic Module (IC2M) Rel5 (Firmware Version: Rel 5) certificate 2388 and has been validated for conformance to the requirements of FIPS 140-2 Level 1 (see Table 6 for algorithm certificate references). Table 6 FIPS References Algorithm Description Supported Mode CAVP Cert. # Module SFR AES Used for symmetric encryption/decryption AES Key Wrap in CBC (128 and 256 bits) 4583 IC2M FCS_COP.1/DataEncryption Cisco Catalyst 4500 Wired Access Switches 17 Algorithm Description Supported Mode CAVP Cert. # Module SFR SHS (SHA-1, SHA-256 and SHA-512) Cryptographic hashing services Byte Oriented 3760 IC2M FCS_COP.1/Hash HMAC (HMAC-SHA- 1, HMAC- SHA-256 and HMAC-SHA- 512) Keyed hashing services and software integrity test Byte Oriented 3034 IC2M FCS_COP.1/KeyedHash DRBG Deterministic random bit generation services in accordance with ISO/IEC 18031:2011 CTR_DRBG (AES 256) 1529 IC2M FCS_RBG_EXT.1 RSA Signature Verification and key transport FIPS PUB 186-4 Key Generation PKCS #1 v2.1 2048 bit key 2500 IC2M FCS_CKM.1 FCS_COP.1/SigGen The TOE provides cryptography in support of remote administrative management via SSHv2 and IPsec to secure the transmission of audit records to the remote syslog server. In addition, IPsec is used to secure the session between the TOE and the authentication servers. The cryptographic services provided by the TOE are described in Table 7 below. Table 7 TOE Provided Cryptography Cryptographic Method Use within the TOE AES Used to encrypt IPsec session traffic. Used to encrypt SSH session traffic. HMAC Used for keyed hash, integrity services in SSH session establishment. DH Used as the Key exchange method for SSH Internet Key Exchange Used to establish initial IPsec session. KAS Used to provide key exchange method Secure Shell Establishment Used to establish initial SSH session. RSA Signature Services Used in IPsec session establishment. Used in SSH session establishment. X.509 certificate signing. SP 800-90A DRBG Used for random number generation, key generation and seeds to asymmetric key generation Used in IPsec session establishment. Used in SSH session establishment. SHS Used to provide IPsec traffic integrity verification Used to provide SSH traffic integrity verification Cisco Catalyst 4500 Wired Access Switches 18 The Cat4K WAS processors are as follows:  Catalyst 4500 Series Sup8E, Sup8LE and Sup9E platforms – Power PC (PPCe5500) CPU  Catalyst 4500X Series platform - Power PC (PPCe500) core 1.6.3 Identification and authentication The TOE performs two types of authentication: device-level authentication of the remote device and user authentication for the Authorized Administrator of the TOE. Device-level authentication allows the TOE to establish a secure channel with a trusted peer. The secure channel is established only after each device authenticates the other. Device-level authentication is performed via IKE/IPsec mutual authentication. The IKE phase authentication for the IPsec communication channel between the TOE and authentication server and between the TOE and syslog server is considered part of the Identification and Authentication security functionality of the TOE. The TOE provides authentication services for administrative users to connect to the TOEs secure CLI administrator interface. The TOE requires Authorized Administrators to authenticate prior to being granted access to any of the management functionality. The TOE can be configured to require a minimum password length of 15 characters as well as mandatory password complexity rules. The TOE provides administrator authentication against a local user database. Password- based authentication can be performed on the serial console or SSHv2 secured connection. The TOE supports use of a RADIUS AAA server (part of the IT Environment) for authentication of administrative users attempting to connect to the TOE’s CLI. The TOE also provides an automatic lockout when a user attempts to authenticate and enters invalid information. When the threshold for a defined number of authentication attempts fail has exceeded the configured allowable attempts, the user is locked out until an authorized administrator can enable the user account. The TOE uses X.509v3 certificates as defined by RFC 5280 to support authentication for IPsec. 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 secured connection with the TOE acting as SSH server or via a local console connection. The TOE provides the ability to securely manage:  Administration of the TOE locally and remotely;  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. Cisco Catalyst 4500 Wired Access Switches 19 The TOE supports two separate administrator roles: non-privileged administrator and privileged administrator. Only the privileged administrator can perform the above security relevant management functions. The privileged administrator is the Authorized Administrator of the TOE who has the ability to enable, disable, determine and modify the behavior of all of the security functions of the TOE as described in this document. 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 to Authorized Administrators. The TOE prevents reading of cryptographic keys and passwords. Additionally Cisco IOS-XE is not a general-purpose operating system and access to Cisco IOS-XE memory space is restricted to only Cisco IOS-XE functions. The TOE internally maintains the date and time. This date and time is 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 testing to verify correct operation of the switch itself and that of the cryptographic module. 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. 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 TOE can also 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 channels to be established to itself from remote administrators that is SSHv2 secured connection, and initiates outbound IPsec tunnels to transmit audit messages to remote syslog servers. In addition, IPsec is used to secure the session between the TOE and the authentication servers. 1.7 Excluded Functionality The following functionality is excluded from the evaluation. Table 8 Excluded Functionality Excluded Functionality Exclusion Rationale Non-FIPS 140-2 mode of operation This mode of operation includes non-FIPS allowed operations. These services can 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.0 + Errata 20180314. Cisco Catalyst 4500 Wired Access Switches 20 Cisco Catalyst 4500 Wired Access Switches 21 2 CONFORMANCE CLAIMS 2.1 Common Criteria Conformance Claim The TOE and ST are compliant with the Common Criteria (CC) Version 3.1, Revision 4, dated: September 2012. 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. 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 functional requirements claimed in this document. Table 9 NIAP TECHNICAL DECISIONS (TD) TD Identifier TD Name Protection Profiles References Publication Date Applic able? TD0343 NIT Technical Decision for Updating FCS_IPSEC_EXT.1.14 Tests CPP_FW_ V2.0E, CPP_ND_ V2.0E ND SD V2.0, FCS_IPSEC_EXT.1. 14 08/02/18 Yes TD0342 NIT Technical Decision for TLS and DTLS Server Tests CPP_ND_ V2.0E ND SD V2.0, FCS_DTLSS_EXT.1, FCS_DTLSS_EXT.2, FCS_TLSS_EXT.1, FCS_TLSS_EXT.2 08/02/18 No TD0341 NIT Technical Decision for TLS wildcard checking CPP_ND_ V2.0E ND SD V2.0, FCS_TLSC_EXT.1.2 , FCS_TLSC_EXT.2.2 , FCS_DTLSC_EXT.1 .2, FCS_DTLSC_EXT.2 .2, 08/02/18 No TD0340 NIT Technical Decision for Handling of the basicConstraints extension in CA and leaf certificates CPP_FW_ V2.0E, CPP_ND_ V2.0E FIA_X509_EXT.1.1 08/02/18 Yes TD0339 NIT Technical Decision for Making password- based authentication optional in FCS_SSHS_EXT.1.2 CPP_FW_ V2.0E, CPP_ND_ V2.0E ND SD V2.0, FCS_SSHS_EXT.1.2 08/02/18 Yes Cisco Catalyst 4500 Wired Access Switches 22 TD0338 NIT Technical Decision for Access Banner Verification CPP_ND_ V2.0E ND SD V2.0, FTA_TAB.1 08/02/18 Yes TD0337 NIT Technical Decision for Selections in FCS_SSH*_EXT.1.6 CPP_FW_ V2.0E, CPP_ND_ V2.0E ND SD V2.0, FCS_SSHC_EXT.1, FCS_SSHS_EXT.1 08/02/18 Yes TD0336 NIT Technical Decision for Audit requirements for FCS_SSH*_EXT.1.8 CPP_ND_ V2.0E ND SD V2.0, FCS_SSHC_EXT.1.8 , FCS_SSHS_EXT.1.8 08/01/18 Yes TD0335 NIT Technical Decision for FCS_DTLS Mandatory Cipher Suites CPP_FW_ V2.0E, CPP_ND_ V2.0E FCS_DTLSC_EXT.1 .1, FCS_DTLSC_EXT.2 .1, FCS_DTLSS_EXT.1. 1, FCS_DTLSS_EXT.2. 1, 08/01/18 No TD0334 NIT Technical Decision for Testing SSH when password-based authentication is not supported CPP_ND_ V2.0E ND SD V2.0, FCS_SSHC_EXT.1.9 08/01/18 No TD0333 NIT Technical Decision for Applicability of FIA_X509_EXT.3 CPP_FW_ V2.0E, CPP_ND_ V2.0E ND SD V2.0, FIA_X509_EXT 08/01/18 Yes TD0324 NIT Technical Decision for Correction of section numbers in SD Table 1 CPP_ND_ V2.0E Table 1 05/18/18 Yes TD0323 NIT Technical Decision for DTLS server testing - Empty Certificate Authorities list CPP_ND_ V2.0E ND SD V2.0, FCS_DTLSS_EXT.2. 7, FCS_DTLSS_EXT.2. 8 05/18/18 No TD0322 NIT Technical Decision for TLS server testing - Empty Certificate Authorities list CPP_ND_ V2.0E ND SD V.1.0, ND SD V2.0, FCS_TLSS_EXT.2.4, FCS_TLSS_EXT.2.5 05/18/18 No TD0321 Protection of NTP communications CPP_FW_ V2.0E, CPP_ND_ V2.0E FTP_ITC.1, FPT_STM_EXT.1 05/21/18 No TD0291 NIT technical decision for DH14 and FCS_CKM.1 CPP_FW_ V1.0, CPP_FW_ v2.0, CPP_FW_ V2.0E, FCS_CKM.1.1, ND SD V1.0, ND SD V2.0 02/03/18 Yes Cisco Catalyst 4500 Wired Access Switches 23 CPP_ND_ V1.0, CPP_ND_ V2.0, CPP_ND_ V2.0E TD0290 NIT technical decision for physical interruption of trusted path/channel. CPP_ND_ V1.0, CPP_ND_ V2.0, CPP_ND_ V2.0E FTP_ITC.1, FTP_TRP.1, FPT_ITT.1, ND SD V1.0, ND SD V2.0 02/03/18 Yes TD0289 NIT technical decision for FCS_TLSC_EXT.x.1 Test 5e CPP_ND_ V1.0, CPP_ND_ V2.0, CPP_ND_ V2.0E FCS_TLSC_EXT.1.1 , FCS_TLSC_EXT.2.1 , FCS_DTLSC_EXT.1 .1 (only ND SD V2.0), FCS_DTLSC_EXT.2 .1 (only ND SD V2.0) 02/03/18 No TD0281 NIT Technical Decision for Testing both thresholds for SSH rekey CPP_ND_ V1.0, CPP_ND_ V2.0, CPP_ND_ V2.0E FCS_SSHC_EXT.1.8 , FCS_SSHS_EXT.1.8 , ND SD V1.0, ND SD V2.0 01/05/18 Yes TD0259 NIT Technical Decision for Support for X509 ssh rsa authentication IAW RFC 6187 CPP_FW_ v2.0, CPP_FW_ V2.0E, CPP_ND_ V2.0, CPP_ND_ V2.0E FCS_SSHC_EXT.1.5 /FCS_SSHS_EXT.1. 5 11/13/17 Yes TD0257 NIT Technical Decision for Updating FCS_DTLSC_EXT.x.2/F CS_TLSC_EXT.x.2 Tests 1-4 CPP_ND_ V1.0, CPP_ND_ V2.0, CPP_ND_ V2.0E ND SD V1.0, ND SD V2.0, FCS_DTLSC_EXT.1 .2/FCS_DTLSC_EX T.2.2 Tests 1-4 (ND SD V2.0), FCS_TLSC_EXT.1.2 /FCS_TLSC_EXT.2. 2, Tests 1-4 (ND SD V1.0, ND SD V2.0) 11/13/17 No TD0256 NIT Technical Decision for Handling of TLS connections with and CPP_ND_ V1.0, CPP_ND_ V2.0, ND SD V1.0, ND SD V2.0, FCS_DTLSC_EXT.2 .5 (ND SD V2.0), 11/13/17 No Cisco Catalyst 4500 Wired Access Switches 24 without mutual authentication CPP_ND_ V2.0E FCS_TLSC_EXT.2 (ND SD V1.0, ND SD V2.0) TD0228 NIT Technical Decision for CA certificates - basicConstraints validation CPP_FW_ V1.0, CPP_ND_ V1.0, CPP_ND_ V2.0, CPP_ND_ V2.0E ND SD V1.0, ND SD V2.0, FIA_X509_EXT.1.2 06/15/18 Yes Table 10 Protection Profiles Protection Profile Version Date collaborative Protection Profile for Network Devices (NDcPP) + Errata 2.0e 14 March 2018 2.2.1 Protection Profile Additions The ST claims exact conformance to the collaborative Protection Profile for Network Devices (NDcPP), Version 2.0 + Errata 20180314 and does not include any additions to the functionality described in the Protection Profile. 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.0 + Errata 20180314 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, Version 2.0 + Errata 20180314 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.0e, 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 NDcPPv2.0e, for which conformance is claimed verbatim. All concepts covered in the Protection Profile’s Statement of Security Requirements are Cisco Catalyst 4500 Wired Access Switches 25 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 NDcPPv2.0e. Cisco Catalyst 4500 Wired Access Switches 26 3 SECURITY PROBLEM DEFINITION This section 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 11 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 a 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 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. Cisco Catalyst 4500 Wired Access Switches 27 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 12 Threats Threat Threat Definition T.UNAUTHORIZED_ADMINISTRATO R_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. 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_ENDP OINTS Threat agents may take advantage of secure protocols that use weak methods to authenticate the endpoints – e.g., shared password that is guessable or transported as plaintext. The consequences are the same as a poorly designed protocol, the attacker could masquerade as the administrator or another device, and the attacker could insert themselves into the network stream and perform a man-in-the- middle attack. The result is the critical network traffic is exposed and there could be a loss of confidentiality and integrity, and potentially the network device itself could be compromised. 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.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. 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. Cisco Catalyst 4500 Wired Access Switches 28 Threat Threat Definition 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_CO MPROMISE 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_FAI LURE 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. 3.3 Organizational Security Policies The following table lists the Organizational Security Policies imposed by an organization to address its security needs. Table 13 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 Catalyst 4500 Wired Access Switches 29 4 SECURITY OBJECTIVES This section 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.0 + Errata 20180314 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 14 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 TOE Administrators are trusted to follow and apply all administrator guidance 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 Catalyst 4500 Wired Access Switches 30 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 4, dated: September 2012 and all international interpretations. 5.1 Conventions The CC defines operations on Security Functional Requirements: assignments, selections, assignments within selections and refinements. This document uses the following font conventions to identify the operations defined by the CC:  Unaltered SFRs are stated in the form used in [CC2] or their extended component definition (ECD);  Refinement made in the PP: the refinement text is indicated with bold text and strikethroughs;  Selection wholly or partially completed in the PP: the selection values (i.e. the selection values adopted in the PP or the remaining selection values available for the ST) are indicated with underlined text e.g. “[selection: disclosure, modification, loss of use]” in [CC2] or an ECD might become “disclosure” (completion) or “[selection: disclosure, modification]” (partial completion) in the PP;  Assignment wholly or partially completed in the PP: indicated with italicized text;  Assignment completed within a selection in the PP: the completed assignment text is indicated with italicized and underlined text e.g. “[selection: change_default, query, modify, delete, [assignment: other operations]]” in [CC2] or an ECD might become “change_default, select_tag” (completion of both selection and assignment) or “[selection: change_default, select_tag, select_value]” (partial completion of selection, and completion of assignment) in the PP;  Iteration: indicated by adding a string starting with “/” (e.g. “FCS_COP.1/Hash”). Extended SFRs are identified by having a label “EXT” at the end of the SFR name. 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 15 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 External Audit Trail Storage FCS: Cryptographic support FCS_CKM.1 Cryptographic Key Generation (for asymmetric keys) FCS_CKM.2 Cryptographic Key Establishment (Refined) FCS_CKM.4 Cryptographic Key Zeroization Cisco Catalyst 4500 Wired Access Switches 31 Class Name Component Identification Component Name FCS_COP.1/DataEncryption Cryptographic Operation (for data encryption/decryption) FCS_COP.1/SigGen Cryptographic Operation (for cryptographic signature) FCS_COP.1/Hash Cryptographic Operation (for cryptographic hashing) FCS_COP.1/KeyedHash Cryptographic Operation (for keyed-hash message authentication) FCS_RBG_EXT.1 Extended: Cryptographic Operation (Random Bit Generation) FCS_IPSEC_EXT.1 IPsec Protocol FCS_SSHS_EXT.1 SSH Server Protocol FIA: Identification and authentication FIA_AFL.1 Authentication Failure Management FIA_PMG_EXT.1 Password Management FIA_UIA_EXT.1 User Identification and Authentication FIA_UAU_EXT.2 Extended: Password-based Authentication Mechanism FIA_UAU.7 Protected Authentication Feedback FIA_X509_EXT.1/Rev X.509 Certificate Validation FIA_X509_EXT.2 X.509 Certificate Authentication FIA_X509_EXT.3 X.509 Certificate Requests FMT: Security management FMT_MOF.1(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_TST_EXT.1 TSF Testing FPT_TUD_EXT.1 Trusted Update FPT_STM_EXT.1 Reliable Time Stamps 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/Admin 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 shut-down of the audit functions; b) All auditable events for the not specified level of audit; and c) All administrative actions comprising:  Administrative login and logout (name of user account shall be logged if individual user accounts are required for administrators).  Changes to TSF data related to configuration changes (in addition to the information Cisco Catalyst 4500 Wired Access Switches 32 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 16. FAU_GEN.1.2 The TSF shall record within each audit record at least the following information:  Date and time of the event, type of event, subject identity, and the outcome (success or failure) of the event; and  For each audit event type, based on the auditable event definitions of the functional components included in the cPP/ST, information specified in column three of Table 16. Table 16 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_IPSEC_EXT.1 Failure to establish an IPsec SA. Reason for failure. FCS_SSHS_EXT.1 Failure to establish an SSH session Reason for failure. FCS_RBG_EXT.1 None. None. FIA_AFL.1 Unsuccessful login attempts limit is met or exceeded Origin of the attempt (e.g., IP address). FIA_PMG_EXT.1 None. None. FIA_UIA_EXT.1 All use of the identification and authentication mechanism. Origin of the attempt (e.g., IP address). FIA_UAU_EXT.2 All use of the identification and authentication mechanism. Origin of the attempt (e.g., IP address). FIA_UAU.7 None. None. FIA_X509_EXT.1/Rev Unsuccessful attempt to validate a certificate Reason for failure FIA_X509_EXT.2 None. None. FIA_X509_EXT.3 None. None. FMT_MOF.1/ ManualUpdate Any attempt to initiate a manual update None. FMT_MTD.1/CoreData All management activities of TSF data. None. FMT_MTD.1/CryptoKeys Management of cryptographic keys. None. FMT_SMF.1 None. None. FMT_SMR.2 None. None. FPT_SKP_EXT.1 None. None. FPT_APW_EXT.1 None. None. FPT_TST_EXT.1 None. None. Cisco Catalyst 4500 Wired Access Switches 33 SFR Auditable Event Additional Audit Record Contents FPT_TUD_EXT.1 Initiation of update; result of the update attempt (success and failure) None. FPT_STM_EXT.1 Discontinuous changes to time – either Administrator actuated or changed via an automated process. (Note that no continuous changes to time need to be logged. See also application note on FPT_STM_EXT.1) For discontinuous changes to time: The old and new values for the time. Origin of the attempt to change time for success and failure (e.g., IP address). FTA_SSL_EXT.1 Any attempts at unlocking of an interactive session. 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. Failures 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 Protected Audit Event 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. FAU_STG_EXT.1.3 The TSF shall [overwrite previous audit records according to the following rule: [when allotted space has reached its threshold], [no other action]] when the local storage space for audit data is full. Cisco Catalyst 4500 Wired Access Switches 34 5.2.2 Cryptographic Support (FCS) 5.2.2.1 FCS_CKM.1 Cryptographic Key Generation (Refinement) FCS_CKM.1.1 The TSF shall generate asymmetric cryptographic keys in accordance with a specified cryptographic key generation algorithm: [  RSA schemes using cryptographic key sizes of 2048-bit or greater that meet the following: FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Appendix B.3;  FFC Schemes using Diffie-Hellman group 14 that meet the following: RFC 3526, Section 3 ] and specified cryptographic key sizes [assignment: cryptographic key sizes] that meet the following: [assignment: list of standards]. 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: NIST Special Publication 800-56B Revision 1, “Recommendation for Pair-Wise Key Establishment Schemes Using Integer Factorization Cryptography”;  Key establishment scheme using Diffie-Hellman group 14 that meets the following: RFC 3526, Section 3; ] that meets the following: [assignment: list of standards]. 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 [ 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] 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]. Cisco Catalyst 4500 Wired Access Switches 35 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], ] 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, ]. 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-512] and cryptographic key sizes [assignment: cryptographic key sizes] and message digest sizes [160, 256, 512] bits that meet the following: ISO/IEC 10118-3:2004. 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-512] and cryptographic key sizes [160-bit, 256-bit, 512-bit] and message digest sizes [160, 256, 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 [CTR_DRBG (AES)]. FCS_RBG_EXT.1.2 The deterministic RBG shall be seeded by at least one entropy source that accumulates entropy from [[1] hardware 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_IPSEC_EXT.1 Internet Protocol Security (IPsec) Communications FCS_IPSEC_EXT.1.1 The TSF shall implement the IPsec architecture as specified in RFC 4301. FCS_IPSEC_EXT.1.2 The TSF shall have a nominal, final entry in the SPD that matches anything that is otherwise unmatched, and discards it. Cisco Catalyst 4500 Wired Access Switches 36 FCS_IPSEC_EXT.1.3 The TSF shall implement [tunnel mode, transport mode]. FCS_IPSEC_EXT.1.4 The TSF shall implement the IPsec protocol ESP as defined by RFC 4303 using the cryptographic algorithms [AES-CBC-128, AES-CBC-256 (specified by RFC 3602)] and together with a Secure Hash Algorithm (SHA)-based HMAC [HMAC-SHA1, HMAC-SHA-256, HMAC-SHA-512] and [no other algorithm]. FCS_IPSEC_EXT.1.5 The TSF shall implement the protocol: [  IKEv1, using Main Mode for Phase 1 exchanges, as defined in RFCs 2407, 2408, 2409, RFC 4109, [no other RFCs for extended sequence numbers], and [no other RFCs for hash functions]].  IKEv2 as defined in RFCs 5996 [with no support for NAT traversal], and [no other RFCs for hash functions] ]. FCS_IPSEC_EXT.1.6 The TSF shall ensure the encrypted payload in the [IKEv1, IKEv2] protocol uses the cryptographic algorithms [AES-CBC-128, AES-CBC-256 (as specified in RFC 3602)]. FCS_IPSEC_EXT.1.7 The TSF shall ensure that [  IKEv1 Phase 1 SA lifetimes can be configured by an Security Administrator based on [ o length of time, where the time values can be configured within [1-24] hours; ];  IKEv2 SA lifetimes can be configured by an Security Administrator based on [ o length of time, where the time values can be configured within [1-24] hours; ] ]. FCS_IPSEC_EXT.1.8 The TSF shall ensure that [  IKEv1 Phase 2 SA lifetimes can be configured by an Security Administrator based on [ o number of bytes o length of time, where the time values can be configured within [1-8] hours; ];  IKEv2 Child SA lifetimes can be configured by an Security Administrator based on [ o number of bytes o length of time, where the time values can be configured within [1-8] hours; ] ]. FCS_IPSEC_EXT.1.9 The TSF shall generate the secret value x used in the IKE Diffie-Hellman key exchange (“x” in gx mod p) using the random bit generator specified in FCS_RBG_EXT.1, and having a length of at least [320 (for DH Group 14)] bits. Cisco Catalyst 4500 Wired Access Switches 37 FCS_IPSEC_EXT.1.10 The TSF shall generate nonces used in [IKEv1, IKEv2] exchanges of length [  according to the security strength associated with the negotiated Diffie-Hellman group; ]. FCS_IPSEC_EXT.1.11 The TSF shall ensure that IKE protocols implement DH Group(s) [14 (2048-bit MODP)]. FCS_IPSEC_EXT.1.12 The TSF shall be able to ensure by default that the strength of the symmetric algorithm (in terms of the number of bits in the key) negotiated to protect the [IKEv1 Phase 1, IKEv2 IKE_SA] connection is greater than or equal to the strength of the symmetric algorithm (in terms of the number of bits in the key) negotiated to protect the [IKEv1 Phase 2, IKEv2 CHILD_SA] connection. FCS_IPSEC_EXT.1.13 The TSF shall ensure that all IKE protocols perform peer authentication using [RSA] that use X.509v3 certificates that conform to RFC 4945 and [Pre-shared Keys]. FCS_IPSEC_EXT.1.14 The TSF shall only establish a trusted channel if the presented identifier in the received certificate matches the configured reference identifier, where the presented and reference identifiers are of the following fields and types: [CN: IP address, CN: Fully Qualified Domain Name (FQDN), CN: user FQDN, Distinguished Name (DN)] and [no other reference identifier type]]. 5.2.2.10 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]. FCS_SSHS_EXT.1.2 The TSF shall ensure that the SSH protocol implementation supports the following authentication methods as described in RFC 4252: public key-based, [password based]. FCS_SSHS_EXT.1.3 The TSF shall ensure that, as described in RFC 4253, packets greater than [65,535 bytes] bytes in an SSH transport connection are dropped. FCS_SSHS_EXT.1.4 The TSF shall ensure that the SSH transport implementation uses the following encryption algorithms and rejects all other encryption algorithms: [aes128-cbc, aes256- cbc]. FCS_SSHS_EXT.1.5 The TSF shall ensure that the SSH public-key based authentication implementation uses [ssh-rsa] as its public key algorithm(s) and rejects all other public key algorithms. FCS_SSHS_EXT.1.6 The TSF shall ensure that the SSH transport implementation uses [hmac- sha1, hmac-sha1-96] as its data integrity MAC algorithm(s) and rejects all other MAC algorithm(s). Cisco Catalyst 4500 Wired Access Switches 38 FCS_SSHS_EXT.1.7 The TSF shall ensure that [diffie-hellman-group14-sha1] and [no other methods] are the only allowed key exchange methods used for the SSH protocol. FCS_SSHS_EXT.1.8 The TSF shall ensure that within SSH connections the same session keys are used for a threshold of no longer than one hour, and no more than one gigabyte of transmitted data. After either of the thresholds are reached a rekey needs to be performed. 5.2.3 Identification and authentication (FIA) 5.2.3.1 Authentication Failure Management FIA_AFL.1.1 The TSF shall detect when an Administrator configurable positive integer within [1-3] unsuccessful authentication attempts occur related to Administrators attempting to authenticate remotely. FIA_AFL.1.2 When the defined number of unsuccessful authentication attempts has been met, the TSF shall [prevent the offending remote Administrator from successfully authenticating until [an authorized administrator unlocks the locked user account] is taken by a local Administrator]. 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: a) Passwords shall be able to be composed of any combination of upper and lower case letters, numbers, and the following special characters: [“!”, “@”, “#”, “$”, “%”, “^”, “&”, “*”, “(“,”)”, [no other characters]]; b) Minimum password length shall be configurable to [15] and [15]. 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;  [any network packets as configured by the authorized administrator may flow through the switch]. 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. Cisco Catalyst 4500 Wired Access Switches 39 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 authentication mechanism, and [remote password-based authentication via RADIUS] 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. 5.2.3.6 FIA_X509_EXT.1/Rev X.509 Certificate Validation FIA_X509_EXT.1.1/Rev The TSF shall validate certificates in accordance with the following rules:  RFC 5280 certificate validation and certificate path validation supporting a minimum path length of three certificates.  The certificate path must terminate with a trusted CA certificate.  The TSF shall validate a 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 [Certificate Revocation List (CRL) as specified in RFC 5759 Section 5].  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 [IPsec], and [[no additional uses]. FIA_X509_EXT.2.2 When the TSF cannot establish a connection to determine the validity of a certificate, the TSF shall [allow the administrator to choose whether to accept the certificate in these cases]. Cisco Catalyst 4500 Wired Access Switches 40 5.2.3.8 FIA_X509_EXT.3 X.509 Certificate Requests FIA_X509_EXT.3.1 The TSF shall generate a Certificate Request as specified by RFC 2986 and be able to provide the following information in the request: public key and [Common Name, Organization, Organizational Unit, Country]. FIA_X509_EXT.3.2 The TSF shall validate the chain of certificates from the Root CA upon receiving the CA Certificate Response. 5.2.4 Security management (FMT) 5.2.4.1 FMT_MOF.1/ManualUpdate Management of security functions behaviour FMT_MOF.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/CoreData The TSF shall restrict the ability to manage the TSF data to 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 [hash comparison] capability prior to installing those updates;  Ability to configure the authentication failure parameters for FIA_AFL.1;  [ o Ability to configure audit behaviour; o Ability to configure the list of TOE-provided services available before an entity is identified and authenticated, as specified in FIA_UIA_EXT.1; o Ability to configure the cryptographic functionality; o Ability to configure thresholds for SSH rekeying; o Ability to configure the lifetime for IPsec SAs; o Ability to re-enable an Administrator account; o Ability to set the time which is used for time-stamps; ] Cisco Catalyst 4500 Wired Access Switches 41 ]. 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 Protection of TSF Data (for reading of all pre-shared, symmetric and private 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_TST_EXT.1: TSF Testing FPT_TST_EXT.1.1 The TSF shall run a suite of the following self-tests [during initial start-up (on power on). periodically during normal operation] to demonstrate the correct operation of the TSF: [  Power-on Self-Tests: o Firmware Integrity Test o Known Answer Tests:  AES KAT  DRBG KAT  HMAC KAT  KAS ECC KAT  KAS FFC KAT  RSA KAT  SP 800-56B RSA key wrap/unwrap KAT  Conditional Self-Tests (run periodically during normal operation): o Continuous Random Number Generator test for DRBG Cisco Catalyst 4500 Wired Access Switches 42 o Continuous Random Number Generator test for Entropy Source o RSA Pairwise Consistency Test o Bypass Test ]. 5.2.5.4 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 [no other TOE firmware/software version]. 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 [published hash] prior to installing those updates. 5.2.5.5 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.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, [  lock the session - disable any activity of the user’s data access/display devices other than unlocking the session, and requiring that the administrator re-authenticate to the TSF prior to unlocking the session] after a Security Administrator-specified time period of inactivity. 5.2.6.2 FTA_SSL.3 TSF-initiated Termination 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 FTA_SSL.4.1 The TSF shall allow Administrator-initiated termination of the Administrator’s own interactive session. Cisco Catalyst 4500 Wired Access Switches 43 5.2.6.4 FTA_TAB.1 Default TOE Access Banners 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 [IPsec] to provide a trusted communication channel between itself and authorized IT entities supporting the following capabilities: audit server, [authentication 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:  remote AAA servers using IPsec  external audit server using IPsec ]. 5.2.7.2 FTP_TRP.1 Trusted Path 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 for SFRs Found in NDcPPv2.0e The Security Functional Requirements (SFRs) in this Security Target represent the SFRs identified in the NDcPPv2.0e. As such, the NDcPPv2.0e SFR dependency rationale is deemed acceptable since the PP itself has been validated. Cisco Catalyst 4500 Wired Access Switches 44 5.4 Security Assurance Requirements 5.4.1 SAR Requirements The TOE assurance requirements for this ST are taken directly from the NDcPPv2.0e which are derived from Common Criteria Version 3.1, Revision 4. The assurance requirements are summarized in the table below. Table 17 Assurance Measures Assurance Class Components Components Description DEVELOPMENT ADV_FSP.1 Basic Functional Specification GUIDANCE DOCUMENTS AGD_OPE.1 Operational user guidance AGD_PRE.1 Preparative User guidance LIFE CYCLE SUPPORT ALC_CMC.1 Labeling of the TOE ALC_CMS.1 TOE CM coverage TESTS ATE_IND.1 Independent testing - conformance VULNERABILITY ASSESSMENT AVA_VAN.1 Vulnerability analysis 5.4.2 Security Assurance Requirements Rationale The Security Assurance Requirements (SARs) in this Security Target represent the SARs identified in the NDcPPv2.0e. As such, the NDcPPv2.0e 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 18 Assurance Measures Component How requirement will be met ADV_FSP.1 The functional specification describes the external interfaces of the TOE; such as the means for a user to invoke a service and the corresponding response of those services. The description includes the interface(s) that enforces a security functional requirement, the interface(s) that supports the enforcement of a security functional requirement, and the interface(s) that does not enforce any security functional requirements. The interfaces are described in terms of their:  purpose (general goal of the interface);  method of use (how the interface is to be used);  parameters (explicit inputs to and outputs from an interface that control the behaviour of that interface);  parameter descriptions (tells what the parameter is in some meaningful way) and  error messages (identifies the condition that generated it, what the message is, and the meaning of any error codes). The development evidence also contains a tracing of the interfaces to the SFRs described in this ST. 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. Cisco Catalyst 4500 Wired Access Switches 45 Component How requirement will be met 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 Configuration Management (CM) document(s) describes how the consumer (end-user) of the TOE can identify the evaluated TOE (Target of Evaluation). The CM document(s) identifies the configuration items, how those configuration items are uniquely identified, and the adequacy of the procedures that are used to control and track changes that are made to the TOE. This includes details on what changes are tracked, how potential changes are incorporated, and the degree to which automation is used to reduce the scope for error. ALC_CMS.1 ATE_IND.1 Cisco will provide the TOE for testing. AVA_VAN.1 Cisco will provide the TOE for testing. Cisco Catalyst 4500 Wired Access Switches 46 6 TOE SUMMARY SPECIFICATION 6.1 TOE Security Functional Requirement Measures This section identifies and describes how the Security Functional Requirements identified above are met by the TOE. Table 19 How TOE SFRs Measures TOE SFRs How the SFR is Met FAU_GEN.1 The TOE generates an audit record whenever an audited event occurs. The types of events that cause audit records to be generated include identification and authentication related events, and administrative events (the specific events and the contents of each audit record are listed in the table within the FAU_GEN.1 SFR, “Auditable Events Table”). Each of the events is specified in the audit record is in enough detail to identify the user for which the event is associated (e.g. user identity, MAC address, IP address), when the event occurred, where the event occurred, the outcome of the event, and the type of event that occurred such as generating keys, including the type of key. Additionally, the startup and shutdown of the audit functionality is audited. The audit trail consists of the individual audit records; one audit record for each event that occurred. The audit record can contain up to 80 characters and a percent sign (%), which follows the time-stamp information. As noted above, the information includes [at least] all of the required information. Additional information can be configured and included if desired. Refer to the Common Criteria Operational User Guidance and Preparative Procedures for command description and usage information. Following is the audit record format: seq no:timestamp: %facility-severity-MNEMONIC:description (hostname-n) Following is an example of an audit record: *Mar 1 18:46:11: %SYS-5-CONFIG_I: Configured from console by vty2 (10.34.195.36) 18:47:02: %SYS-5-CONFIG_I: Configured from console by vty2 (10.34.195.36) *Mar 1 18:48:50.483 UTC: %SYS-5-CONFIG_I: Configured from console by vty2 (10.34.195.36) The logging buffer size can be configured from a range of 4096 (default) to 2147483647 bytes. It is noted, not make the buffer size too large because the switch could run out of memory for other tasks. Use the show memory privileged EXEC command to view the free processor memory on the switch. However, this value is the maximum available, and the buffer size should not be set to this amount. Refer to the Common Criteria Operational User Guidance and Preparative Procedures for command description and usage information. The log buffer is circular, so newer messages overwrite older messages after the buffer is full. Administrators are instructed to monitor the log buffer using the show logging privileged EXEC command to view the audit records. The first message displayed is the oldest message in the buffer. There are other associated commands to clear the buffer, to set the logging level, etc.; all of which are described in the Guidance documents and IOS CLI. Refer to the Common Criteria Operational User Guidance and Preparative Procedures for command description and usage information. Cisco Catalyst 4500 Wired Access Switches 47 TOE SFRs How the SFR is Met The logs can be saved to flash memory so records are not lost in case of failures or restarts. Refer to the Common Criteria Operational User Guidance and Preparative Procedures for command description and usage information. The administrator can set the level of the audit records to be displayed on the console or sent to the syslog server. For instance, all emergency, alerts, critical, errors, and warning message can be sent to the console alerting the administrator that some action needs to be taken as these types of messages mean that the functionality of the switch is affected. All notifications and information type message can be sent to the syslog server, whereas message is only for information; switch functionality is not affected. To configure the TOE to send audit records to a syslog server, the ‘set logging server’ command is used. A maximum of three syslog servers can be configured. Refer to the Common Criteria Operational User Guidance and Preparative Procedures for command description and usage information. The audit records are transmitted using IPsec tunnel 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. The FIPS crypto tests performed during startup, the messages are displayed only on the console. Once the box is up and operational and the crypto self-test command is entered, then the messages would be displayed on the console and will also be logged. For the TSF self-test, successful completion of the self-test is indicated by reaching the log-on prompt. If there are issues, the applicable audit record is generated and displayed on the console. 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. For an IT entity or device, the IP address, MAC address, host name, or other configured identification is presented. Refer to the Common Criteria Operational User Guidance and Preparative Procedures for command description and usage information. FAU_STG_EXT.1 The TOE is configured to export syslog records to a specified, external syslog server in real-time. Once the configuration is complete, the audit records are automatically sent to the external syslog server. The TOE protects communications with an external syslog server via IPsec. If the IPsec connection fails, the TOE will store audit records locally on the TOE when it is discovered it can no longer communicate with the configured syslog server. When the connection is restored, the TOE will transmit the buffer contents to the syslog server For audit records stored internally to the TOE, the administrator has the ability to configure the TOE to stop all auditable events when an audit storage threshold is met (lossless auditing) or given the log file is circular, the TOE may overwrite the oldest audit records when the audit trail becomes full. The size of the logging files on the TOE is configurable by the administrator with the minimum value being 4096 (default) to 2147483647 bytes of available disk space. Please refer to the Guidance documentation for configuration syntax and information. Only Authorized Administrators are able to clear the local logs, and local audit records are stored in a directory that does not allow administrators to modify the contents. Cisco Catalyst 4500 Wired Access Switches 48 TOE SFRs How the SFR is Met FCS_CKM.1 The TOE implements DH group 14 key establishment schemes that meets RFC 3526, Section 3. The TOE implements and uses the prime and generator specified in RFC 3526 Section 3 when generating parameters for the key exchange. The TOE also implements RSA key establishment schemes that is 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. Asymmetric cryptographic keys used for IKE peer authentication are generated according to FIPS PUB 186-4, Appendix B.3 for RSA schemes. The TOE can create an RSA public-private key pair that can be used to generate a Certificate Signing Request (CSR). Through use of Simple Certificate Enrollment Protocol (SCEP), the TOE can send the CSR to a Certificate Authority (CA) for the CA to generate a certificate and receive its X509v3 certificate from the CA. Integrity of the CSR and certificate during transit are assured through use of digitally signatures (encrypting the hash of the TOE’s public key contained in the CSR and certificate). The TOE can store and distribute the certificate to external entities including Registration Authorities (RA). 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. The TOE implements Diffie-Hellman (DH) group 14 (2048) bit key establishment schemes in SSH. The DH key generation meets the NIST FIPS PUB 186-4 Appendix B.1. The TOE acts as a receiver for SSH communications and as both a sender and receiver for IPsec communications. For details on each protocol, see the related SFR. FCS_CKM.2 FCS_CKM.4 None of the symmetric keys, pre-shared keys, or private keys are stored in plaintext form. The TOE meets all requirements specified in FIPS 140-2 for destruction of keys and Critical Security Parameters (CSPs). See Section 7.1 for more information on the key zeroization. FCS_COP.1/DataEncryption The TOE provides symmetric encryption and decryption capabilities using AES in CBC mode (128, 256 bits) as described in ISO 18033-3 and ISO 10116. AES is implemented in the following protocols: IPsec and SSH. The relevant FIPS certificate numbers are listed in Table 6 FIPS References. The TOE provides cryptographic signature services using RSA Digital Signature Algorithm with key size of 2048 and greater as specified in FIPS PUB 186-4, “Digital Signature Standard”. The relevant FIPS certificate numbers are listed in Table 6 FIPS References. The TOE provides cryptographic hashing services using SHA-1, SHA-256 and SHA- 512 as specified in ISO/IEC 10118-3:2004. For IKE (ISAKMP) hashing, administrators can select any of SHA-1, SHA-256 and/or SHA-512 (with message FCS_COP.1/SigGen FCS_COP.1/Hash FCS_COP.1/KeyedHash Cisco Catalyst 4500 Wired Access Switches 49 TOE SFRs How the SFR is Met digest sizes of 160, 256 and 512 bits respectively) to be used with remote IPsec endpoints. SHA-512 hashing is used for verification of software image integrity. The relevant FIPS certificate numbers are listed in Table 6 FIPS References. The TOE provides keyed-hashing message authentication services using HMAC- SHA-1 and HMAC-SHA-256 operates on 512-bit blocks and HMAC-SHA-512 operate on 1024-bit blocks of data, with key sizes and message digest sizes of 160- bits, 256 bits and 512 bits respectively) as specified in ISO/IEC 9797-2:2011, Section 7 “MAC Algorithm 2”. The relevant FIPS certificate numbers are listed in Table 6 FIPS References. FCS_IPSEC_EXT.1 The TOE implements IPsec to provide authentication and encryption services to prevent unauthorized viewing or modification of data as it travels over the external network. In addition to tunnel mode, which is the default IPsec mode, the TOE also supports transport mode, allowing for only the payload of the packet to be encrypted. If tunnel mode is explicitly specified, the switch will request tunnel mode and will accept only tunnel mode. The TOE implements IPsec to provide both certificates and pre-shared key-based authentication and encryption services to prevent unauthorized viewing or modification of data as it travels over the external network. The TOE implementation of the IPsec standard (in accordance with the RFCs noted in the SFR and using cryptographic algorithms AES-CBC-128 and AES-CBC-256 together with HMAC- SHA1, HMAC-SHA-256, and HMAC-SHA-512) uses the Encapsulating Security Payload (ESP) protocol to provide authentication, encryption and anti-replay services. Preshared keys can be configured using the 'crypto isakmp key' key command and may be proposed by each of the peers negotiating the IKE establishment. IPsec Internet Key Exchange, also called ISAKMP, is the negotiation protocol that lets two peers agree on how to build an IPsec Security Association (SA). The IKE protocols implement Peer Authentication using the RSA algorithm with X.509v3 certificates or preshared keys. When certificates are used for authentication, the fully qualified domain name (FQDN) or the distinguished name (DN) is verified to ensure the certificate is valid and is from a valid entity. The DN naming attributes in the certificate is compared with the expected DN naming attributes and deemed valid if the attribute types are the same and the values are the same and as expected. IKE separates negotiation into two phases: phase 1 and phase 2. Phase 1 creates the first tunnel, which protects later ISAKMP negotiation messages. The key negotiated in phase 1 enables IKE peers to communicate securely in phase 2. During Phase 2 IKE establishes the IPsec SA. IKE maintains a trusted channel, referred to as a Security Association (SA), between IPsec peers that is also used to manage IPsec connections, including:  The negotiation of mutually acceptable IPsec options between peers (including peer authentication parameters, either signature based or pre-shared key based),  The establishment of additional Security Associations to protect packets flows using Encapsulating Security Payload (ESP), and Cisco Catalyst 4500 Wired Access Switches 50 TOE SFRs How the SFR is Met  The agreement of secure bulk data encryption AES keys for use with ESP. After the two peers agree upon a policy, the security parameters of the policy are identified by an SA established at each peer, and these IKE SAs apply to all subsequent IKE traffic during the negotiation. The TOE supports both IKEv1 and IKEv2 session establishment. As part of this support, the TOE can be configured to not support aggressive mode for IKEv1 exchanges and to only use main mode using the 'crypto isakmp aggressive-mode disable' command. The TOE can be configured to not allow "confidentiality only" ESP mode by ensuring the IKE Policies configured include ESP-encryption. The TOE supports configuration lifetimes of both Phase 1 SAs and Phase 2 SAs using "lifetime" command. The default time value for Phase 1 SAs is 24 hours, though is configurable from 1 to 24 hours. The default time value for Phase 2 SAs is 1 hour, though is configurable up to 8 hours. The TOE also supports configuring the maximum amount of traffic that is allowed to flow for a given IPsec SA using the following command, 'crypto ipsec security- association lifetime'. The default amount is 2560KB, which is the minimum configurable value. The maximum configurable value is 4GB. The TOE provides AES-CBC-128 and AES-CBC-256 for encrypting the IKEv1 and IKEv2 payloads. The administrator is instructed in the AGD to ensure that the size of key used for ESP must be greater than or equal to the key size used to protect the IKE payload. The TOE supports Diffie-Hellman Group 14 (2048-bit keys), in support of IKE Key Establishment. These keys are generated using the AES-CTR Deterministic Random Bit Generator (DRBG), as specified in SP 800-90, and the following corresponding key sizes (in bits) are used: 320 (for DH Group 14) bits. The DH group can be configured by issuing the following command during the configuration of IPsec: TOE-common-criteria (config-isakmp)# group 14 This selects DH Group 14 (2048-bit MODP) for IKE and this sets the DH group offered during negotiations. The TOE generates the secret value 'x' used in the IKEv1 Diffie-Hellman key exchange ('x' in gx mod p) using the NIST approved AES-CTR Deterministic Random Bit Generator (DRBG) specified in FCS_RBG_EXT.1 and having possible lengths of 320 bits. When a random number is needed for a nonce, the probability that a specific nonce value will be repeated during the life a specific IPsec SA is less than 1 in 2^128. The nonce is likewise generated using the AES-CTR DRBG. IPsec provides secure tunnels between two peers. An authorized administrator defines which packets are considered sensitive and should be sent through these secure tunnels. When the IPsec peer recognizes a sensitive packet, the peer sets up the appropriate secure tunnel and sends the packet through the tunnel to the remote peer. More accurately, these tunnels are sets of security associations (SAs) that are established between two IPsec peers. The SAs define the protocols and algorithms to be applied to sensitive packets and specify the keying material to be used. SAs are Cisco Catalyst 4500 Wired Access Switches 51 TOE SFRs How the SFR is Met unidirectional and are established per security protocol (AH or ESP). In the evaluated configuration only, ESP will be configured for use. A crypto map (the Security Policy Definition (SPD)) set can contain multiple entries, each with a different access list. The crypto map entries are searched in a sequence - the switch attempts to match the packet to the access list (acl) specified in that entry. When a packet matches a permit entry in a particular access list, the method of security in the corresponding crypto map is applied. If the crypto map entry is tagged as ipsecisakmp, IPsec is triggered. The traffic matching the permit acls would then flow through the IPsec tunnel and be classified as "PROTECTED". Traffic that does not match a permit crypto map acl and does not match a non-crypto permit acl on the interface would be DISCARDED. Traffic that does not match a permit acl in the crypto map, but does match a non-crypto permit acl would be allowed to BYPASS the tunnel. For example, a non-crypto permit acl for icmp would allow ping traffic to flow unencrypted if a permit crypto map was not configured that matches the ping traffic. If there is no SA that the IPsec can use to protect this traffic to the peer, IPsec uses IKE to negotiate with the remote peer to set up the necessary IPsec SAs on behalf of the data flow. The negotiation uses information specified in the crypto map entry as well as the data flow information from the specific access list entry. In IOS the negotiations of the IKE SA adheres to configuration settings for IPsec applied by the administrator. For example, in the first SA, the encryption, hash and DH group is identified, for the Child SA the encryption and the hash are identified. The administrator configures the first SA to be as strong as or stronger than the child SA; meaning if the first SA is set at AES 128, then the Child SA can only be AES128. If the first SA is AES256, then the Child SA could be AES128 or AES256. During the negotiations, if a non-match is encountered, the process stops and an error message is received. FCS_SSHS_EXT.1 The TOE implementation of SSHv2 supports the following:  Compliance with RFCs 4251, 4252, 4253, and 4254;  Dropping packets greater than 65,535 bytes, as such packets would violate the IP packet size limitations;  Enforcement to only allow the encryption algorithms AES-CBC-128, and AES-CBC-256 to ensure confidentiality of the session;  Enforcement to only use of the SSH_RSA public key algorithms for authentication;  Password-based authentication;  Enforcement to only allow the hashing algorithms hmac-sha1 and hmac- sha1-96 to ensure the integrity of the session and  Enforcement of DH Group 14 (diffie-hellman-group-14-sha1) as required by the NDcPPv2.0e. The TOE can also be configured to require a rekey of not more than one hour of time and of not more than one gig of data passing. Once configured, the TOE monitors both thresholds, and SSH re-keying is performed upon reaching whichever threshold is met first. FCS_RBG_EXT.1 The TOE implements a NIST-approved AES-CTR Deterministic Random Bit Generator (DRBG), as specified in SP 800-90 seeded by an entropy source that accumulates entropy from a TSF-hardware based noise source. Cisco Catalyst 4500 Wired Access Switches 52 TOE SFRs How the SFR is Met 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. FIA_AFL.1 The TOE provides the privileged administrator the ability to specify the maximum number of unsuccessful authentication attempts (within 3) before privileged administrator or non-privileged administrator is locked out through the administrative CLI using a privileged CLI command. Additionally, a local login can be configured to allow for TOE administrator access in the event of authentication failures by remote administrators. FIA_PMG_EXT.1 The TOE supports the local definition of users with corresponding passwords. The passwords can be composed of any combination of upper and lower case letters, numbers, and special characters (that include: [“!”, “@”, “#”, “$”, “%”, “^”, “&”, “*”, “(“,”)” Minimum password length is settable by the Authorized Administrator, and can be configured for minimum password lengths of 15 characters. FIA_UIA_EXT.1 The TOE requires all users to be successfully identified and authenticated before allowing any TSF mediated actions to be performed except for the login warning banner that is displayed prior to user authentication and any network packets as configured by the authorized administrator may flow through the switch. Administrative access to the TOE is facilitated through the TOE’s 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 secured connection, the TOE prompts the user for a user name and password. 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. The TOE provides public key-based authentication and local password based authentication mechanisms as well as RADIUS AAA server for remote authentication. The administrator authentication policies include authentication to the local user database or redirection to a remote authentication server. Interfaces can be configured to try one or more remote authentication servers, and then fail back to the local user database if the remote authentication servers are inaccessible. The process for authentication is the same for administrative access whether administration is occurring via a directly connected console or remotely via SSHv2 secured connection. At initial login, the administrative user is prompted to provide a username. After the user provides the username, the user is prompted to provide the administrative password associated with the user account. The TOE then either grant administrative access (if the combination of username and password is correct) or indicate that the login was unsuccessful. The TOE does not provide a reason for failure in the cases of a login failure. FIA_UAU_EXT.2 FIA_UAU.7 When a user enters their password at the local console, the TOE displays only ‘*’ characters so that the user password is obscured. Cisco Catalyst 4500 Wired Access Switches 53 TOE SFRs How the SFR is Met For remote session authentication, the TOE does not echo any characters as they are entered. FIA_X509_EXT.1/Rev The TOE uses X.509v3 certificates as defined by RFC 5280 to support authentication for IPsec. The TOE supports the following methods to obtain a certificate from a CA:  Manual cut-and-paste—The switch displays the certificate request on the console terminal, allowing the administrator to enter the issued certificate on the console terminal; manually cut-and-paste certificate requests and certificates when there is no network connection between the switch and CA All of the certificates include at least the following information: public key, Common Name, Organization, Organizational Unit and Country. The certificate validity is checked during session establishment with the CA. The TOE chooses which certificate to use based on its current configuration. For example, if the TOE is configured to use RSA, it will choose an RSA certificate. Public key infrastructure (PKI) credentials, such as Rivest, Shamir, and Adelman (RSA) keys and certificates can be stored in a specific location on the TOE. Certificates are stored to NVRAM by default; however, some switches do not have the required amount of NVRAM to successfully store certificates. All Cisco platforms support NVRAM and flash local storage. Depending on the platform, an authorized administrator may have other supported local storage options including bootflash, slot, disk, or USB flash. During run time, an authorized administrator can specify what active local storage device will be used to store certificates. The certificates themselves provide protection in that they are digitally signed. If a certificate is modified in any way, it will 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. Each CA corresponds to a trust point. When a certificate chain is received from a peer, the default processing of a certificate chain path continues until the first trusted certificate, or trust point, is reached. The administrator may configure the level to which a certificate chain is processed on all certificates including subordinate CA certificates. The authorized administrator can also configure one or more certificate fields together with their matching criteria to match. Such as: • alt-subject-name • expires-on • issuer-name • name • serial-number • subject-name • unstructured-subject-name • valid-start FIA_X509_EXT.2 FIA_X509_EXT.3 Cisco Catalyst 4500 Wired Access Switches 54 TOE SFRs How the SFR is Met This allows for installing more than one certificate from one or more CAs on the TOE. However, the default configuration is a single certificate from one CA that is used for all authenticated connections. The physical security of the TOE (A.PHYSICAL_PROTECTION) protects the switch and the certificates from being tampered with or deleted. Only authorized administrators with the necessary privilege level can access the certificate storage and add/delete them. 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 is used for certificate revocation. The authorized administrator uses the revocation-check and match key-usage cRLSign commands to specify CRL. The authorized administer sets the trust point and its name, and the revocation-check method: crl --Certificate checking is performed by a CRL. 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 administrator is able to choose whether or not to accept the certificate. FMT_MOF.1/ManualUpdate The TOE performs role-based authorization, using TOE platform authorization mechanisms, to grant access to the privileged and semi-privileged levels. For the purposes of this evaluation, the privileged level is equivalent to full administrative access to the CLI, which is the default access for IOS privilege level 15; and the semi- privileged level equates to any privilege level that has a subset of the privileges assigned to level 15. Privilege levels 0 and 1 are defined by default and are customizable, while levels 2-14 are undefined by default and also customizable. The term “Authorized Administrator” is used 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. As such the semi-privileged administrators with only a subset of privileges may also manage and modify TOE data based on the privileges assigned. The TOE provides the ability for Security Administrators (a.k.a 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 level has a set of permissions that will grant them access to the TOE data, though with some privilege levels, the access is limited. The TOE does not provide automatic updates to the software version running on the TOE. The Security Administrators (a.k.a 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, network packets are permitted to flow, as configured by the authorized administrator, through the switch prior to the identification and authentication of an authorized administrator. The warning and access banner can be displayed prior to FMT_MTD.1/CoreData FMT_MTD.1/CryptoKeys Cisco Catalyst 4500 Wired Access Switches 55 TOE SFRs How the SFR is Met the identification and authentication of an authorized administrator. However, 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 Security Administrators (a.k.a 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 specific management capabilities available from the TOE include;  Local and remote administration of the TOE and the services provided by the TOE via the TOE CLI, as described above;  The ability to manage the warning banner message and content which allows the Authorized Administrator the ability to define warning banner 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 IOS software. The validity of the image is provided using SHA-512;  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 o allow any network packets as configured by the authorized administrator may flow through the switch prior to the identification and authentication process;  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 configure the IPsec functionality which supports the secure connections to the audit server and the remote authentication server;  The ability to import the X.509v3 certificates and validate for use in authentication and secure connections and  The ability to configure and set the time clock. FMT_SMR.2 The TOE maintains Authorizer Administrators that include privileged and semi- privileged administrator roles to administer the TOE locally and remotely. The TOE performs role-based authorization, using TOE platform authorization mechanisms, to grant access to the privileged and semi-privileged roles. For the purposes of this evaluation, the privileged role is equivalent to full administrative access to the CLI, which is the default access for IOS privilege level 15; and the semi- privileged role equates to any privilege level that has a subset of the privileges assigned to level 15. Privilege levels 0 and 1 are defined by default and are customizable, while levels 2-14 are undefined by default and also customizable. Note: the levels are not theoretically hierarchical. Cisco Catalyst 4500 Wired Access Switches 56 TOE SFRs How the SFR is Met The term “Authorized Administrator” is used 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 privilege level determines the functions the user can perform; hence the Authorized Administrator with the appropriate privileges. The TOE can and shall be configured to authenticate all access to the command line interface using a username and password. The TOE supports both local administration via a directly connected console cable and remote authentication via SSHv2 secure connection. FPT_SKP_EXT.1 The command service password-encryption applies encryption to all passwords, including username passwords, authentication key passwords, the privileged command password, console and virtual terminal line access passwords. During the setup and configuration of the TOE and the generation of keys, the TOE stores all private keys in a secure directory that is not readily accessible to administrators; hence no interface access. Additionally, all pre-shared and symmetric keys are stored in encrypted form to prevent access. Refer to the Common Criteria Operational User Guidance and Preparative Procedures for command description and usage information. FPT_APW_EXT.1 FPT_STM.1 The TOE provides a source of date and time information used in audit event timestamps. The clock function is reliant on the system clock provided by the underlying hardware. This date and time is used as the time stamp that is applied to TOE generated audit records and used to track inactivity of administrative sessions. This system clock is also used for cryptographic functions such as limiting SAs based on times. FPT_TUD_EXT.1 The TOE has specific versions that can be queried by an administrator. When updates are made available by Cisco, an administrator can obtain and install those updates. The updates can be downloaded from the Cisco.com web site. Authorized Administrators can download the approved image file from Cisco.com onto a trusted computer system for usage in the trusted update functionality. Detailed instructions for how to do this verification are provided in the administrator guidance for this evaluation. The software version information for the TOE specific image can be displayed using the following commands: The administrator in privileged EXEC mode enters Switch# show version ( this displays information about the Cisco IOS software version running on the TOE the ROM Monitor and Bootflash software versions, and the hardware configuration, including the amount of system memory). Cisco provides the SHA-512 hash value for all Cisco IOS Software releases that are published on Cisco.com. Administrators can compare the SHA-512 value published on Cisco.com and the SHA-512 value calculated by a third-party utility to verify the integrity of a Cisco IOS image. The following Cisco document provides information on SHA512 verification using a third-party utility in section "Using Offline Image File Hashes", https://www.cisco.com/c/en/us/about/security-center/integrity- assurance.html#10. Cisco Catalyst 4500 Wired Access Switches 57 TOE SFRs How the SFR is Met If the third-party tool displays a hash that matches the Cisco.com SHA-512 hash, the file has successfully been verified. If the third-party tool displays a hash that does not match the Cisco.com hash, the file has failed verification and should not be deployed. FPT_TST_EXT.1 The TOE runs a suite of self-tests during initial start-up to verify its correct operation. If any of the tests fail, the Authorized Administrator will have to log into the CLI to determine which test failed and why. During the system bootup process (power on or reboot), all the Power on Startup Test (POST) components for all the cryptographic modules perform the POST for the corresponding component (hardware or software). These tests include:  Power-on Self-Tests: o Firmware Integrity Test – the firmware integrity test ensures the correct operation of the device and its components o Known Answer Tests:  AES Known Answer Test - For the encrypt test, a known key is used to encrypt a known plain text value resulting in an encrypted value. This encrypted value is compared to a known encrypted value to ensure that the encrypt operation is working correctly. The decrypt test is just the opposite. In this test a known key is used to decrypt a known encrypted value. The resulting plaintext value is compared to a known plaintext value to ensure that the decrypt operation is working correctly.  RNG/DRBG Known Answer Test - For this test, known seed values are provided to the DRBG implementation. The DRBG uses these values to generate random bits. These random bits are compared to known random bits to ensure that the DRBG is operating correctly.  HMAC Known Answer Test - For each of the hash values listed, the HMAC implementation is fed known plaintext data and a known key. These values are used to generate a MAC. This MAC is compared to a known MAC to verify that the HMAC and hash operations are operating correctly.  KAS ECC KAT - Also known as the ‘ECC Primitive “Z” KAT’, the KAT shall be performed on the point multiplication for the ECC-based protocol (per SP 800- 56A, Section 5.7.1.2).  KAS FFC KAT - Also known as the 'FFC Primitive "Z" KAT', the KAT shall be performed on the underlying mathematical function(s) which use modular exponentiation for an FFC-based key establishment protocol (per SP 800-56A, Section 5.7.1.1).  RSA Signature Known Answer Test (both signature/verification) - This test takes a known plaintext value and Private/Public key pair and used the public key to encrypt the data. This value is compared to a known encrypted value to verify that encrypt operation is working properly. The encrypted data is then decrypted using the private key. This value is compared to the original Cisco Catalyst 4500 Wired Access Switches 58 TOE SFRs How the SFR is Met plaintext value to ensure the decrypt operation is working properly.  SP 800-56B RSA key wrap/unwrap KAT - The module has an RSA encryption pre-computed and then, while performing a power-up self-test, the module performs the RSA encryption again and compares the newly-generated result to the pre-computed value. The module also has a separate known answer for the RSA decryption by starting with a given value representing an RSA encryption and decrypting this value using the RSA algorithm. The result of said decryption operation is compared to a pre- computed result. If any component reports failure for the POST, the system crashes and appropriate information is displayed on the screen, and saved in the crashinfo file. All ports are blocked from moving to forwarding state during the POST. If all components of all modules pass the POST, the system is placed in FIPS PASS state and ports are allowed to forward data traffic.  Conditional Self-Tests (run periodically during normal operation): o Continuous Random Number Generator test for DRBG - The first n-bit block generated after power-up, initialization, or reset shall not be used, but shall be saved for comparison with the next n-bit block to be generated. Each subsequent generation of an n-bit block shall be compared with the previously generated block. The test shall fail if any two compared n-bit blocks are equal. o Continuous Random Number Generator test for Entropy Source - This test functions precisely the same as the CRNGT for the DRBG (described above) except that input to the test is taken from the Entropy Source output as opposed to the DRBG output. o RSA Pairwise Consistency Test - Each time a new RSA public/private keypair is generated, the public key is used to encrypt a plaintext value. The resulting ciphertext value is then compared to the original plaintext value. If the two values are equal, then the test is considered to have failed. If the two values differ, then the private key is used to decrypt the ciphertext and the resulting value is then compared to the original plaintext value. If the two values are not equal, the test is considered to have failed. o Bypass Test – the bypass test involves testing correct operation providing crypto services when a switch takes place between bypass services and crypto services. In short, the crypto series, gets tested normally overtime a bypass occurs and the returns. An example is AES known answer test gets run at start. Then the module moves to bypass crypto services. Then returns back to crypto devices and the AES known answer test is immediately run. The combination of these tests are sufficient to verify that the correct version of the TOE is running as well as that the cryptographic operations are all performing as expected. FTA_SSL_EXT.1 Cisco Catalyst 4500 Wired Access Switches 59 TOE SFRs How the SFR is Met FTA_SSL.3 An Authorized 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 and virtual terminal (vty) lines. The configuration of the vty lines sets the configuration for the remote console access. The line console 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 locked and will require re-authentication to unlock the 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. Administratively configurable timeouts are also available for the EXEC level access (access above level 1) through use of the “exec-timeout” setting. The allowable inactivity timeout range is from 1 to 65535 seconds. FTA_SSL.4 An Authorized Administrator is able to exit out of both local and remote administrative sessions by issuing the ‘exit’ command. FTA_TAB.1 Authorized administrators define a custom login banner that will be displayed at the CLI (local and remote) prior to allowing Authorized Administrator access through those interfaces. FTP_ITC.1 The TOE protects communications with authorized IT entities such as the remote audit server and remote authentication servers with IPsec. This protects the data from disclosure by encryption and by checksums that verify that data has not been modified. The TOE protects communications using keyed hash as defined in FCS_COP.1/KeyedHash and cryptographic hashing functions FCS_COP.1/Hash. This protects the data from modification by hashing then verifying that data has not been modified in transit. In addition, encryption of the data as defined in FCS_COP.1/DataEncryption is provided to ensure the data is not disclosed in transit. The TSF allows the TSF, or the authorized IT entities to initiate communication via the trusted channel. FTP_TRP.1/Admin All remote administrative communications take place over a secure encrypted SSHv2 session. The SSHv2 session is encrypted using AES encryption. The remote users (Authorized Administrators) are able to initiate SSHv2 communications with the TOE. Cisco Catalyst 4500 Wired Access Switches 60 7 ANNEX A: KEY ZEROIZATION 7.1 Key Zeroization The following table describes the key zeroization referenced by FCS_CKM.4 provided by the TOE. Table 20 TOE Key Zeroization Name Description Zeroization Diffie-Hellman Shared Secret This is the shared secret used as part of the Diffie-Hellman key exchange. This key is stored in DRAM. Automatically after completion of DH exchange. Overwritten with: 0x00 Diffie Hellman private exponent This is the private exponent used as part of the Diffie-Hellman key exchange. This key is stored in DRAM. Zeroized upon completion of DH exchange. Overwritten with: 0x00 skeyid This is an IKE intermittent value used to create skeyid_d. This information is stored in DRAM. This information and keys are stored in DRAM. Automatically after IKE session terminated. Overwritten with: 0x00 skeyid_d This is an IKE intermittent value used to derive keying data for IPsec. This information and keys are stored in DRAM. Automatically after IKE session terminated. Overwritten with: 0x00 IKE session encrypt key This the key IPsec key used for encrypting the traffic in an IPsec connection. This key is stored in DRAM. Automatically after IKE session terminated. Overwritten with: 0x00 IKE session authentication key This the key IPsec key used for authenticating the traffic in an IPsec connection. This key is stored in DRAM. Automatically after IKE session terminated. Overwritten with: 0x00 ISAKMP preshared This is the configured pre-shared key for ISAKMP negotiation. This key is stored in DRAM. Zeroized using the following command: # no crypto isakmp key Overwritten with: 0x0d IKE RSA Private Key The RSA private-public key pair is created by the device itself using the key generation CLI described below. The device’s public key must be added into the device certificate. The device’s certificate is created by creating a trustpoint on the device. This trustpoint authenticates with the CA server to get the CA certificate and to enrol with the CA server to generate the device certificate. Zeroized using the following command: # crypto key zeroize rsa Overwritten with: 0x0d Cisco Catalyst 4500 Wired Access Switches 61 Name Description Zeroization In the IKE authentication step, the device’s certificate is first sent to other device so that it can be authenticated. The other device verifies the certificate is signed by CA’s signing key, and then the device sends a random secret encrypted by the device’s public key in the valid device certificate. Thus, establishing the trusted connection since only the device with the matching device private key can decrypt the message and obtain the random secret. This key is stored in NVRAM. IPsec encryption key This is the key used to encrypt IPsec sessions. This key is stored in DRAM. Automatically when IPsec session terminated. Overwritten with: 0x00 IPsec authentication key This is the key used to authenticate IPsec sessions. This key is stored in DRAM. Automatically when IPsec session terminated. Overwritten with: 0x00 RADIUS secret Shared secret used as part of the Radius authentication method. The password is stored in NVRAM. Zeroized using the following command: # no radius-server key Overwritten with: 0x0d SSH Private Key This is the private (secret) key of the asymmetric key pair required to establish the secure SSH session. The key is stored in NVRAM. Zeroized using the following command: # crypto key zeroize rsa Overwritten with: 0x00 SSH Session Key Once the function has completed the operations requiring the RSA key object, the module over writes the entire object (no matter its contents). This key is stored in DRAM. 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 Cisco Catalyst 4500 Wired Access Switches 62 8 ANNEX B: REFERENCES The following documentation was used to prepare this ST: Table 21 References Identifier Description [CC_PART1] Common Criteria for Information Technology Security Evaluation – Part 1: Introduction and general model, dated September 2012, version 3.1, Revision 4 [CC_PART2] Common Criteria for Information Technology Security Evaluation – Part 2: Security functional components, dated September 2012, version 3.1, Revision 4 [CC_PART3] Common Criteria for Information Technology Security Evaluation – Part 3: Security assurance components, September 2012, version 3.1, Revision 4 [CEM] Common Methodology for Information Technology Security Evaluation – Evaluation Methodology, September 2012, version 3.1, Revision 4 [NDcPP] collaborative Protection Profile for Network Devices + Errata 20180314, Version 2.0e, 14 March 2018 [800-56A] NIST Special Publication 800-56A, March, 2007 Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography (Revised) [800-56B] NIST Special Publication 800-56B Recommendation for Pair-Wise, August 2009 Key Establishment Schemes Using Integer Factorization Cryptography [800-90] NIST Special Publication 800-90A Recommendation for Random Number Generation Using Deterministic Random Bit Generators January 2012 [FIPS 140-2] FIPS PUB 140-2 Federal Information Processing Standards Publication [FIPS PUB 180-3] FIPS PUB 180-3 Federal Information Processing Standards Publication Secure Hash Standard (SHS) October 2008 [FIPS PUB 186-4] FIPS PUB 186-3 Federal Information Processing Standards Publication Digital Signature Standard (DSS) June, 2013 [FIPS PUB 198-1] Federal Information Processing Standards Publication The Keyed-Hash Message Authentication Code (HMAC) July 2008