Cisco Catalyst 3560-CX Switch FIPS 140-2 Non Proprietary Security Policy Level 1 Validation Version 0.4 August 24, 2016 © Copyright 2016 Cisco Systems, Inc. This document may be freely reproduced and distributed whole and intact including this Copyright Notice. Table of Contents 1 INTRODUCTION.................................................................................................................. 3 1.1 PURPOSE ............................................................................................................................. 3 1.2 MODULE VALIDATION LEVEL ............................................................................................ 3 1.3 REFERENCES ....................................................................................................................... 3 1.4 TERMINOLOGY ................................................................................................................... 4 1.5 DOCUMENT ORGANIZATION ............................................................................................... 4 2 CISCO CATALYST 3560-CX SWITCH ............................................................................. 4 2.1 CRYPTOGRAPHIC MODULE PHYSICAL CHARACTERISTICS .................................................. 4 2.2 CRYPTOGRAPHIC BOUNDARY ............................................................................................. 5 2.3 MODULE INTERFACES ......................................................................................................... 5 3 ROLES, SERVICES, AND AUTHENTICATION ............................................................. 6 3.1 USER ROLE ......................................................................................................................... 6 3.2 CRYPTO OFFICER ROLE ...................................................................................................... 7 3.3 UNAUTHORIZED ROLE ........................................................................................................ 9 3.4 SERVICES AVAILABLE IN NON-FIPS MODE OF OPERATION................................................ 9 4 PHYSICAL SECURITY........................................................................................................ 9 5 CRYPTOGRAPHIC ALGORITHMS ............................................................................... 10 5.1 APPROVED CRYPTOGRAPHIC ALGORITHMS ...................................................................... 10 5.2 NON-FIPS APPROVED, BUT ALLOWED CRYPTOGRAPHIC ALGORITHMS ........................... 10 5.3 NON-FIPS APPROVED AND NOT ALLOWED CRYPTOGRAPHIC ALGORITHMS .................... 11 5.4 SELF-TESTS ...................................................................................................................... 11 6 CRYPTOGRAPHIC KEY/CSP MANAGEMENT........................................................... 12 TABLE 8 - CRYPTOGRAPHIC KEYS AND CSPS............................................................... 16 7 SECURE OPERATION OF THE C3560-CX SWITCH .................................................. 16 7.1 SYSTEM INITIALIZATION AND CONFIGURATION ................................................................ 16 7.2 REMOTE ACCESS .............................................................................................................. 17 8 DEFINITION LIST ............................................................................................................. 17 2 © Copyright 2016 Cisco Systems, Inc. This document may be freely reproduced and distributed whole and intact including this Copyright Notice. 1 Introduction 1.1 Purpose This document is the non-proprietary Cryptographic Module Security Policy for the Cisco Catalyst 3560-CX Switch. This security policy describes how the modules listed below meet the security requirements of FIPS 140-2, and how to operate the switch with on-board crypto enabled in a secure FIPS 140-2 mode. Modules covered in this document are listed below: Cisco Catalyst WS-3560CX-8TC-S running IOS Firmware Version - 15.2(3)E1 This policy was prepared as part of the Level 1 FIPS 140-2 validation of the Catalyst 3560-CX Switch. FIPS 140-2 (Federal Information Processing Standards Publication 140-2 — Security Requirements for Cryptographic Modules) details the U.S. Government requirements for cryptographic modules. More information about the FIPS 140-2 standard and validation program is available on the NIST website at http://csrc.nist.gov/groups/STM/index.html. 1.2 Module Validation Level The following table lists the level of validation for each area in the FIPS PUB 140-2. No. Area Title Level 1 Cryptographic Module Specification 1 2 Cryptographic Module Ports and Interfaces 1 3 Roles, Services, and Authentication 2 4 Finite State Model 1 5 Physical Security 1 6 Operational Environment N/A 7 Cryptographic Key management 1 8 Electromagnetic Interface/Electromagnetic Compatibility 1 9 Self-Tests 1 10 Design Assurance 1 11 Mitigation of Other Attacks N/A Overall module validation level 1 Table 1- Module Validation Level 1.3 References This document deals only with operations and capabilities of the module in the technical terms of a FIPS 140-2 cryptographic module security policy. More information is available on the switch from the following sources: The Cisco Systems website contains information on the full line of Cisco products. Please refer to the following websites for: Catalyst 3560-CX switch - http://www.cisco.com/c/en/us/products/switches/catalyst-3560-cx-series-switches/index.html For answers to technical or sales related questions, please refer to the contacts listed on the Cisco Systems website at www.cisco.com. 3 © Copyright 2016 Cisco Systems, Inc. This document may be freely reproduced and distributed whole and intact including this Copyright Notice. The NIST Validated Modules website (http://csrc.nist.gov/groups/STM/cmvp/validation.html) contains contact information for answers to technical or sales-related questions for the module. 1.4 Terminology In this document, the Catalyst 3560-CX switch is referred to as C3560-CX, the switch or the module. 1.5 Document Organization The Security Policy document is part of the FIPS 140-2 Submission Package. In addition to this document, the Submission Package contains: Vendor Evidence document Finite State Machine Other supporting documentation as additional references This document provides an overview of the Cisco Catalyst 3560-CX switch and explains the secure configuration and operation of the module. This introduction section is followed by Section 2, which details the general features and functionality of the switch. Section 3 specifically addresses the required configuration for the FIPS-mode of operation. With the exception of this Non-Proprietary Security Policy, the FIPS 140-2 Validation Submission Documentation is Cisco-proprietary and is releasable only under appropriate non- disclosure agreements. For access to these documents, please contact Cisco Systems. 2 Cisco Catalyst 3560-CX Switch The compact Cisco® Catalyst® 3560-CX Switch easily extends an intelligent, fully managed Cisco Catalyst wired switching infrastructure, including end-to-end IP and Borderless Network services, with a single Ethernet cable or fiber from the wiring closet. These attractive, small form-factor Gigabit and Fast Ethernet switches are ideal for connecting multiple devices: wherever space is at a premium and multiple cable runs could be challenging. This switch delivers advanced Layer 2 switching with intelligent Layer 2 through 4 services for the network edge, such as voice, video, and wireless LAN services, including support for routed access, Cisco TrustSec®, and other Cisco Borderless Network services. Catalyst 3560-CX implements MACsec, but the feature is not available in FIPS mode of operation. The Catalyst 3560-CX Switch meets FIPS 140-2 overall Level 1 requirements as a multi-chip standalone module. 2.1 Cryptographic Module Physical Characteristics The C3560-CX switch is a small form factor, fixed chassis switch. This fanless, small form- factor switch is ideal for space-constrained deployments where multiple cable runs would be challenging. C3560-CX is a Gigabit Ethernet (GbE) managed switch, which is ideal for high- speed data connectivity and Wi-Fi backhaul. With a single copper or fiber cable from the wiring closet, this Cisco Catalyst compact switch enables IP connectivity for devices such as IP phones, wireless access points, surveillance cameras, PCs, and video endpoints. 4 © Copyright 2016 Cisco Systems, Inc. This document may be freely reproduced and distributed whole and intact including this Copyright Notice. Figure 1- Cisco C3560-CX Switch 2.2 Cryptographic Boundary The cryptographic boundary is defined as being the physical enclosure of the chassis. All of the functionality described in this publication is provided by components within this cryptographic boundary. 2.3 Module Interfaces The module provides a number of physical and logical interfaces to the device, and the physical interfaces provided by the module are mapped to four FIPS 140-2 defined logical interfaces: data input, data output, control input, and status output. The module also supports a power interface. The following table identifies the features on the module covered by this Security Policy: Model Ethernet Ports PoE Available Uplinks Output Ports PoE Power 3560CX-8TC-S 8 x 10/100/1000 Gigabit N/A 2x1G copper plus Ethernet 2x1G SFP Table 2 - C3560-CX Interface Information Note: Cisco Catalyst 3560-CX includes hardware for IEEE 802.1AE MACsec for Layer 2, line- rate Ethernet data confidentiality and integrity on host-facing ports. But the capability has not been tested for FIPS 140-2. The module provides a number of physical and logical interfaces to the device, and the physical interfaces provided by the module are mapped to the following FIPS 140-2 defined logical interfaces: data input, data output, control input, status output, and power. The logical interfaces and their mapping are described in Table 3 below: 5 © Copyright 2016 Cisco Systems, Inc. This document may be freely reproduced and distributed whole and intact including this Copyright Notice. Physical Interface Logical Interface Ethernet Ports (RJ45) Data Input Interface Copper Gigabit Ports SFP Ports Type A USB port Console Port (RJ45 and USB Type B) Ethernet Ports (RJ45) Data Output Interface Copper Gigabit Ports SFP Ports Type A USB port Console Port (RJ45 and USB Type B) Ethernet Ports (RJ45) Control Input Interface Copper Gigabit Ports SFP Ports Console Port (RJ45 and USB Type B) Reset Button Copper Gigabit Ports Status Output Interface SFP Ports Console Port (RJ45 and USB Type B) LEDs Power Plug Power Interface Table 3 - Module Interfaces 3 Roles, Services, and Authentication Authentication is role-based. Each user is authenticated upon initial access to the module. There are two roles in the switch that may be assumed: the Crypto Officer (CO) role and the User role. The administrator of the switch assumes the CO role in order to configure and maintain the switch using CO services, while the Users exercise security services over the network. 3.1 User Role The role is assumed by users obtaining general security services. From a logical view, user activity exists in the data-plane. Users are authenticated using a password and their data is protected with secure communication protocol such as IPsec. The user passwords must be at least eight (8) characters long, including at least one letter and at least one number character (enforced procedurally). If six (6) special/alpha/number characters, one (1) special character and one (1) number are used without repetition for an eight (8) digit value, the probability of randomly guessing the correct sequence is one (1) in 187,595,543,116,800. This is calculated by performing 94 x 93 x 92 x 91 x 90 x 89 x 32 x 10. Therefore, the associated probability of a successful random attempt is approximately 1 in 187,595,543,116,800, which is less than 1 in 1,000,000 required by FIPS 140-2. In order to successfully guess the sequence in one minute would require the ability to make over 3,126,592,385,280 guesses per second, which far exceeds the operational capabilities of the module. The User role can also be authenticated via certificate credentials by using 2048 bit RSA keys – in such a case the security strength is 112 bits, so the associated probability of a successful random attempt is 1 in 2112, which is less than 1 in 1,000,000 required by FIPS 140-2. To exceed a one in 100,000 probability of a successful random key guess in one minute, an attacker would have to be 6 © Copyright 2016 Cisco Systems, Inc. This document may be freely reproduced and distributed whole and intact including this Copyright Notice. capable of approximately 8.65x1031 attempts per second, which far exceeds the operational capabilities of the module to support. The services available to the User role accessing the CSPs, the type of access – read (r), write (w) and zeroized/delete (d) – and which role accesses the CSPs are listed below: Services Description Keys and CSPs Access IPsec VPN Negotiation and User password, skeyid, skeyid_d, SKEYSEED, IKE session encrypt encrypted data transport key, IKE session authentication key, ISAKMP preshared, IKE via IPSec VPN authentication private Key, IKE authentication public key, IPsec encryption key, IPsec authentication key, DRBG entropy input, DRBG Seed, DRBG V, DRBG Key (r, w, d) Table 4 - User Services 3.2 Crypto Officer Role This role is assumed by an authorized CO connecting to the switch via CLI through the console port and performing management functions and module configuration. From a logical view, CO activity exists only in the control plane. IOS prompts the CO for their username and password, and, if the password is validated against the CO’s password in IOS memory, the CO is allowed entry to the IOS executive program. The module supports RADIUS and TACACS+ for authentication of CO. CO passwords must be at least eight (8) characters long, including at least one letter and at least one number character (enforced procedurally). If six (6) special/alpha/number characters, one (1) special character and one (1) number are used without repetition for an eight (8) digit value, the probability of randomly guessing the correct sequence is one (1) in 187,595,543,116,800. This is calculated by performing 94 x 93 x 92 x 91 x 90 x 89 x 32 x 10. Therefore, the associated probability of a successful random attempt is approximately 1 in 187,595,543,116,800, which is less than 1 in 1,000,000 required by FIPS 140-2. In order to successfully guess the sequence in one minute would require the ability to make over 3,126,592,385,280 guesses per second, which far exceeds the operational capabilities of the module. The Crypto Officer role is responsible for the configuration of the switch. The services available to the Crypto Officer role accessing the CSPs, the type of access – read (r), write (w) and zeroized/delete (d) – and which role accesses the CSPs are listed below: Services Description Keys and CSPs Access Configure Define network interfaces and settings, create Enable password (r, w, d) command aliases, set the protocols the switch will support, enable interfaces and network services, set system date and time, and load authentication information. Manage Log off users, shutdown or reload the switch, Enable password (r, w, d) manually back up switch configurations, view complete configurations, manage user rights, and restore switch configurations. 7 © Copyright 2016 Cisco Systems, Inc. This document may be freely reproduced and distributed whole and intact including this Copyright Notice. Services Description Keys and CSPs Access Define Rules and Create packet Filters that are applied to User Enable password (r, w, d) Filters data streams on each interface. Each Filter consists of a set of Rules, which define a set of packets to permit or deny based on characteristics such as protocol ID, addresses, ports, TCP connection establishment, or packet direction. View Status View the switch configuration, routing tables, Enable password (r, w, d) Functions active sessions, health, temperature, memory status, voltage, packet statistics; review accounting logs; and view physical interface status. Configure Set up the configuration tables for IP IKE session encrypt key, IKE session Encryption/Bypass tunneling. Set preshared keys and algorithms authentication key, ISAKMP preshared, IKE to be used for each IP range or allow plaintext authentication private Key, IKE packets to be set from specified IP address. authentication public key, skeyid, skeyid_d, SKEYSEED, IPsec encryption key, IPsec authentication key (r, w, d) Configure Remote Set up authentication account for users and RADIUS secret, RADIUS Key wrap key, Authentication devices using RADIUS or TACACS+. TACACS+ secret (r, w, d) HTTPs HTTP server over TLS (1.0). TLS Server RSA private key, TLS Server RSA public key, TLS pre-master secret, TLS session keys, TLS authentication keys, DRBG entropy input, DRBG Seed, DRBG V, DRBG Key (r, w, d) SSH v2 Configure SSH v2 parameter, provide entry DH private DH public key, DH Shared and output of CSPs. Secret, SSH RSA private key, SSH RSA public key, SSH session key, SSH session authentication key, DRBG entropy input, DRBG Seed, DRBG V, DRBG Key (r, w, d) SNMPv3 Configure SNMPv3 MIB and monitor status. SNMPv3 Password, snmpEngineID, SNMP session key, DRBG entropy input, DRBG Seed, DRBG V, DRBG Key (r, w, d) IPsec VPN Configure IPsec VPN parameters, provide skeyid, skeyid_d, SKEYSEED, IKE session entry and output of CSPs. encrypt key, IKE session authentication key, ISAKMP preshared, IKE authentication private Key, IKE authentication public key, IPsec encryption key, IPsec authentication key, DRBG entropy input, DRBG Seed, DRBG V, DRBG Key (r, w, d) Self-Tests Execute the FIPS 140 start-up tests on N/A demand. User services The Crypto Officer has access to all User User Password (r, w, d) services. Zeroization Zeroize cryptographic keys/CSPs by running All CSPs (d) the zeroization methods classified in table 8, Zeroization column. Table 5 - Crypto Officer Services 8 © Copyright 2016 Cisco Systems, Inc. This document may be freely reproduced and distributed whole and intact including this Copyright Notice. 3.3 Unauthorized Role The services for someone without an authorized role are: passing traffic through the device, view the status output from the module’s LED pins, and cycle power. 3.4 Services Available in Non-FIPS Mode of Operation The cryptographic module in addition to FIPS mode of operation can operate in a non-FIPS mode of operation. This is not a recommended operational mode but because the associated RFC’s for the following protocols allow for non-approved algorithms and non-approved key sizes a non-approved mode of operation exist. The module is considered to be in a non-FIPS mode of operation when it is not configured per section 7. The FIPS approved services listed in table 6 become non-approved services when using any non-approved algorithms or non- approved key or curve sizes. Services 1 Non-Approved Algorithms Hashing: MD5 MACing: HMAC-MD5 IPsec Symmetric: DES, RC4 Asymmetric: 768-bit/1024-bit RSA (key transport), 1024-bit Diffie-Hellman Hashing: MD5 MACing: HMAC-MD5 SSH Symmetric: DES Asymmetric: 768-bit/1024-bit RSA (key transport), 1024-bit Diffie-Hellman Symmetric: DES, RC4 TLS Asymmetric: 768-bit/1024-bit RSA (key transport), 1024-bit Diffie-Hellman Hashing: MD5 SNMP Symmetric: DES v1/v2 AES GCM MACsec Table 6 - Non-approved algorithms in the Non-FIPS mode services Note: The AES GCM supporting MACsec service is a non-compliant algorithm. Neither the User nor the Crypto Officer are allowed to operate any of these services while in FIPS mode of operation. 4 Physical Security The module is a multi-chip standalone cryptographic module. The module meets FIPS 140-2 level 1 physical security requirements as production grade equipment. 1 These approved services become non-approved when using any of non-approved algorithms or non-approved key or curve sizes. When using approved algorithms and key sizes these services are approved. 9 © Copyright 2016 Cisco Systems, Inc. This document may be freely reproduced and distributed whole and intact including this Copyright Notice. 5 Cryptographic Algorithms 5.1 Approved Cryptographic Algorithms The switch supports many different cryptographic algorithms. However, only FIPS approved algorithms may be used while in the FIPS mode of operation. Table 7 below identifies the approved algorithms included in the module for use in the FIPS mode of operation. Algorithm Algorithm Implementation Name IOS Common Cryptographic Module (IC2M) Algorithm Module (Firmware) AES (CBC, GCM; 128, 192, 256 bits) #3984 and #4016 Triple-DES (CBC, 3-key, 192 bits) #2187 SHS (SHA-1/256/384/512) #3289 HMAC (SHA-1) #2600 RSA (FIPS 186-4 KeyGen; PKCS1_V1_5; 2048 #2045 bits; Signature Generation/Verification) DRBG (SP 800-90A AES CTR-256) #1177 CVL Component (SP800-135 KDF for IKEv2, #813 TLSv1.0, SSH, SNMPv3) Table 7- Approved Cryptographic Algorithms and Associated Certificate Number Notes:  There are some algorithm modes that were tested but not implemented by the module. Only the algorithms, modes, and key sizes that are implemented by the module are shown in Table 7.  The AES-GCM IV generation method from AES #4016 is in compliance with IG A.5, scenario #1. The module is in compliance with the RFC 6071 (IPSec Protocol). The module generates new AES-GCM keys if the module loses power.  The SSH, TLSv1.0, SNMPv3 and IKEv2 protocols have not been reviewed or tested by the CAVP and CMVP. 5.2 Non-FIPS Approved, but Allowed Cryptographic Algorithms The cryptographic module implements the following non-approved algorithms, but they are allowed to be used in a FIPS 140-2 mode of operation.  Diffie-Hellman (key agreement; key establishment methodology provides between 112 and 150 bits of encryption strength)  RSA (key wrapping; key establishment methodology provides 112 bits of encryption strength)  AES (Cert. #3984, key wrapping; key establishment methodology provides 128 or 256 bits of encryption strength)  NDRNG (entropy source for DRBG; at minimum 256 bits can be obtained)  HMAC-MD5 is allowed in FIPS mode strictly for TLS  MD5 is allowed in FIPS mode strictly for TLS 10 © Copyright 2016 Cisco Systems, Inc. This document may be freely reproduced and distributed whole and intact including this Copyright Notice. Notes:  The AES key wrapping method is not compliant with SP 800-38F. 5.3 Non-FIPS Approved and not Allowed Cryptographic Algorithms The cryptographic module implements the following non-approved algorithms that are not permitted for use in FIPS 140-2 mode of operation:  AES GCM (non-compliant)  DES  Diffie-Hellman (key agreement; non-compliant less than 112 bits of encryption strength)  HMAC-MD5  MD5  RC4  RSA (key wrapping; non-compliant less than 112 bits of encryption strength) 5.4 Self-Tests The module includes an array of self-tests that are run during startup and periodically during operations to prevent any secure data from being released and to ensure all components are functioning correctly. The module implements the following power-on self-tests:  IOS Power-On Self-Tests Known Answer Tests (KATs): o AES (encryption and decryption) KATs o AES-CMAC KAT o AES-GCM (encryption and decryption) KATs o AES-256 CTR DRBG KAT o HMAC-SHA-1 KAT o DRBG health test (Note: DRBG Health Tests as specified in SP800-90A Section 11.3 are performed) o SHA-1 KAT o SHA-256 KAT o SHA-512 KAT o RSA (sign and verify) KATs o Triple-DES (encryption and decryption) KATs  Firmware Integrity Test o RSA PKCS#1 v1.5 (2048 bits) signature verification with SHA-256 The module performs all power-on self-tests automatically at boot. All power-on self-tests must be passed before any operator can perform cryptographic services. The power-on self-tests are performed after the cryptographic systems are initialized but prior to any other operations; this prevents the module from passing any data during a power-on self-test failure. 11 © Copyright 2016 Cisco Systems, Inc. This document may be freely reproduced and distributed whole and intact including this Copyright Notice. In addition, the modules also provide the following conditional self-tests:  Continuous Random Number Generator Test (CRNGT) for SP800-90A DRBG  CRNGT for the NDRNG  Pairwise Consistency Test for RSA  Conditional IPSec Bypass Test 6 Cryptographic Key/CSP Management The module securely administers both cryptographic keys and other critical security parameters such as passwords. All keys are also protected by the password-protection on the CO role login, and can be zeroized by the CO. Keys are exchanged and entered electronically. Persistent keys are entered by the CO via the console port CLI, transient keys are generated or established and stored in DRAM. Note that the command fips zeroize all will zeroize a large majority of the listed CSPs. The module supports the following cryptographic keys and critical security parameters (CSPs): 12 © Copyright 2016 Cisco Systems, Inc. This document may be freely reproduced and distributed whole and intact including this Copyright Notice. ID Algorithm Description Storage Zeroization Method General Keys/CSPs Enable password Password Variable (8+ characters). The NVRAM Zeroized by password used to authenticate the (plaintext) overwriting with new CO role. This CSP is entered by the password Crypto Officer. User password Password Variable (8+ characters). The NVRAM Zeroized by password used to authenticate the (plaintext) overwriting with new User role. This CSP is created by password the CO role and entered by the User role. Zeroized by “# no RADIUS secret Shared Secret Variable (8+ characters). The NVRAM RADIUS shared secret is used for (plaintext) radius-server key” RADIUS Client/Server command authentication. This CSP is entered by the Crypto Officer. RADIUS Key wrap AES-CBC 128/256 bits. Secures DRAM Zeroized when data key communication with RADIUS (plaintext) structure is freed authentication server. This CSP is derived from the RADIUS secret. Zeroized by “# no TACACS+ secret Shared Secret Variable (8+ characters). The NVRAM TACACS+ shared secret is used for (plaintext) tacacs-server key” TACACS+ Client/Server command authentication. This CSP is entered by the Crypto Officer. DRBG entropy input SP 800-90A 256-bits. HW based entropy source DRAM Automatically when CTR_DRBG output used to construct the seed. (plaintext) the switch is power cycled DRBG Seed SP 800-90A 384-bits. Generated using DRBG DRAM Automatically when CTR_DRBG derivation function that includes (plaintext) the switch is power the entropy input from hardware- cycled based entropy source. DRBG V SP 800-90A 128-bits. Generated by entropy DRAM Automatically when CTR_DRBG source via the CTR_DRBG (plaintext) the switch is power derivation function. It is stored in cycled DRAM with plaintext form DRBG Key SP 800-90A 256-bits. This is the 256-bit DRBG DRAM Automatically when CTR_DRBG key used for SP 800-90A (plaintext) the switch is power CTR_DRBG. Established per SP cycled 800-90A CTR_DRBG. Diffie-Hellman Diffie-Hellman 224-379 bits DH private key used DRAM Automatically after private key in Diffie-Hellman (DH) exchange. (plaintext) shared secret Generated by calling the SP 800- generated. 90A CTR-DRBG. 13 © Copyright 2016 Cisco Systems, Inc. This document may be freely reproduced and distributed whole and intact including this Copyright Notice. Diffie-Hellman Diffie-Hellman 2048-4096 bits DH private key DRAM Automatically after public key used in Diffie-Hellman (DH) (plaintext) shared secret exchange. Generated by calling the generated. SP 800-90A CTR-DRBG. Diffie-Hellman Diffie-Hellman 2048-4096 bits. DH shared secret DRAM Zeroized upon Shared Secret derived in Diffie-Hellman (DH) (plaintext) deletion exchange. SSH Zeroized by “# fips SSH RSA private RSA 2048 bits. The SSHv2 private key NVRAM zeroize all” command key used in SSHv2 connection. This (plaintext) key is generated by calling SP 800- 90A DRBG. Zeroized by “# fips SSH RSA public RSA 2048 bits. The SSHv2 public key NVRAM zeroize all” command key used in SSHv2 connection. This (plaintext) key is internally generated by the module. SSH session key Triple- 192-bits/256-bits. This is the DRAM Automatically when DES/AES SSHv2 session key. It is used to (plaintext) SSH session encrypt all SSHv2 data traffic terminated traversing between the SSHv2 Client and SSHv2 Server. This key is derived via key derivation function defined in SP800-135 KDF (SSH). SSH session HMAC SHA 160-bits. It is used to authenticate DRAM Automatically when authentication key all SSHv2 data traffic traversing (plaintext) SSH session between the SSHv2 Client and terminated SSHv2 Server. This key is internally derived by the module. TLS 2048 bits. The TLS server private Zeroized by “# fips TLS Server RSA RSA NVRAM key used in TLS connection. This zeroize all” command private key (plaintext) key is generated by calling SP 800- 90A DRBG. 2048 bits. The TLS server public Zeroized by “# fips TLS Server RSA RSA NVRAM key used in TLS connection. This zeroize all” command public key (plaintext) key is generated by calling SP 800- 90A DRBG. 384-bits. Shared secret created TLS pre-master Shared Secret DRAM Automatically when using asymmetric cryptography secret session terminated. (plaintext) from which new HTTPS session keys can be created. TLS session keys Triple- 192-bits/256-bits. This is the TLS DRAM Automatically when DES/AES session key. It is used to encrypt all (plaintext) session terminated. TLS data traffic traversing between the TLS client and server. This key is derived via key derivation function defined in SP800-135 KDF (TLS). 14 © Copyright 2016 Cisco Systems, Inc. This document may be freely reproduced and distributed whole and intact including this Copyright Notice. TLS authentication HMAC SHA 160-bit. This is the TLS DRAM Automatically when keys authentication key. It is used to (plaintext) session terminated. authenticate all TLS data traffic traversing between the TLS client and server. This key is internally generated by the module. IPSec Skeyid Shared Secret 160 bits. A shared secret known DRAM Automatically when only to IKE peers. It is established (plaintext) session expires via key derivation function defined in SP800-135 KDF and it will be used for deriving other keys in IKE protocol implementation. skeyid_d Shared Secret 160 bits. A shared secret known DRAM Automatically when only to IKE peers. It is derived via (plaintext) session expires key derivation function defined in SP800-135 KDF (IKEv2) and it will be used for deriving IKE session authentication key. DRAM SKEYSEED Shared Secret 160 bits. A shared secret known Automatically when only to IKE peers. It is derived via (plaintext) session expires key derivation function defined in SP800-135 KDF (IKEv2) and it will be used for deriving IKE session authentication key. IKE session TRIPLE- 192-bit Triple-DES or a 256-bit DRAM Automatically when encryption key DES/AES AES. The IKE session (IKE Phase (plaintext) session expires I) encrypt key. This key is derived via key derivation function defined in SP800-135 KDF (IKEv2). IKE session HMAC-SHA1 160 bits. The IKE session (IKE DRAM Automatically when authentication key Phase I) authentication key. This (plaintext) session expires key is derived via key derivation function defined in SP800-135 KDF (IKEv2). ISAKMP preshared pre-shared The secret used to derive IKE NVRAM Zeroized by secret skeyid when using preshared secret (plaintext) overwriting with new authentication. This CSP is entered secret by the Crypto Officer. Zeroized by “# fips IKE Authentication RSA 2048 bits. RSA private key used in NVRAM zeroize all” command private Key IKE authentication. This key is (plaintext) generated by calling SP800-90A DRBG. Zeroized by “# fips IKE Authentication RSA 2048 bits. RSA public key used in NVRAM zeroize all” command public Key IKE authentication. Internally (plaintext) generated by the module. 15 © Copyright 2016 Cisco Systems, Inc. This document may be freely reproduced and distributed whole and intact including this Copyright Notice. IPSec HMAC-SHA-1 160 bits. The IPsec (IKE Phase II) DRAM Automatically when Authentication key authentication key. This key is (plaintext) session expires derived via a key derivation function defined in SP800-135 KDF (IKEv2). IPSec encryption TRIPLE- 192 bits Triple-DES or DRAM Automatically when key DES/AES/AES- 128/192/256 bits AES. The IPsec (plaintext) session expires GCM (IKE phase II) encryption key. This key is derived via a key derivation function defined in SP800-135 KDF (IKEv2). SNMPv3 SNMPv3 Password Secret 256 bits. This secret is used to NVRAM Zeroized by derive HMAC-SHA1 key for overwriting with new (plaintext) SNMPv3 Authentication. secret snmpEngineID Shared secret 32 bits. Unique string to identify NVRAM Overwritten with new the SNMP engine. engine ID (plaintext) SNMP session key AES 128 bits. Encrypts SNMP traffic. DRAM Automatically when (plaintext) session expires Table 8 - Cryptographic Keys and CSPs 7 Secure Operation of the C3560-CX Switch The switch meets all the overall Level 1 requirements for FIPS 140-2. Follow the setup instructions provided below to place the module in FIPS-approved mode. Operating this Switch without maintaining the following settings will remove the module from the FIPS approved mode of operation. 7.1 System Initialization and Configuration 1. The value of the boot field must be 0x0102. This setting disables break from the console to the ROM monitor and automatically boots. From the “configure terminal” command line, the CO enters the following syntax: config-register 0x0F 2. The CO must create the “enable” password for the CO role. Procedurally, the password must be at least 8 characters, including at least one letter and at least one number, and is entered when the CO first engages the “enable” command. The CO enters the following syntax at the “#” prompt: Switch(config)# enable secret [PASSWORD] 3. The CO must always assign passwords (of at least 8 characters, including at least one letter and at least one number) to users. Identification and authentication on the console/auxiliary port is required for Users. From the “configure terminal” command line, the CO enters the following syntax: 16 © Copyright 2016 Cisco Systems, Inc. This document may be freely reproduced and distributed whole and intact including this Copyright Notice. Switch(config)# line con 0 Switch(config)# password [PASSWORD] Switch(config)# login local 4. To ensure all FIPS 140-2 logging is received, set the log level: Switch(config)# logging console errors 5. The CO may configure the module to use RADIUS or TACACS+ for authentication. If the module is configured to use RADIUS, the CO must define RADIUS or shared secret keys that are at least 8 characters long, including at least one letter and at least one number. The RADIUS or TACACS+ traffic must be protected by an IPSec tunnel. 6. The CO shall only assign users to a privilege level 1 (the default). 7. The CO shall not assign a command to any privilege level other than its default. 7.2 Remote Access 1. Remote access is permitted via SSHv2, TLS and SNMPv3. While in FIPS 140-2 Mode of Operation the module will enforce use of Approved algorithms for the management protocols. 8 Definition List AES – Advanced Encryption Standard CMVP – Cryptographic Module Validation Program CSE – Communications Security Establishment CSP – Critical Security Parameter DRBG – Deterministic Random Bit Generator FIPS – Federal Information Processing Standard HMAC – Hash Message Authentication Code HTTP – Hyper Text Transfer Protocol KAT – Known Answer Test LED – Light Emitting Diode MAC – Message Authentication Code MACsec – IEEE MAC Security protocol 802.1AE NDRNG – Non-Deterministic Random Number Generator NIST – National Institute of Standards and Technology NVRAM – Non-Volatile Random Access Memory PoE+ – Power over Ethernet Plus RAM – Random Access Memory SHA – Secure Hash Algorithm SHS – Secure Hashing Standard Triple-DES – Triple Data Encryption Standard 17 © Copyright 2016 Cisco Systems, Inc. This document may be freely reproduced and distributed whole and intact including this Copyright Notice.